Detection Engineering Gaps

A fintech vendor's SOC operated three SIEM platforms across their hybrid cloud environment , Microsoft Sentinel for the Azure workloads, Splunk for on-premise infrastructure, and an AWS Security Hub aggregation for their cloud-native workloads. The total rule count across the three platforms exceeded four hundred correlation rules and detection policies. The detection engineering team was two senior analysts who maintained all four platforms alongside their regular SOC duties. The four hundred rules had been accumulated over six years , some written by the original SOC team for specific incident findings, the majority inherited from platform vendor templates and threat intelligence feed integrations. The custom rules specific to the fintech industry's threat landscape , transaction manipulation, API abuse for financial fraud, credential stuffing against payment processing endpoints , numbered fewer than twenty. The remaining three hundred and eighty were generic rules applicable to any organisation. When a sophisticated financially motivated threat group that specifically targeted fintech infrastructure began probing the vendor's environment, they used techniques specifically designed to blend with normal fintech operations , API call patterns consistent with legitimate high-volume payment processing, authentication sequences mimicking automated reconciliation workflows, and data access patterns indistinguishable from standard end-of-day batch processing. The generic detection rules generated no alerts. The twenty fintech-specific rules were tuned for older attack patterns the team had previously observed. The threat actor's techniques were new.

What are Detection Engineering Gaps, Really?

Detection engineering is the discipline of designing, building, testing, and maintaining the detection logic , correlation rules, behavioural analytics, and anomaly detection policies , that enable a SIEM and SOC to identify malicious activity in a specific environment. Detection engineering gaps are the shortfalls in detection logic coverage: rules that have not been written for specific attack techniques, rules that have been inherited from generic templates without customisation, rules that have degraded in relevance as the environment and threat landscape have evolved, and rules that are never tested to confirm they still fire as designed.

The platform default inheritance problem is the most widespread detection engineering gap. SIEM platforms ship with default rule sets , hundreds of correlation rules and detection policies derived from general threat intelligence and common attack patterns. These defaults provide immediate detection coverage out of the box and are valuable for catching commodity threats. They are not designed for the specific attack patterns relevant to any particular industry, technology stack, or threat actor profile. Organisations that rely primarily on inherited defaults without building industry-specific and environment-specific detection logic have detection coverage calibrated to the average threat landscape rather than their actual threat landscape.

The rule decay problem compounds the default inheritance gap. Detection rules degrade in relevance over time as the environment changes, as attack techniques evolve, and as the tuning adjustments made to reduce false positives inadvertently narrow the rule's detection scope. A rule written to detect a specific attack pattern five years ago may have been progressively narrowed through tuning until it only fires in circumstances that exactly match the original incident that triggered it , missing the broader pattern the rule was intended to catch. Detection engineering programmes that regularly review and update rules maintain detection relevance. Programmes that primarily add new rules without retiring or refreshing old ones accumulate detection debt.

• Platform default rules without industry customisation , generic coverage for average threat landscape
• Two-person detection engineering team maintaining four hundred rules across multiple platforms
• Rule decay , tuning reducing detection scope over time
• Industry-specific techniques not covered , threat actor uses sector-specific methods
• No rule testing cadence , rules not verified to still fire as designed

Why this matters

Detection engineering gaps matter for TPRM because the SOC's detection capability is only as good as the rules that have been built and maintained. A vendor with a mature SIEM platform and comprehensive default rule deployment has the infrastructure for effective detection. Whether that infrastructure is actually effective against the specific threats relevant to the customer's data depends on whether the detection engineering programme has built and maintained rules for those specific threats. Platform maturity and detection engineering maturity are different dimensions of the same SOC capability.

The supply chain dimension is particularly relevant for industry-specific threats. Fintech customers who share data with fintech vendors face the same industry-specific threat landscape. Healthcare customers who rely on healthcare technology vendors are exposed to the same threat actors that target healthcare data. A vendor whose detection engineering programme covers generic attack patterns but lacks industry-specific detection logic is a vendor whose SOC will miss the specific techniques used by the threat actors most likely to target the customer's data through the vendor relationship.

Where most teams get this wrong

