Newsletter Article
Detection Is Not Investigation
Snare Insider Newsletter Series Article
Make sure you Subscribe
The gap between the alert and the answer
That distinction surfaces repeatedly across this week’s InfoSec World and CyberCon programs.
InfoSec World’s From Alert to Evidence session opens with a line every SOC lead will recognise: security tools can generate a high-confidence alert in seconds.[1] Determining what actually occurred — how the attacker got in, how far the activity spread, which systems and data were affected — can still take hours or days. A Threat Summit session, From Chasing Alerts to Understanding Attacks, traces one organisation’s move from reactive alerting to kill-chain-aware detection, built on better visibility and contextual investigation.[2] At CyberCon, sessions on incident pre-mortems and security architecture “whodunits” ask the same question from the response side: when an incident is reconstructed after the fact, where do the gaps turn out to be?[3]
The industry data points the same way. IBM’s Cost of a Data Breach Report 2025 puts the mean time to identify and contain a breach at 241 days — a nine-year low, but still the better part of a year.[4] Mandiant’s M-Trends 2026 reports a global median dwell time of 14 days, up from 11, rising to a median of 122 days for cyber-espionage intrusions. It also reports that the median time between initial access and hand-off to a secondary threat group fell from more than eight hours in 2022 to 22 seconds in 2025.[5]
Attackers are moving faster. Investigations still have to look back further.
This is fundamentally an evidence problem.
Start before the alert
Imagine an identity alert fires at 10:17 on a Tuesday morning: an impossible-travel sign-in for a privileged account, followed by an unusual Kerberos service-ticket request.
The detection did its job. Now the investigation begins, and it needs to determine:
- when the credentials were first compromised;
- which device originally authenticated, and how;
- whether authentication occurred from another location or network;
- what privileges the account held at the time;
- whether those privileges changed — and who changed them;
- which systems the identity subsequently accessed;
- which processes executed on those systems;
- whether administrative or remote-access tools were used;
- whether data was accessed, staged or moved; and
- whether similar activity occurred previously.
The alert at 10:17 may be just one event in a sequence that began days, weeks or months earlier. In MITRE ATT&CK terms, a Valid Accounts (T1078) intrusion often looks like legitimate activity until a specific behaviour trips a rule — by which point the useful evidence is in the past.
The investigator therefore needs something much broader than the detection itself. They need a timeline of evidence.
Evidence rarely lives in one place
A modern investigation can require events from:
Endpoints and servers — authentication, process execution, services, file activity, configuration changes and administrative events.
Identity systems — logons, authentication failures, privilege changes, MFA activity, service-account use and directory changes.
Cloud infrastructure — control-plane actions, workload events, configuration changes and access activity.
SaaS platforms — user activity, administrator changes, application permissions and data access.
Network and security infrastructure — connections, VPN sessions, policy changes, firewall activity and security-control events.
The challenge isn’t simply collecting each dataset. It’s being able to correlate them. An investigator needs to move from:
identity → device → access → privilege → action → destination → outcome
without losing the thread because one dataset has expired, another was never collected, timestamps aren’t aligned, or the evidence sits in a system the investigation team can’t readily search.
Time alignment deserves special mention. Endpoint logs recorded in local time, cloud logs in UTC and an appliance with a drifting clock can turn a clean sequence into an argument about which event came first. Normalising timestamps at collection — and keeping time sources synchronised — is one of the least glamorous and most valuable investigation controls an organisation can have.
Collection needs to support investigation
That means security teams need to think beyond:
“Are we collecting logs?”
and ask:
“Could we reconstruct an incident from them?”
Those aren’t the same question. Each property of a logging architecture maps to a specific way an investigation can stall:
| If collection lacks… | The investigation suffers from… |
| Coverage | Blind spots — systems, identities or SaaS tenants that generated no evidence |
| Retention | Historical gaps — the evidence existed, but expired before it was needed |
| Integrity | Doubt — the record can’t be shown to be complete and unaltered |
| Searchability | Delay — the evidence exists but takes days to retrieve or rehydrate |
| Context | Manual reconstruction — analysts stitching relationships between millions of events by hand |
The joint SIEM and SOAR guidance published in 2025 by ASD’s ACSC, CISA and international partners makes the same point from the other direction: the absence of logs from systems should itself be a concern to organisations, and a log retention and archiving policy should be implemented — at a minimum, one year for logs recording administrative and security-related events.[7]
Five checks for investigation readiness
- Pick your top three scenarios — for most organisations, privileged-account compromise, ransomware precursor activity and SaaS data exfiltration — and list the evidence each would need.
- Confirm collection, source by source, including identity providers, cloud control planes and SaaS audit logs, not just endpoints.
- Check retention against dwell time, not against licence tiers. If credible intrusions run for months, 30- or 90-day windows won’t answer the question.
- Normalise time at collection and verify clock synchronisation across sources.
- Test retrieval. Pull a 60-day-old event from each source and time how long it takes. That’s your real investigation speed.
Where Snare fits
Snare is built for this layer.
Snare Agents collect Windows, Linux and other endpoint and server events — including the authentication, privilege and process events above — at source. Identity, cloud, SaaS, network and security-infrastructure sources feed Snare Central directly via syslog, API and cloud audit feeds, with no agent required.
Snare Central retains a complete copy of that evidence for search, reporting and forensic investigation, independently of any analytics platform.
Snare Reflector routes selected events to the SIEM and other destinations based on the organisation’s own rules. Filtering shapes what each destination receives, not what is kept. Your SIEM detects; your evidence layer makes sure there’s a complete record to investigate.
Key takeaway
Detection tells you something happened. Evidence lets you determine what happened.
Your logging architecture needs to support both.
Do this, this week: Run the 30-minute Evidence Gap Drill . Pick a privileged-account compromise with suspected initial access 60 days ago, try to rebuild the timeline, and record exactly where the investigation stops.
References
- InfoSec World 2026, “From Alert to Evidence: Investigating Enterprise Threats in Natural Language,” Tech Theater, 14 October 2026: https://www.infosecworldusa.com/isw26/session/?iswid=4443726
- InfoSec World 2026, Threat Summit, “From Chasing Alerts to Understanding Attacks,” 12 October 2026: https://www.infosecworldusa.com/isw26/session/?iswid=4236937
- CyberCon 2026 Program, “When cyber plans fail: A pre-mortem approach” and “People, process, technology — who done it? A security architecture investigation,” 14 October 2026: https://melbourne2026.cyberconference.com.au/program
- IBM Security, Cost of a Data Breach Report 2025. Reported in Help Net Security, 4 August 2025: https://www.helpnetsecurity.com/2025/08/04/ibm-cost-data-breach-report-2025/
- Mandiant (Google Cloud), M-Trends 2026, 23 March 2026: https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026
- NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, April 2025: https://csrc.nist.gov/pubs/sp/800/61/r3/final
- ASD’s ACSC, CISA et al., Implementing SIEM and SOAR Platforms: Practitioner Guidance, May 2025, Principle 7: https://www.cyber.gov.au/sites/default/files/2025-05/implementing_siem_and_soar_platforms_-_practitioner_guidance.pdf
- MITRE ATT&CK, T1078 Valid Accounts: https://attack.mitre.org/techniques/T1078/
- PCI Security Standards Council, Payment Card Industry Data Security Standard (PCI DSS) v4.0.1, June 2024, Requirement 10.5.1: https://www.pcisecuritystandards.org/document_library/
