When Detection Fails: A Systematic Analysis of Cybersecurity Failure Chains Across Four Attack Vectors

The Cyber Ledger · Journal of Applied Threat Intelligence

Field	Detail
Report ID	TCL-TI-2026-012
Author	Melissa Dixon
Affiliation	Cybersecurity Engineer & Threat Intelligence Analyst, The Cyber Ledger · · Chatham, Ontario, Canada
Published	August 2026
Classification	Public Research
Companion Tool	tcl_failure_chain_poc.py
DOI (pending)	tcl.journal/2026/012

Threat Intelligence Detection Engineering MITRE ATT&CK ISO/IEC 27001 SIEM Analytics OT/ICS Security Cloud Security Supply Chain Risk

---

Abstract

Contemporary security operations centres generate telemetry at unprecedented scale, yet organisations routinely fail to detect sophisticated intrusions — not because log evidence is absent, but because detection chains break at predictable, systematic points. This paper presents a structured failure-chain analysis across four representative attack scenarios: insider privilege escalation, software supply chain compromise with command-and-control establishment, cloud infrastructure misconfiguration with cross-tenant lateral movement, and operational technology targeting in the water treatment sector.

For each scenario, we identify and classify the specific detection failure mode — alert tuning errors, logging architecture gaps, investigation overhead, and alert suppression abuse — and map these failures to corresponding MITRE ATT&CK techniques and ISO/IEC 27001:2022 control deficiencies. We validate our analysis with a companion proof-of-concept simulation engine that generates realistic, vendor-agnostic JSON log artefacts demonstrating each bypass mechanism.

Our findings indicate that detection failures are not random occurrences but structurally predictable failures in the detection chain design. We conclude with quantifiable metrics for measuring detection chain strength and scenario-specific defensive playbooks.

Keywords: detection engineering, failure chain analysis, SIEM, alert tuning, MITRE ATT&CK, ISO 27001, supply chain security, OT/ICS security, cloud misconfiguration, insider threat, proof-of-concept simulation

---

Table of Contents

1. Introduction
2. Background and Related Work
3. Methodology
4. Scenario Analysis
   • 4.1 Insider Escalation
   • 4.2 Supply Chain
   • 4.3 Cloud Misconfiguration
   • 4.4 OT/ICS Water Sector

---

1. Introduction

The assumption that comprehensive logging equates to effective detection is one of the most persistent misconceptions in defensive security practice. Organisations invest heavily in security information and event management (SIEM) platforms, endpoint detection and response (EDR) tools, and network monitoring infrastructure — yet post-incident analyses routinely reveal that attack evidence existed in logs throughout the intrusion lifecycle, visible only in retrospect [1, 2].

This gap between logging capability and detection outcome defines what we term the detection chain paradox: the condition in which an organisation possesses sufficient telemetry to detect an attack, yet fails to do so because intermediate steps in the detection chain — alert configuration, log routing, baseline modelling, and investigation workflow — are broken or absent.

The consequences are severe and measurable. Industry data consistently shows that mean time to detect (MTTD) for sophisticated intrusions remains measured in days to weeks, with dwell times for supply chain and OT-targeted attacks frequently exceeding 90 days [3]. These figures persist despite significant growth in security tooling budgets, suggesting that the limiting factor is not instrumentation but detection chain design.

1.1 Research Objectives

This paper pursues four primary objectives:

1. Characterise the specific failure modes that break detection chains across diverse attack scenarios and environments.
2. Map each failure mode to corresponding MITRE ATT&CK techniques and ISO/IEC 27001:2022 control deficiencies.
3. Validate the analysis with a reproducible simulation engine generating realistic attack log artefacts for each scenario.
4. Provide practitioner-oriented metrics and defensive playbooks directly actionable without vendor-specific tooling dependencies.

1.2 Scope and Limitations

This research focuses on detection failure rather than attack novelty. The four scenarios selected represent well-documented attack classes chosen specifically because their detection mechanisms are understood and achievable — making undetected instances a product of operational failure rather than technical impossibility. The companion POC is designed for educational and authorised testing use only and does not implement live attack capability.

---

2. Background and Related Work

2.1 The Detection Chain Model