The most consistent failure is accepting rule count as a proxy for detection engineering quality. Rule count measures volume. Detection engineering quality measures relevance, maintenance, and testing cadence.

• Rule count accepted as coverage indicator
• Platform default reliance not assessed , custom vs inherited rule ratio not requested
• Detection engineering team capacity not assessed relative to rule maintenance burden
• Industry-specific rule coverage not verified
• Rule testing cadence not asked , when rules were last validated

What good looks like

Mature detection engineering programmes maintain a rule inventory that distinguishes platform defaults from custom rules, regularly test rules to confirm they fire as designed, and prioritise building and maintaining rules for the specific threat actors and techniques most relevant to the organisation's industry and threat profile.

• Custom rule ratio , what proportion of rules are environment-specific vs inherited defaults
• Industry-specific detection , rules written for sector-specific attack techniques
• Regular rule testing , rules validated to fire on relevant attack patterns
• Detection debt management , deprecated rules retired, degraded rules refreshed
• Detection engineering roadmap , known gaps and timeline for coverage improvement

Tooling

SIEM Platforms , Microsoft Sentinel, Splunk, Elastic SIEM with custom rule development

SIEM platforms provide the infrastructure for custom detection rule development. For TPRM practitioners, asking what proportion of the vendor's rules are custom-written versus platform defaults provides the detection engineering engagement indicator that total rule count does not.

Threat Intelligence , MITRE ATT&CK, industry ISACs

Industry-specific threat intelligence from ISACs and ATT&CK technique mappings for known threat groups provide the source material for detection engineering rules calibrated to the specific threat landscape. For TPRM practitioners, asking whether the vendor's detection rules are mapped to the ATT&CK techniques most associated with their industry's threat actors provides a specific relevance question.

Governance challenges

The governance challenge with detection engineering is capacity. Building and maintaining high-quality, tested, industry-specific detection rules requires significant analyst time that competes with day-to-day SOC operations. The governance resolution is dedicating specific capacity to detection engineering , separating detection development work from alert triage work , and using SOAR and automated testing to reduce the ongoing maintenance burden.

• Ask for custom versus default rule ratio , what proportion are environment-specific
• Ask for industry-specific rule count , how many rules address sector-specific techniques
• Ask for rule testing cadence , how frequently rules are validated
• Ask for last ATT&CK coverage review for industry-relevant threat actors
• Ask for detection engineering team dedicated capacity

If you are a small team

Ask your highest-risk vendor three detection engineering questions. First: what percentage of your detection rules are custom-written for your specific environment versus inherited from platform defaults? Second: do you have detection rules specifically written for the attack techniques used by threat actors known to target your industry? Third: when were your detection rules last tested to confirm they fire on the patterns they were designed to detect? Those three questions reveal whether the four hundred rules are custom and tested or inherited and unverified.

• Ask custom versus default rule ratio
• Ask for industry-specific attack technique coverage
• Ask when rules were last tested to confirm they fire
• Ask for ATT&CK coverage for industry-relevant threat groups

What to require

Ask directly:

"What percentage of your SIEM detection rules are custom-written for your environment versus inherited from platform defaults , and do you have specific rules for the attack techniques used by threat groups known to target your industry?"

Expect as evidence

• Custom versus default rule ratio
• Industry-specific rule count and technique coverage
• Rule testing cadence and last test date
• ATT&CK coverage map for industry threat actors

A vendor with four hundred detection rules should be asked how many of those rules are custom-built for their specific threat landscape. Four hundred defaults and four hundred custom rules represent very different detection engineering investment.

How to evidence it

• Custom rule ratio documentation
• Industry-specific detection coverage records
• Rule testing cadence records
• ATT&CK coverage assessment

Key Takeaway

Four hundred rules. Three hundred and eighty platform defaults. Twenty custom rules for older industry patterns. The fintech threat actor used current fintech-specific techniques. Zero alerts. The SIEM infrastructure was mature. The detection engineering programme had not built the rules to use it against the specific threat. Rule count describes investment in detection infrastructure. Custom rule ratio and industry-specific technique coverage describe whether that infrastructure has been engineered to detect the actual threats. The defaults cover the average. The custom rules cover the specific. The specific is what matters.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations