# SIEM Architecture
A Security Information and Event Management (SIEM) platform is the central aggregation, correlation, and analysis system for security telemetry across an organization's entire IT environment. It collects log data from endpoints, network devices, cloud platforms, identity providers, applications, and security tools, normalizes that data into a common format, applies detection rules to identify suspicious patterns, and generates alerts for analyst investigation.
SIEM is the central nervous system of the TID (Threat Intelligence and Defense) domain. It does not block attacks. It detects them. It provides the visibility that enables human analysts and automated response systems to identify, investigate, and respond to threats. An organization without a SIEM is an organization operating without centralized security visibility: each system generates its own logs in its own format, and no mechanism exists to correlate events across systems to detect multi-stage attacks.
The SIEM market includes both legacy platforms (Splunk, IBM QRadar, LogRhythm) and cloud-native platforms (Microsoft Sentinel, Google Chronicle, Elastic Security, Sumo Logic). The distinction matters architecturally: legacy SIEMs typically require on-premises infrastructure and license by data volume (creating cost pressure to limit log ingestion), while cloud-native SIEMs operate on elastic infrastructure with more flexible pricing models. The operational principles, log collection, normalization, correlation, and alerting, are the same regardless of platform.
SIEM effectiveness begins with data collection. The platform must ingest logs from every security-relevant source in the environment. Common log sources:
Endpoints. EDR telemetry (process execution, file modification, network connections), operating system event logs (Windows Security Event Log, Linux syslog/auditd), antivirus/anti-malware events.
Network. Firewall logs (traffic allowed/denied, connection metadata), IDS/IPS alerts, DNS query logs, proxy logs (URL access, content filtering events), NetFlow/IPFIX (network traffic metadata), VPN connection logs.
Identity. Active Directory / Entra ID authentication events (successful, failed, MFA challenges), identity provider logs (Okta, Google Workspace), privileged access management logs (session recordings, credential checkouts).
Cloud. Cloud platform audit logs (AWS CloudTrail, Azure Activity Log, GCP Audit Logs), cloud workload logs, SaaS application logs (Microsoft 365, Google Workspace, Salesforce), container orchestration logs (Kubernetes audit logs).
Security tools. DLP events, email security events (phishing detections, malware attachments blocked), vulnerability scanner results, threat intelligence feed matches.
Applications. Application-level logs for critical business applications (ERP, CRM, financial systems), web server access logs, database audit logs.
The completeness of log collection directly determines the completeness of detection coverage. Every log source that is not connected to the SIEM is a detection blind spot. CDA's TID-R03 mission (Log Source Inventory, 12 hours) specifically enumerates every log source in the environment and identifies which are connected to the SIEM and which are gaps.
Raw logs arrive from dozens of sources in dozens of formats. Windows event logs use XML. Firewall logs use syslog with vendor-specific fields. Cloud audit logs use JSON with platform-specific schemas. The SIEM's normalization engine translates all of these into a common data model so that a "failed authentication" event means the same thing whether it originated from Active Directory, Okta, an AWS console login, or a VPN concentrator.
Normalization enables cross-source correlation: detecting an attack that spans multiple systems requires comparing events from those systems using a common vocabulary. Without normalization, "Event ID 4625" (Windows failed logon) and "Authentication Failed" (Okta) and "ConsoleLogin: Failure" (AWS CloudTrail) are three unrelated events. After normalization, they are three instances of the same event type, correlatable by user identity, source IP, and time window.
Detection rules define what patterns the SIEM flags as suspicious. Rules range from simple (single-event matches) to complex (multi-event correlations across time windows and data sources).
Single-event rules. Alert on a specific event: a user account added to the Domain Admins group, a new service installed on a server, a firewall rule change, a DLP policy violation. These rules catch specific actions that are always suspicious regardless of context.
Threshold rules. Alert when an event exceeds a frequency threshold: more than 50 failed login attempts against a single account in 5 minutes (brute force), more than 100 DNS queries to a newly registered domain in 1 hour (potential C2 communication), more than 10 DLP alerts from a single user in a day (potential data staging).
Correlation rules. Alert when multiple events from different sources occur in a pattern that indicates an attack chain. A successful VPN login from an unusual geography (identity log), followed by access to a file server the user has never accessed before (file server log), followed by a large data transfer to an external IP (network log), correlated within a 30-minute window. No individual event is alarming. The pattern is.
Behavioral rules (UEBA). Machine learning models establish baseline behavior for each user and entity, then alert on deviations. A user who normally accesses 3 applications during business hours suddenly accessing 15 applications at 2 AM. A service account that normally authenticates from 2 servers suddenly authenticating from 20. Behavioral rules detect threats that no predefined rule anticipated because the detection is based on deviation from normal, not on matching a known pattern.
Detection rules generate alerts. Alerts require triage: an analyst evaluates each alert to determine if it represents a true threat (true positive), a benign event that matches a suspicious pattern (false positive), or an event that needs additional investigation to determine.
Triage quality depends on alert quality. A SIEM that generates 5,000 alerts per day with a 95% false positive rate produces 250 true positives buried in 4,750 false alarms. Analysts processing this volume experience alert fatigue: their detection accuracy degrades over time as the cognitive burden of evaluating each alert accumulates. The critical alert at hour eight of a 12-hour shift looks identical to the 400 false positives that preceded it.
Reducing false positives through rule tuning, suppression of known-benign patterns, and enrichment (adding context from threat intelligence, asset inventory, and user identity to each alert) is the operational discipline that separates a functioning SIEM from a noise machine.
Security Orchestration, Automation, and Response (SOAR) platforms extend the SIEM by automating response workflows. When a SIEM alert fires, a SOAR playbook can automatically enrich the alert (query threat intelligence for the source IP, check the user's recent activity, verify the endpoint's EDR status), execute containment actions (disable the user account, isolate the endpoint, block the IP at the firewall), and create an incident ticket with all context pre-assembled for analyst review.
SOAR does not replace analysts. It reduces the time between detection and response by automating the repetitive steps that analysts perform manually for every alert. A SOAR-automated workflow can enrich and contain a credential compromise alert in 30 seconds. A human analyst performing the same steps manually takes 15 to 30 minutes. When dwell time is measured in hours and days, 30 seconds versus 30 minutes is the difference between containment and catastrophe.
Without a SIEM, security visibility is fragmented. The firewall team sees firewall logs. The endpoint team sees EDR alerts. The identity team sees authentication events. The cloud team sees cloud audit logs. Nobody sees the complete picture. A multi-stage attack that traverses firewall, endpoint, identity, and cloud (as most sophisticated attacks do) is invisible to any single team. Only the SIEM, which aggregates all sources, can detect the attack chain.
Advanced attackers (state-sponsored APT groups, sophisticated ransomware operators) specifically design their operations to evade individual security controls. They use living-off-the-land techniques (legitimate tools, no malware to detect). They move slowly (staying under threshold-based alert triggers). They compromise legitimate credentials (bypassing authentication controls). The only detection mechanism for these attacks is behavioral correlation across multiple data sources: the SIEM.
Multiple compliance frameworks mandate centralized logging and monitoring. PCI DSS Requirement 10 (Log and Monitor All Access to System Components and Cardholder Data) specifically requires centralized log collection, retention, and monitoring. NIST CSF 2.0 DE.CM (Continuous Monitoring) and DE.AE (Adverse Event Analysis) describe SIEM capabilities. ISO 27001 A.8.15 (Logging) and A.8.16 (Monitoring Activities) require log collection and analysis. SOC 2 CC7.2 (Monitor System Components for Anomalies) is typically satisfied through SIEM operations.
Beyond compliance checkboxes, SIEM provides the audit trail that reconstructs security events after the fact. When a breach occurs and regulators, insurers, and legal counsel ask "what happened," the SIEM log archive is the evidentiary record that answers the question.
SIEM is the primary operational platform in the TID (Threat Intelligence and Defense) domain of the Planetary Defense Model. It is the atmospheric sensor network: the equivalent of weather stations, radar installations, and satellites that detect threats before they reach the surface.
CDA's Predictive Defense Intelligence (PDI) methodology operates through the SIEM as its primary engine. "See the threat before it sees you." The SIEM provides the raw visibility. Detection engineering (TID-H01) transforms that visibility into actionable alerts. Threat intelligence integration (TID-B03) provides the context that distinguishes targeted attacks from background noise. Threat hunting (TID-H03) uses the SIEM's historical data to search for threats that automated rules missed.
The Roman parallel is the cursus publicus: Rome's imperial communications network of relay stations spaced along major roads. The cursus publicus aggregated information from across the empire and transmitted it to the capital faster than any individual messenger could travel. The SIEM aggregates telemetry from across the environment and presents it to analysts faster than any individual log review could accomplish. The cursus publicus was Rome's SIEM, built with horses and relay stations instead of APIs and log collectors.
TID-B01 (SIEM Deployment and Tuning) is the highest-hour single mission in the entire PDM at 60 estimated hours. This reflects the operational reality: SIEM deployment is not a product installation. It is an integration project that requires connecting dozens of log sources, normalizing data formats, writing and tuning detection rules, configuring alert thresholds, building dashboards, establishing triage procedures, and validating that the system detects real threats without drowning analysts in noise.
CDA approaches SIEM differently from conventional vendors and MSSPs in one specific way: we measure SIEM effectiveness by detection coverage against the MITRE ATT&CK framework, not by log volume ingested or alerts generated. A SIEM that ingests 500GB per day and generates 3,000 alerts but detects only 15% of ATT&CK techniques is less effective than a SIEM that ingests 100GB per day and generates 200 alerts but detects 60% of ATT&CK techniques. Coverage matters. Volume does not.
TID-R02 (Detection Coverage Assessment, 16 hours) maps the organization's current detection capability against the ATT&CK matrix, identifying which techniques can be detected and which are blind spots. This assessment transforms the abstract question "is our SIEM working?" into the quantified answer "we detect 47 of 201 ATT&CK techniques, and here are the 154 gaps ranked by likelihood of encounter."
Additional connected missions: TID-R03 (Log Source Inventory) ensures the data foundation is complete. TID-H01 (Detection Engineering Program) establishes the continuous practice of writing, testing, and refining detection rules. TID-H02 (SOAR Playbook Automation) extends the SIEM with automated response. TID-D02 (Purple Team Exercise) validates the SIEM's detection capability against real attack simulations.
Word count: 2,089