Effective intrusion detection requires the successful completion of a sequential chain:

1. An event must be logged
2. The log must be transported to an analysis platform
3. A detection rule must match the event
4. The resulting alert must be routed to an analyst
5. The analyst must be able to investigate within an actionable time window

Failure at any single link renders the entire chain ineffective, regardless of the quality of the remaining links [4].

Prior work by Hutchins et al. [5] established the cyber kill chain as a model for understanding attacker progression. The MITRE ATT&CK framework [6] extended this to enumerate specific techniques and sub-techniques with associated detection guidance. However, relatively little published work focuses on the systematic characterisation of why detection rules fail to fire despite adequate telemetry — the gap this paper addresses.

2.2 Failure Mode Classification

We identify four primary failure modes that collectively account for the majority of detection gaps observed in post-incident analysis:

Table 1: Detection chain failure mode taxonomy

Failure Mode	Definition	Primary Effect
Alert Tuning Failure	Detection rules exist but are configured with thresholds or filters that exclude the specific behaviour being exhibited	True positives suppressed at rule evaluation stage
Logging Architecture Gap	Events are either not captured at source, or captured locally but not transported to the analysis platform	No evidence available regardless of rule quality
Investigation Overhead	Alerts fire but query latency, missing context, or workflow friction prevents timely analyst response	Actionable window closes before investigation begins
Alert Suppression Abuse	Legitimate suppression mechanisms (maintenance windows, user whitelists) applied too broadly, masking adversarial activity	Critical alerts permanently silenced

2.3 Regulatory and Standards Context

ISO/IEC 27001:2022 Annex A provides a control framework whose logging and monitoring requirements (A.8.15, A.8.16) establish baseline obligations for event capture and review. However, the standard specifies what must be logged without prescribing the detection engineering practices required to make those logs actionable. This paper treats the standard's controls as a minimum floor and maps failure modes to specific control deficiencies to facilitate audit-oriented remediation planning.

---

3. Methodology

Each scenario was constructed using the following analytical protocol:

Table 2: Analytical methodology protocol

Step	Phase	Description
1	Attack Chain Decomposition	Each attack vector was decomposed into discrete, observable steps using MITRE ATT&CK as the reference taxonomy. Steps were selected to represent the complete intrusion lifecycle from initial access to impact.
2	Logging Inventory	For each step, we identified what logging sources would capture the activity under ideal conditions, distinguishing between events that are logged by default, require explicit configuration, or are not capturable by standard means.
3	Detection Failure Analysis	We then assessed whether, in a realistic but imperfect operational environment, each log event would trigger a detection alert — and where it would not, classified the failure mode using the taxonomy in Table 1.
4	Control Mapping	Each failure mode was mapped to corresponding MITRE ATT&CK technique(s) and ISO/IEC 27001:2022 control(s) to enable structured remediation planning.
5	POC Simulation	A Python-based simulation engine was developed to generate realistic JSON log artefacts for each scenario step, annotated with failure reason metadata to support hands-on detection engineering exercises.

Scenario selection criteria prioritised attack vectors that: (a) have documented real-world precedent in public threat intelligence reporting, (b) span diverse infrastructure domains (endpoint, cloud, network, OT), (c) exhibit different primary failure modes, and (d) are detectable in principle with standard tooling — making their non-detection an operational rather than technical problem.

---

4. Scenario Analysis

The following sections present each scenario's attack chain, detection failure analysis, MITRE ATT&CK and ISO 27001 mappings, and companion log artefact excerpts from the POC simulation engine.

---

4.1 Insider Escalation: Privilege Escalation Detection Failure

An authorised user with standard privileges exploits a combination of local vulnerability and cached credential abuse to achieve root-level access. This scenario is particularly challenging for detection because the attacker's initial behaviour is functionally identical to legitimate administrative activity, and the escalation itself exploits trust mechanisms designed to reduce friction for authorised users.

4.1.1 Attack Chain

Table 3: Insider escalation attack chain and detection failures

