Building a Defense Cybersecurity Stack, Part 2: SIEM/SOAR for Classified Enclaves

Part 1 built the intelligence foundation. Part 2 implements the operations layer that consumes that intelligence: SIEM aggregates and correlates telemetry, SOAR automates response, both wired into the classified-enclave network topology that defines defense cybersecurity. Commercial SIEM and SOAR products exist; engineering them for defense deployment is where most programmes underestimate the work. Part 2 walks through what that work actually looks like.

The pillar-level framing is in The Complete Guide to Defense Cybersecurity; the deeper SIEM/SOAR engineering details in SIEM and SOAR for Military Integration.

Step 1: Per-Enclave Deployment Architecture

The single most consequential architectural decision: do not run one SIEM instance across multiple classification levels. Each classified enclave runs its own SIEM/SOAR stack with its own data store, its own detection content, its own audit log. The stacks are physically separated; data movement between them goes through accredited cross-domain solutions, never through shared infrastructure.

The reasoning is structural: SIEM data is a classification superset of the sources it ingests. A SIEM aggregating SECRET network logs holds SECRET-classified content; merging that store with UNCLASSIFIED administrative logs would inadvertently raise the administrative store's classification through the SIEM's aggregation effect. Per-enclave isolation prevents this.

The deployment pattern for the running example:

• UNCLASSIFIED SIEM — administrative networks, internet-facing assets, vendor management. Vendor-supplied SaaS may be acceptable here.
• NATO RESTRICTED SIEM — coalition mission networks, FMN-attached infrastructure. Self-hosted on accredited infrastructure; vendor SaaS rarely acceptable.
• NATO SECRET SIEM — operational classified networks. Self-hosted; air-gapped from internet; updates through controlled channels.
• National-classified SIEM — national systems at higher classification. Single-source vendors that have national accreditation; bespoke deployment.

Cross-enclave intelligence sharing flows through CTI propagation (Part 1 mechanism) and through controlled summary reports — not through shared SIEM dashboards.

Step 2: The Log Aggregation Pipeline

SIEM is, structurally, a log pipeline with detection layered on top. Get the pipeline right and detection becomes tractable; get it wrong and the pipeline cost dominates everything else.

The pipeline stages:

Collection. Agents on endpoints (Sysmon on Windows, auditd on Linux, EDR-vendor agents), network sensors (NDR products, IDS appliances, NetFlow collectors), application logs (custom format and Syslog), cloud-control-plane logs (where cloud is in scope), OT telemetry (Part 3 of this series).

Normalization. Heterogeneous source formats normalized to a common schema. Elastic Common Schema (ECS), the OCSF, vendor-specific schemas — pick one and align. Schema mismatches in production are a recurring source of detection misses.

Enrichment. Add context the raw log lacks: asset classification from the inventory (Part 1), CTI tags from the intelligence pipeline, user-attribute context from identity systems, geolocation, threat-actor association.

Routing. Events flow to the SIEM's hot tier for live correlation, to long-term cold storage for forensic retention, and selectively to the SOAR for playbook triggering. Routing rules are explicit policy.

Retention. Defense cybersecurity has long-retention requirements — nation-state campaigns dwell for months or years. The pipeline supports tiered retention: hot (live correlation), warm (recent forensic queries), cold (long-term archival). Retention budgets are programme decisions; under-budgeting forces premature data deletion.

Step 3: Detection Content as Code

SIEM out-of-the-box detection rules catch commodity threats. Defense-grade detection catches nation-state threats. The gap is detection content: rules tailored to the asset inventory, the threat model, and the CTI pipeline.

The discipline of detection-content-as-code:

Sigma rules as the source format. Sigma is the vendor-neutral detection rule format; rules written in Sigma convert to Splunk, Elastic, Sentinel, QRadar, and others. Writing in Sigma keeps the detection portable; vendor-specific tuning happens at deployment.

Per-asset and per-threat-actor rules. Generic "PowerShell encoded command" detection catches noise. "PowerShell encoded command on a NATO SECRET host from a user not in the engineering OU" is signal. The asset inventory and threat model inform the rule's specificity.

CI testing against captured event data. Detection rules are unit-tested in CI. Captured event traces from prior incidents and red-team exercises serve as ground truth. A rule change that no longer detects the captured incident is a regression that blocks the merge.

MITRE ATT&CK mapping. Every rule maps to one or more ATT&CK techniques. The mapping enables coverage analysis (which techniques are well-covered, which are blind spots) and procurement-grade reporting on the platform's defensive posture.

False-positive management. Rules produce alerts. Alerts produce SOC workload. The discipline of FP tuning — measuring per-rule FP rate, refining rules to reduce noise, retiring rules that cannot be tuned — is structural. SOCs that drown in FPs miss the TPs.

Step 4: SOAR Playbook Engineering

