Logging and Detection: Why Most Breaches Are Found by Someone Else

Years of incident reporting point to the same uncomfortable finding: a large share of intrusions are discovered by third parties, not by the victim's own monitoring. A customer notices unusual activity, a law-enforcement agency makes an arrest, or a journalist receives stolen data. By then the dwell time is measured in weeks or months.

Why detection fails

The reasons are consistent across industries.

Logs are collected but not correlated. Authentication events, endpoint telemetry, and network flows live in separate systems with separate retention windows, so the sequence that would reveal an intrusion is never assembled in one place.

Alerting is tuned for volume rather than for behaviour. A rule that fires on failed logins generates noise; a rule that fires on a successful login from a new country for an account with no travel history generates signal.

Coverage has gaps in exactly the places attackers use. Identity provider logs, cloud control-plane audit trails, and CI/CD system logs are frequently not forwarded to the security monitoring platform at all.

What good looks like

• Forward identity provider, cloud control plane, and build system logs to the same platform as endpoint and network telemetry.
• Retain authentication and audit logs long enough to cover realistic dwell time; thirty days is rarely sufficient.
• Build detections around attacker behaviour rather than tool signatures: new token issuance, new device registration, bulk data access, and unusual administrative actions.
• Store logs where the monitored system cannot modify them, so an intruder cannot erase the evidence.
• Exercise the detection path: run a controlled test and measure whether it is detected and how long it takes.

Conclusion

Detection is not a product, it is a coverage problem. The organisations that find intrusions themselves are the ones that have assembled the relevant telemetry in one place and built detections around what attackers do rather than what tools they use.

References

• NIST SP 800-61, Computer Security Incident Handling Guide: https://csrc.nist.gov/pubs/sp/800/61/r2/final
• CISA guidance on logging and incident detection: https://www.cisa.gov/resources-tools/resources/implementing-logging-and-incident-detection
• MITRE ATT&CK framework: https://attack.mitre.org/