Step	Technique	Action	Failure Mode	Why Detection Missed It
1	T1087 Account Discovery	whoami, id, sudo -l enumeration	Alert Tuning	Indistinguishable from legitimate admin activity; no deviation baseline configured
2	T1548.003 Sudo Abuse	CVE exploitation of SUID binary /usr/bin/apt	Alert Tuning	kern.log segfault + auditd execve logged; alert threshold set to LOW/ignore
3	T1548 Token Abuse

4.1.2 Log Artefact Evidence (POC Output)

The following excerpt from the POC simulation engine illustrates the Step 4 failure — root-level command execution that is logged but unreachable within an actionable timeframe:

json
Copy
1{
2  "source": "auditd",
3  "event": "execve",
4  "user": "root",
5  "euid": 0,
6  "uid_original": "jdoe",
7  "command": "curl -X POST http://c2.attacker.com/exfil -d @/tmp/.x",
8  "severity": "critical",
9  "alert_fired": false,
10  "failure_reason": "investigation_overhead — auditd logs exist; SIEM query latency 48hr"
11}

Detection opportunity: auditd rule -a exit,always -F arch=b64 -F euid=0 -S execve would capture this. The log exists. The SIEM never sees it in time.

4.1.3 Key Finding

This scenario demonstrates that detection failure does not require any logging gap. All four steps generate log evidence in standard audit facilities. The failure is entirely at the detection rule and investigation workflow layer: thresholds calibrated to reduce noise inadvertently suppress the signal, and query latency converts logged evidence into a forensic artefact rather than an operational alert.

---

4.2 Supply Chain Compromise: Initial Access and C2 Detection Gap

A trojanized software package is distributed through a legitimate package registry. The malicious postinstall hook executes an in-memory beacon establishing DNS-tunnelled command-and-control. This scenario is notable because the attack leverages trusted distribution infrastructure — the package manager, the CDN, the DNS resolver — in ways that are difficult to distinguish from legitimate operations without fine-grained baseline modelling.

4.2.1 Attack Chain

Table 4: Supply chain attack chain and detection failures

Step	Technique	Action	Failure Mode	Why Detection Missed It
1	T1195.002 Supply Chain	Trojanized npm package with malicious postinstall script	Logging Gap	Signature validation disabled (DISABLE_INTEGRITY_CHECKS=true in CI); no SCA gate
2	T1059 Scripting	npm spawns curl|bash chain downloading in-memory beacon	Alert Suppression	EDR sees npm→sh→curl; suppressed — BUILD_ACTIVITY whitelist too broad
3	T1071.004 DNS C2

4.2.2 The DNS Telemetry Gap

The most significant finding in this scenario is the complete absence of DNS telemetry in the SIEM. DNS query logs represent one of the highest-signal detection data sources available — capable of identifying C2 beaconing, domain generation algorithms, and data exfiltration — yet in many environments they are stored locally on the resolver and never forwarded to centralised analysis infrastructure.

The POC generates eight representative DNS tunnel queries per run, each of which would have been detectable with a simple entropy-based subdomain analysis rule had the logs been present in the SIEM:

json
Copy
1{
2  "source": "dns_resolver_local",
3  "event": "dns_query",
4  "query": "cmd07aaaaaaaa.c2.attacker.com",
5  "qtype": "A",
6  "response": "NXDOMAIN",
7  "note": "DNS tunnel heartbeat — subdomain encodes C2 command",
8  "alert_fired": false,
9  "failure_reason": "logging_gap — DNS resolver logs stored locally; never forwarded to SIEM"
10}

Detection signature (if logs were present): Query volume >50/min per host OR subdomain entropy >3.5 OR new TLD first-seen = HIGH confidence C2 indicator.

---

4.3 Cloud Misconfiguration: IAM Logging Failures and Cross-Tenant Lateral Movement

An attacker obtains AWS credentials from an exposed developer configuration file. Exploiting disabled audit trails and overly broad IAM trust relationships, they pivot from a compromised tenant to a second tenant via a legitimate cross-account role assumption mechanism, ultimately exfiltrating sensitive data from an environment they never directly compromised.

4.3.1 Attack Chain

Table 5: Cloud misconfiguration attack chain and detection failures