SOAR (Security Orchestration, Automation, and Response) automates the response to detected events. A playbook is a versioned, tested, reviewable workflow that the SOAR executes on alert.

The playbook discipline:

Versioned in source control. Playbooks are code — YAML, JSON, vendor-specific DSLs. They live in the repository alongside detection rules, are reviewed before deployment, and roll out through the same change-control process as application code.

Tested in CI. Captured incident traces serve as test inputs. A playbook that no longer executes correctly against the captured trace blocks the merge.

Human-confirmation gates for consequential actions. SOAR can isolate a host, disable a user account, block a network range, terminate a process. Each of these has operational consequences. The playbook surfaces the proposed action and requires explicit human confirmation; the human's decision is logged.

Audit trail for every automated action. Even actions that complete without human review (alert enrichment, ticket creation, threat-intelligence lookup) are logged. The audit trail is the evidence base for after-action review.

Rollback paths. A SOAR action that was wrong — wrong host isolated, wrong user disabled — must be reversible. The playbook engineering accommodates this from the start; retrofitting reversal is bespoke per-action work.

Step 5: Cross-CERT Integration

Defense cybersecurity exists in a community. National CERTs (CISA, BSI, ANSSI, CCN-CERT), military-specific CSIRTs (US-CERT, NCSC, JCDC), coalition CSIRTs (NATO NCIRC), partner CSIRTs. The platform integrates with this community bidirectionally.

The integration patterns:

Inbound intelligence consumption. CERT advisories flow into the CTI pipeline (Part 1) and trigger detection-rule updates. Time-sensitive advisories (active vulnerability exploitation, ongoing campaign attribution) get priority handling.

Outbound incident reporting. Confirmed incidents — particularly those involving nation-state TTPs or coalition-relevant indicators — flow outbound to the appropriate CERT through STIX/TAXII or formal incident-report channels. The reporting respects classification: NATO SECRET incidents go to NCIRC, not to a commercial vendor.

Joint hunting. Periodic threat-hunting collaborations with partner CERTs — running queries across multiple national environments, looking for adversary TTPs that surface only in aggregate. Joint hunting is operationally valuable and politically complex; the platform's audit trail supports the legal-and-policy review.

Exercise participation. Locked Shields, Cyber Coalition, Crossed Swords — NATO and partner cyber exercises that test cross-CERT coordination. Participation is procurement-grade evidence of capability.

Step 6: Performance and Scale Targets

SIEM/SOAR targets that distinguish operational platforms from prototypes:

• Log ingestion sustained at the operational rate (typically 50K–500K events/second for a national defense deployment), with surge handling at 5× baseline.
• Detection latency under 60 seconds from event arrival to alert generation for time-sensitive rules; under 5 minutes for correlation-heavy rules.
• Playbook execution latency under 30 seconds for the human-review handoff; full playbook completion within minutes for automated paths.
• Storage retention measured in years for high-classification environments; tiered to manage cost.
• Query performance under 30 seconds for typical analyst queries on hot data; under 5 minutes for cold-data queries.
• Availability at 99.9%+ for hot-tier components; degraded operation acceptable on cold-tier failures.

Missing these targets is usually the result of architectural shortcuts (under-provisioned ingest, mis-routed indices, naive query patterns). Programmes that prototype against these targets explicitly catch the shortcuts before operational deployment.

Step 7: Vendor Selection for Defense Deployment

The defense-deployable SIEM/SOAR vendor list is smaller than the commercial list. The criteria:

Accreditation track record. Vendors with prior accreditation in NATO or member-state classified networks have evidence accreditation reviewers find credible. Cold-start with an unaccredited vendor adds 12-24 months to deployment.

Air-gapped deployability. The vendor's deployment must work in environments with no internet egress for updates, threat-intel feeds, or telemetry. Cloud-only products are out for higher classifications.

ITAR-free positioning for European programmes. See ITAR-Free Defence Software for the criteria. European deployments increasingly prefer ITAR-free vendors.

Detection-content portability. Sigma support (or comparable vendor-neutral format) keeps the platform's detection content portable across vendor transitions. Vendor lock-in on detection content is a strategic risk.

Open APIs. The SIEM/SOAR integrates with everything else in the cyber stack — CTI platform, EDR, network sensors, identity systems, ticketing. Open APIs are non-negotiable.

The detailed vendor-selection criteria for defense software broadly are in How to Choose a Defense Software Vendor.

What's Next

Part 2 has built the operations layer. Per-enclave SIEM/SOAR architecture, log aggregation pipeline, detection content as code, SOAR playbook discipline, cross-CERT integration, performance targets, vendor selection. The stack now detects and responds at scale within the classified-enclave architecture.

Part 3 covers the specialized layers: ICS/OT defense for the operational technology that IT-grade tooling does not address, digital forensics readiness for post-compromise analysis, and the cross-domain solutions that move appropriate data between enclaves while preventing inappropriate flows.