Architecture · Security Architecture
Security Monitoring Architecture
A design for collecting, normalising, retaining and analysing security telemetry across identity, endpoint, network, cloud and application layers.
AdvancedUpdated 2026-09-01
Overview
The architecture defines which sources are collected, how they reach the platform, how long they are retained in each tier, which detections run, and how alerts become owned cases with response authority.
Coverage should be planned against attack techniques, not against available connectors. The question is which techniques would be invisible today, and which source would make them visible.
Sequence
- 1Sources
- 2Collectors / agents
- 3Normalisation & enrichment
- 4Detection analytics
- 5Case management
- 6Response actions
- 7Detection tuning
Layer model
Sources
Identity sign in and auditEDR telemetryEmail security eventsDNS and proxyFirewall and flow logsCloud control planesSaaS audit logsApplication logs
Platform
Ingestion and parsingHot searchable tierArchive tier for investigationThreat intelligence enrichmentEntity and asset context
Operations
Detection catalogue mapped to ATT&CKTriage runbooksAutomation for enrichmentOn call and escalationCoverage and gap reporting
Design considerations
- Decide retention per source based on investigative value and cost, and document the decision.
- Protect log integrity with restricted deletion and alerting on source silence.
- Include the security platform's own audit trail in monitoring scope.
Security considerations
- Isolate the logging pipeline from the environment it monitors where possible, so a compromise cannot erase evidence.
- Restrict SIEM access; it aggregates sensitive data from every system.
Failure points
- Single collector or forwarder
- Ingestion caps silently dropping data
- Time skew across sources
- Alerts with no owner