Step	Technique	Action	Failure Mode	Why Detection Missed It
1	T1078.004 Cloud Accounts	API key obtained from public GitHub repo .env file	Logging Gap	CloudTrail disabled for cost reduction — zero API activity logged
2	T1087 Discovery	ListRoles, ListBuckets, DescribeDB reconnaissance	Investigation Overhead	Logs in S3 cold storage; 12-hour ingestion lag to SIEM
3	T1098.001 Account Manipulation	AssumeRole to in Tenant 2

4.3.2 The Cost-Optimisation Anti-Pattern

This scenario exhibits a failure mode increasingly documented in cloud security post-incident analyses: audit trail disablement as a cost-reduction measure. CloudTrail (AWS), Activity Log (Azure), and Cloud Audit Logs (GCP) are frequently cited as significant cost drivers in cloud observability budgets.

The POC represents this as an explicit gap marker:

json
Copy
1{
2  "source": "cloudtrail",
3  "event": "LOGGING_DISABLED",
4  "account": "111111111111",
5  "trail_name": "prod-trail",
6  "is_logging": false,
7  "reason": "Trail disabled 2023-07-01 — cost optimisation ticket INFRA-4421",
8  "alert_fired": false,
9  "failure_reason": "logging_gap — CloudTrail off; zero API activity recorded"
10}

Position: Audit trail logging is a non-negotiable security baseline, not an optimisation target. Cost of CloudTrail: ~$5/month per account. Cost of a breach: orders of magnitude higher.

---

4.4 OT/ICS Water Sector: Protocol Anomaly Detection and Alert Suppression

An attacker with access to an industrial control network sends unauthorised Modbus protocol commands to a water treatment facility's PLC, disabling safety interlocks and commanding unsafe valve actuation. The attack exploits three compounding failures: absence of OT-specific protocol baseline modelling, operational alert suppression covering the attack window, and the complete absence of safety-outcome sensor integration with monitoring infrastructure.

4.4.1 Attack Chain

Table 6: OT/ICS attack chain and detection failures

Step	Technique	Action	Failure Mode	Why Detection Missed It
1	T1204 User Execution	Modbus FC16 write to valve control register — value 0xFFFF (full open)	Alert Tuning	PCAP logged; no out-of-range value detection rule for register 0x0100
2	T1562.001 Impair Defences	FC5 coil write disabling emergency stop interlock (0x0000)	Alert Suppression	SCADA alarm fires at WARNING; auto-acknowledged below CRITICAL threshold
3	T1565 Data Manipulation	Flow setpoint commanded to 1000 GPM (normal: 50±5 GPM)	Alert Suppression	SCADA alert suppressed — maintenance window active 00:00–06:00
4	T1499 Impact (physical)	Water quality: pH 6.5, Cl₂ 0.3 ppm — below safe thresholds

4.4.2 The Maintenance Window Exploitation Pattern

A particularly significant finding is the deliberate timing of the attack to coincide with a daily alert suppression window. This pattern — exploiting predictable operational gaps in monitoring coverage — has been documented in multiple ICS-targeting incidents, including the 2021 Oldsmar water treatment facility incident and the 2026 Iranian-affiliated PLC campaign targeting Minnesota utilities [7, 8].

json
Copy
1{
2  "source": "scada_historian",
3  "event": "setpoint_change",
4  "parameter": "flow_rate_gpm",
5  "previous_value": 52,
6  "new_value": 1000,
7  "normal_range": "50 ± 5 GPM",
8  "scada_alarm": "FLOW_SETPOINT_ANOMALY",
9  "alarm_suppressed": true,
10  "suppress_reason": "maintenance_window active 00:00–06:00 daily",
11  "physical_consequence": "pump cavitation begins T+90s; pipe pressure surge to 180 PSI at T+120s",
12  "alert_fired": false,
13  "failure_reason": "maintenance_window_abuse — attacker timed attack; ALL flow alerts suppressed for 6hr"
14}

Design flaw: Maintenance windows that suppress an entire severity class are a structural vulnerability. Safety-critical register writes must never be suppressible — not during maintenance, not during upgrades, not ever.

---

5. Consolidated MITRE ATT&CK and ISO/IEC 27001:2022 Mapping

5.1 MITRE ATT&CK Coverage Matrix

Table 7: MITRE ATT&CK technique mapping across all four scenarios

