Newsletter Article
One Incident. Many Evidence Planes.
Snare Insider Newsletter Series Article
Make sure you Subscribe
In Week 2, Detection Is Not Investigation showed that evidence rarely lives in one place. In July we argued that identity compromise is as much a correlation problem as a collection problem. And Week 1’s Investigation Gap traced how uncorrelated alerts and unintegrated tools hold SOCs back.
This article picks up where those left off: what it actually takes to join evidence across planes, and where the joins break.
Microsoft’s Digital Defense Report 2026 describes the reward for getting it right: signal cross-correlation can reveal attack patterns that remain invisible when endpoint, identity, cloud, application, email and network telemetry are analysed in isolation.[1] NIST CSF 2.0 states the requirement as DE.AE-03: information is correlated from multiple sources.[2]
Five planes, five sets of joins
Each evidence plane proves something the others can’t. Each one also adds its own identifiers to the chain, and each has its own common point where the join fails.
| Evidence plane | What only it can prove | Join keys it contributes | Where the join commonly breaks |
| Endpoint and server | What ran and who logged on, on the host | SID, logon ID, hostname, source IP | Local accounts with no directory identity; clock drift between hosts |
| Identity | Who authenticated, how, and under which policy | User or service principal object ID, session ID, correlation ID, device ID | Non-interactive and service principal sign-ins kept in separate logs that are not always exported |
| SaaS | What was done inside the application | Application user ID, session context, client IP | A different schema for every application; audit depth tied to licence tier |
| Cloud | Which control-plane and data-plane changes happened | Principal ARN or object ID, request ID, caller IP | Data-plane logging off by default; assumed roles hiding the original identity |
| External trust | What happened on the provider’s side | Provider tenant and user IDs | Access depends on contract, licence and the provider’s response time |
Control plane is not data plane
Cloud evidence comes in two layers, and only one is reliably on by default.
Control-plane events record changes to configuration, such as a role granted, a key created or a policy changed. AWS CloudTrail records management events by default, and the Azure Activity Log records subscription-level operations.
Data-plane events record use, such as an object read, a blob downloaded or a secret retrieved. CloudTrail does not record S3 object-level data events unless a trail is configured to, and Azure resource logs require diagnostic settings.
So the control plane may prove a role was granted at 09:14, while nothing proves what that role read at 09:18. That decision is made before the incident, usually by whoever built the cloud environment rather than whoever will investigate it.
External trust: evidence you don’t hold
The investigation may not stop inside your environment. The World Economic Forum’s Global Cybersecurity Outlook 2026 found 65% of large organisations now cite third-party and supply chain vulnerabilities as their greatest cyber resilience challenge, up from 54% a year earlier.[5] ENISA likewise reports cybercriminals increasingly targeting third-party providers.[6]
Breach data confirms the concern. Verizon’s 2026 Data Breach Investigations Report found that 48% of breaches involved a third party, up from 30% the year before.[7]
When a supplier is part of the incident, some of the chain sits in its environment, under its retention, behind its export API and on its timeline. The NSA and CISA list managed service provider risk among their top ten cloud mitigation strategies for the same reason.[8] Logging requirements belong in third-party assessments and contracts, alongside controls. This week’s exercise tests exactly that.
Collection is not enough
Consider five events:
| Time (UTC) | Event | Evidence plane | Source record |
| 09:02 | User authenticates successfully | Identity | Entra ID sign-in, authenticationProtocol = deviceCode |
| 09:07 | New OAuth permission granted | Identity / OAuth | Entra ID audit: “Consent to application” |
| 09:11 | SaaS mailbox queried | SaaS | Microsoft 365 Unified Audit Log: MailItemsAccessed |
| 09:14 | Cloud role modified | Cloud control plane | Azure Activity Log: roleAssignments/write |
| 09:18 | Sensitive data accessed | Cloud data plane | Storage resource log: GetBlob (only if diagnostic settings were enabled) |
Five legitimate-looking events. Stored separately, in five consoles with five retention periods, they may mean very little. Joined through identity, session and time, they tell a very different story.
An evidence layer built for this needs to answer six questions, and each depends on specific fields being collected and preserved consistently:
| Question | Correlation context required |
| Who? | User principal name, object ID, on-premises SID, service principal or agent ID |
| From where? | Source IP, geolocation, device ID, user agent |
| Using which identity? | Session ID, token or correlation ID, authentication method and protocol |
| Against which system? | Application ID, tenant, account, subscription or resource ID, hostname |
| What changed? | Operation name, target object, old and new values |
| What happened next? | Normalised UTC timestamps across every source |
Week 2 covered why timestamps must be normalised at collection. Across planes, it is what makes “what happened next” a fact rather than an argument.
Don’t confuse correlation with centralisation
Being able to investigate across systems does not mean every event must live permanently in one analytics platform.
Week 2’s Retention Is Not Ingestion separated three decisions: collection → retention → SIEM ingestion.
Week 3 adds a fourth: correlation.
Correlation depends on common context: timestamps, identities, source information, event structure and correlation identifiers. With that context in place, activity can be reconstructed across planes wherever the evidence is stored. Some events need immediate SIEM analysis. Others mainly carry historical or forensic value. The architecture should decide where each belongs based on its value to detection and investigation.
Where Snare fits
For Snare, the changing evidence perimeter reinforces a principle of collection architecture: the evidence layer should follow the investigation, wherever the investigation now goes.
That means two collection paths into one evidence layer:
- Snare Agent collects from endpoints and servers, including domain controllers, where host-level forensic evidence originates.
- Identity, SaaS and cloud audit sources feed Snare Central directly through syslog, API and cloud audit feeds. No agent is required.
Snare Reflector then routes events to the SIEM and other destinations, so teams decide what is analysed where, while a complete raw copy is retained regardless of what is forwarded.
That complements the SIEM rather than competing with it. The SIEM receives what detection needs. The evidence layer keeps what investigation needs, with the identity and time context that lets planes be joined.
Key takeaway
Collection gets you the evidence. Correlation gets you the investigation.
Know which keys join your planes, which data-plane logs are switched on, which retention period ends your investigation first, and what your suppliers can give you. Then decide where each piece of evidence belongs.
Try it this week: test one supplier evidence request, then record what you found in the Security Evidence Coverage Map.
References
- Microsoft, Digital Defense Report 2026 (published 1 October 2026), Key Takeaways, p.8. https://www.microsoft.com/en-us/corporate-responsibility/topics/cybersecurity/reports/microsoft-digital-defense-report/
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024, DE.AE-03. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- Microsoft Learn, Microsoft Entra data retention. https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-reports-data-retention
- Microsoft Learn, Learn about auditing solutions in Microsoft Purview. https://learn.microsoft.com/en-us/purview/audit-solutions-overview
- World Economic Forum with Accenture, Global Cybersecurity Outlook 2026, January 2026. https://reports.weforum.org/docs/WEF_Global_Cybersecurity_Outlook_2026.pdf
- ENISA, ENISA Threat Landscape 2026 (September 2026; reporting period January to December 2025). https://www.enisa.europa.eu/sites/default/files/2026-09/ENISA%20Threat%20Landscape%202026_Final.pdf
- Verizon, 2026 Data Breach Investigations Report (22,000+ confirmed breaches, 145 countries). https://www.verizon.com/business/resources/reports/dbir/
- NSA and CISA, Top Ten Cloud Security Mitigation Strategies, 7 March 2024. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3699169/nsa-releases-top-ten-cloud-security-mitigation-strategies/