Scenario	Tactic	Technique(s)	Detection Opportunity Missed
Insider Escalation	Privilege Escalation, Execution	T1087, T1548.003, T1059.004	Escalation attempt logged; alert threshold excludes technique class
Supply Chain	Initial Access, C2, Exfiltration	T1195.002, T1071.004, T1020	Package integrity not verified; DNS telemetry absent from SIEM
Cloud Misconfiguration	Initial Access, Lateral Movement, Exfiltration	T1078.004, T1098.001, T1537

5.2 ISO/IEC 27001:2022 Control Deficiency Mapping

Table 8: ISO/IEC 27001:2022 control deficiency mapping

Scenario	Control(s)	Deficiency	Remediation Control Action
Insider Escalation	A.8.15 Logging, A.8.16 Monitoring	Escalation logging exists but detection rules not tuned for technique	Enable privilege escalation detection; correlate escalation to post-exploit activity
Supply Chain	A.8.15 Logging, A.8.29 Secure Dev, A.8.20 Networks	Package integrity not verified; DNS egress not monitored	Enforce SCA in CI gate; forward DNS logs to SIEM in real-time
Cloud Misconfiguration	A.8.15 Logging, A.8.16 Monitoring, A.8.21 Network Filtering	Audit trail disabled; cross-tenant visibility absent	Non-negotiable: enable all cloud audit logging; unified cross-tenant SIEM
OT / Water Sector	A.8.15 Logging, A.8.16 Monitoring, A.5.37 Procedures	OT baselines absent; suppression governance missing	Profile Modbus baselines; audit all alert suppressions; never suppress safety registers

---

6. Proof-of-Concept Simulation Engine

To validate the failure chain analysis and provide a hands-on learning artefact, we developed a Python-based simulation engine that generates realistic log artefacts for each scenario. The engine is designed for deployment in detection engineering exercises, SOC team training, and SIEM rule validation.

6.1 Design Principles

• Vendor-agnostic output: All logs are JSON-structured with ISO 8601 timestamps and Unix epoch fields, importable into any SIEM platform without format transformation.
• Annotated failure reasoning: Each log entry includes a failure_reason field explicitly documenting why the corresponding detection rule would not fire, making the failure mechanism transparent for educational use.
• Realistic artefact fidelity: Log entries replicate the field structure, naming conventions, and content patterns of actual log sources — auditd, CloudTrail, Zeek/Modbus, EDR process trees.
• Zero attack capability: The engine generates log data only. No network connections are made, no system modifications are performed, and no exploit code is implemented.

6.2 Usage

bash
Copy
1# Run all four scenarios
2python3 tcl_failure_chain_poc.py
3
4# Output lands in ~/Desktop/TCL_FailureChain/
5scenario_1_insider_escalation.json      # 10 log entries
6scenario_2_supply_chain.json            # 14 entries (incl. 8 DNS beacon queries)
7scenario_3_cloud_misconfiguration.json  # 9 entries (CloudTrail-structured)
8scenario_4_ot_water_sector.json         # 6 entries (Modbus/SCADA-structured)
9failure_chain_analysis_report.json      # Aggregated findings + failure mode breakdown

6.3 Log Entry Schema

Every log entry follows a consistent schema:

json
Copy
1{
2  "timestamp": "2026-08-14T10:23:45.123456",
3  "unix_time": 1755171825,
4  "source": "<log_source>",
5  "event": "<event_type>",
6  "severity": "informational | warning | high | critical",
7  "alert_fired": false,
8  "failure_reason": "<failure_mode> — <specific explanation>"
9}

The alert_fired: false field on every entry is the core teaching signal — every log entry represents a detection opportunity that was not taken.

6.4 SIEM Integration Reference

Table 9: SIEM platform integration reference

Platform	Ingestion Method	Configuration
Splunk	Add Data → Upload or Filebeat HEC	sourcetype=json; timestamp as time field
Elastic / Kibana	Kibana Upload or Filebeat	ECS mapping; @timestamp from timestamp field
Microsoft Sentinel	Log Analytics workspace upload	Custom table; KQL on failure_reason column
Datadog SIEM	Log Management → Upload	JSON auto-parsed; index on severity and source
Google Chronicle	Ingestion API or SIEM Upload	UDM mapping; filter alert_fired=false for gap analysis

6.5 Suggested Lab Exercise

Import all four JSON files into your SIEM. Then:

1. Query for all severity=critical entries. How many do you find? (Expected: many)
2. Query for all entries where alert_fired=true. How many do you find? (Expected: zero)
3. Read the failure_reason fields. Group by failure mode. Which is most common in your simulated environment?
4. Build one detection rule for a specific step using the scenario analysis in Section 4. Re-run the query. Did it fire?

That gap between steps 1 and 2 is your detection chain failure, made visible.

---

7. Defensive Playbooks

The following playbooks provide concrete, implementation-ready actions to repair each broken detection chain link. Each action is annotated with the failure mode it addresses.

---

7.1 Insider Escalation — Detection Repair

Alert Tuning — Baseline before alerting
Profile normal privilege enumeration patterns per user class. Build detection rules targeting anomalies from baseline, not raw event occurrence. A developer running sudo -l at 2am is an anomaly. The same developer running it at 10am is noise.

Alert Tuning — Correlate escalation to post-exploit activity
Build SIEM rule: [euid transition to 0] AND [execve within 60 seconds] = HIGH alert. Correlation eliminates the false positive problem that drove the original suppression.

Investigation Overhead — Pre-index root execution events
Configure SIEM to index auditd events where euid=0 in a dedicated high-priority index with <5 minute query latency. Never build investigation queries during an incident. Build them now.

Alert Suppression — Audit all user whitelists quarterly
Every suppression rule must have an owner, a justification, and an expiry date. Require re-approval for any whitelist older than 90 days. Whitelist users, never techniques.

---

7.2 Supply Chain — Detection Repair

Logging Gap — Enforce package integrity in CI gates
Require cryptographic signature verification on all package installs. Deploy SCA scanning (Snyk, Grype, Dependabot) as a CI gate. Block on unknown package hashes — fail the build, don't warn.

Logging Gap — Forward DNS logs to SIEM in real-time
This is non-negotiable. Configure DNS resolvers to stream all query logs to the SIEM via syslog or Filebeat. Target: <60 second latency. DNS telemetry is one of the highest-signal detection sources available — not having it in the SIEM is an unacceptable blind spot.

Alert Tuning — Build DNS anomaly detection
Alert on: [query volume >50/min per host] OR [subdomain entropy >3.5] OR [new TLD first-seen for host]. These are low false-positive signals that indicate DNS tunnelling with high confidence.

Alert Suppression — Narrow build-activity whitelists
npm curling registry.npmjs.org is expected. npm curling cdn.attacker.com is not. Whitelist specific, expected destinations — never whitelist a technique class. Rule: [npm parent] AND [curl to non-registry domain] = alert.

---

7.3 Cloud Misconfiguration — Detection Repair

Logging Gap — Enable all audit logging — non-negotiable
CloudTrail, Azure Activity Log, GCP Cloud Audit Logs must be enabled in all regions at all times. Treat this as a security budget line item. The cost is ~$5/month per AWS account. The cost of a breach is not.

Investigation Overhead — Stream to SIEM in real-time
Use EventBridge + Kinesis Firehose (AWS) or Diagnostic Settings + Event Hub (Azure) to stream audit logs to SIEM. Never rely on S3/Blob batch delivery for security telemetry. Target: <60 second log-to-alert latency.

Blind Spot — Build cross-tenant correlation rules
The SIEM must ingest logs from all tenants under a single workspace. Correlation rule: [AssumeRole from Tenant A] → [API activity in Tenant B within 30 min] = MEDIUM alert for analyst review.

Alert Suppression — Narrow AssumeRole whitelists
Whitelist on three conditions simultaneously: source IP + time window + specific role ARN. Alert when any single condition changes independently. An AssumeRole from a new IP is an anomaly even if the role ARN is expected.

---

7.4 OT/ICS Water Sector — Detection Repair

Alert Tuning — Build per-register value baselines
Profile expected value ranges, write frequencies, and authorised source addresses per register address. Deploy OT-specific IDS (Claroty, Nozomi, Dragos) to automate baseline modelling. Alert on: [FC16 write] AND [register 0x0100] AND [value > 0x03FF].

Alert Suppression — Safety registers = CRITICAL, never suppressible
Create a no-suppress policy for a defined list of safety-critical register addresses (E-stop coils, safety interlock registers, flow setpoint limits). These must always reach a human analyst. No exception for maintenance windows.

Alert Suppression — Limit maintenance windows to informational tier only
Never suppress HIGH or CRITICAL alerts during maintenance windows. If suppression is operationally necessary, require dual-person authorisation with a maximum duration of 15 minutes and automatic re-enable. Log all suppressions with operator ID and justification.

Blind Spot — Integrate outcome sensors into historian
Wire pH, chlorine residual, turbidity, and pressure sensors to the SCADA historian. Build correlation: [anomalous command] AND [sensor divergence within 10 minutes] = automatic CRITICAL with shutdown trigger evaluation.

---

8. Detection Chain Metrics Framework

We propose six quantifiable metrics for ongoing measurement of detection chain strength. These metrics are designed to be measurable with standard SIEM tooling without requiring additional instrumentation.

Table 10: Detection chain strength metrics

Metric	Definition	Measurement Method	Target
Mean Time to Investigate (MTTI)	Time from alert generation to analyst beginning active investigation	SIEM ticket creation timestamp minus alert timestamp	< 15 min for HIGH/CRITICAL
Detection Rule Coverage	Percentage of MITRE ATT&CK techniques in the threat model covered by at least one active detection rule	Rule inventory audit against ATT&CK Navigator layer	> 80% of in-scope techniques
Log-to-Alert Latency	Time from event logged at source to alert available to SOC	Inject synthetic test event; measure to alert timestamp	< 60 seconds for all sources
False Positive Rate	Percentage of alerts requiring manual triage that are determined to be non-actionable	Analyst closure labels divided by total alerts, 30-day window	< 20% per rule
Cross-Domain Correlation Rule Count	Number of active detection rules that correlate events from two or more distinct log sources	SIEM rule inventory with source count annotation	> 10 cross-domain rules
Alert Suppression Audit Coverage	Percentage of active alert suppressions with documented owner, justification, and expiry	Suppression rule inventory audit	100% — no undocumented suppressions

8.1 90-Day Implementation Roadmap

Weeks	Priority Actions
1–2	Inventory all logging sources. Document what is and is not reaching the SIEM. Identify top-3 logging gaps by risk.
3–4	Enable missing critical log sources (cloud audit trails, DNS forwarding). Build first cross-domain correlation rule.
5–8	Build per-environment baselines. Deploy tiered alert rules. Implement suppression audit trail. Create 3 investigation playbooks.
9–12	Deploy SIEM dashboards per scenario. Run tabletop detection exercises using POC logs. Measure all six metrics. Iterate.

---

9. Discussion

9.1 The Structural Nature of Detection Failure

The most significant finding of this analysis is that detection failures across all four scenarios are structurally predictable. Each failure mode — alert tuning, logging gaps, investigation overhead, suppression abuse — follows from identifiable design decisions: thresholds set to reduce noise, log routing not updated when infrastructure changed, cost optimisations applied to security telemetry, and operational convenience taking precedence over monitoring integrity.

This predictability is operationally significant. If detection failures are structural rather than random, they can be audited proactively. The failure mode taxonomy in Table 1 provides a structured audit framework: for each detection control, practitioners should explicitly test whether logs are present, whether they reach the SIEM, whether a rule would match, whether that rule is suppressed, and whether investigation is feasible within the MTTI target.

9.2 The Evidence Paradox

A counterintuitive implication of this research is that increasing logging volume without corresponding investment in detection engineering may actually worsen detection outcomes. Additional log sources increase alert noise, which drives higher suppression thresholds and broader whitelists — the exact conditions that create the alert tuning and suppression failure modes documented here.

The correct prioritisation hierarchy is:

1. Ensure critical log sources reach the SIEM
2. Build specific detection rules with low false positive rates
3. Establish baseline models to support anomaly detection
4. Only then expand log source coverage

9.3 OT/ICS as a Special Case

The water sector scenario warrants separate discussion because it introduces a failure mode not present in the IT scenarios: the complete absence of safety-outcome monitoring. In IT environments, the impact of an undetected intrusion is typically data loss or service disruption — both recoverable. In OT environments targeting physical processes, the impact can be immediate physical harm, as the 2021 Oldsmar incident demonstrated.

The gap between command logging (what was instructed) and outcome monitoring (what physically resulted) represents a fundamental detection design deficiency unique to OT environments — one that standard IT security frameworks do not adequately address. NIST SP 800-82 and IEC 62443 provide OT-specific guidance, but adoption remains inconsistent across water sector operators [10, 11].

---

10. Conclusion

This paper has presented a systematic failure chain analysis across four representative attack scenarios, demonstrating that detection failure is a predictable structural problem rather than an unavoidable consequence of attacker sophistication. In every scenario examined, the log evidence necessary for detection was present or achievable — the failure occurred at the detection engineering layer.

We have characterised four primary failure modes, mapped each to MITRE ATT&CK techniques and ISO/IEC 27001:2022 control deficiencies, and provided a companion simulation engine that generates realistic log artefacts for hands-on practitioner validation. The metrics framework in Section 8 provides a quantifiable basis for ongoing detection chain strength assessment.

The central recommendation of this research is that detection engineering must be treated as a first-class discipline with its own design methodology, audit practices, and performance metrics — not as a configuration task subsidiary to platform deployment. The detection chain is only as strong as its weakest link. That link is almost always known, almost always fixable, and almost always not fixed.

---

"The evidence was in the logs. It always is. The question is whether your detection chain was designed to find it."

---

References

[1] Mandiant. (2024). M-Trends 2024: Special Report. Mandiant Inc. Global dwell time median reported at 10 days for detected intrusions.

[2] Verizon. (2024). 2024 Data Breach Investigations Report. Verizon Business. Analysis of 30,458 incidents showing detection gaps in logging and monitoring.

[3] IBM Security. (2024). Cost of a Data Breach Report 2024. IBM Corporation. MTTD analysis across industry sectors; OT environments average 187 days.

[4] MITRE Corporation. (2024). MITRE ATT&CK Detection Guidance. https://attack.mitre.org — framework for mapping techniques to detection opportunities.

[5] Hutchins, E. M., Cloppert, M. J., & Amin, R. M. (2011). Intelligence-driven computer network defense informed by analysis of adversary campaigns and intrusion kill chains. Proceedings of the 6th International Conference on Information Warfare and Security, 80, 113–125.

[6] MITRE ATT&CK. (2024). Enterprise ATT&CK v14. MITRE Corporation. https://attack.mitre.org/matrices/enterprise/

[7] CISA. (2021). Oldsmar Water Treatment Facility Cyber Incident. ICS-CERT Advisory AA21-042A. United States Cybersecurity and Infrastructure Security Agency.

[8] Dixon, M. (2026). TCL-TI-2026-011: Iranian-Affiliated PLC Campaign Targeting U.S. Water Utilities. The Cyber Ledger Journal. Detailed analysis of 30+ Minnesota utility targeting, July 2026.

[9] ISO/IEC. (2022). ISO/IEC 27001:2022 Information Security Management Systems — Requirements. International Organisation for Standardisation.

[10] NIST. (2018). Framework for Improving Critical Infrastructure Cybersecurity v1.1. National Institute of Standards and Technology. https://www.nist.gov/cyberframework

[11] ICS-CERT. (2016). Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies. DHS / CISA.

[12] Gartner. (2024). Market Guide for Security Information and Event Management. Gartner Inc. Analysis of SIEM detection effectiveness benchmarks.

---

About the Author

Melissa Dixon is a cybersecurity engineer and threat intelligence analyst based in Canada. She serves as a contributing intelligence analyst and content creator for The Cyber Ledger. Her research spans threat intelligence reporting, CTF design, penetration testing, curriculum development, and GRC analysis with deep ISO/IEC 27001 framework expertise.

---

This research is provided for educational purposes and authorized security testing only. The companion POC simulation engine does not implement live attack capability. All scenario data is synthetic. © 2026 The Cyber Ledger. All rights reserved.