SIEM and SOAR Integration for Military Networks: What Defense Teams Need

Security Information and Event Management (SIEM) and Security Orchestration, Automation and Response (SOAR) are the operational heart of a modern Security Operations Center (SOC). In commercial environments, deploying them is a matter of vendor selection, integration effort, and operational discipline. In military and defense environments, the same deployment requires navigating classification boundaries, air-gap constraints, multi-level security (MLS) data handling, and latency requirements that commercial security tools were not designed to meet.

This article examines what SIEM and SOAR integration looks like when deployed in a military context — what log sources feed the platform, how automated response playbooks must be designed to accommodate human approval requirements for high-impact actions, and what the architectural differences are between classified and unclassified network deployments.

SIEM Fundamentals in a Military Context

A SIEM aggregates log and event data from across the network, normalizes it into a common schema, and applies correlation rules that detect patterns indicative of security incidents. The value proposition is straightforward: no single log source tells the complete story of an attack, but the correlation of logs from multiple sources — network, endpoint, application, identity — can reveal the full attack chain.

Network log sources include firewall logs (connection accept/deny, port scans, geolocation anomalies), router and switch logs (routing table changes, spanning tree events), DNS query logs (beaconing patterns, domain generation algorithm detection, newly registered domains), proxy logs (URL categorization, file download events, protocol anomalies), and intrusion detection system (IDS) alerts from both network-based sensors and host-based agents.

Endpoint log sources feed from Windows Event Logs (authentication events, process creation, scheduled task creation, registry modifications, PowerShell execution), Linux auditd logs (syscall auditing, privilege escalation, file access), and endpoint detection and response (EDR) agents such as Microsoft Defender for Endpoint, CrowdStrike Falcon, or SentinelOne. In classified environments, EDR selection is constrained by accreditation status — not all commercial EDR products are approved for classified network deployment.

Application log sources include authentication systems (Active Directory/LDAP authentication events, Kerberos ticket requests, SAML assertions), email gateways (attachment analysis, link click events, spoofing detection), web application firewalls, and custom defense application logs. In military environments, physical access control systems — card readers, biometric gates — are increasingly integrated as log sources, providing physical-cyber correlation capability.

SIEM platform selection for defense environments is constrained by two factors: classification support and deployment model. Splunk Enterprise (not Splunk Cloud) is widely deployed in classified environments because it can run as an on-premises installation with no cloud dependencies. IBM QRadar similarly supports on-premises classified deployment. Elastic Security (the Elastic SIEM capability built on the Elastic Stack) is increasingly used in defense environments, particularly where cost and licensing flexibility are priorities. All three support air-gapped deployment — a hard requirement for networks handling classified data.

SOAR: Playbook Design for Military Use Cases

SOAR extends SIEM by automating the response workflow — not just detecting an incident, but taking action. The scope of automated action is where military deployments diverge most significantly from commercial ones. In a commercial SOC, fully automated containment — blocking an IP at the firewall, isolating a workstation from the network — is acceptable for high-confidence detections. In a military environment, automated containment actions can have operational consequences that are unacceptable without human review.

Consider a scenario: an endpoint on a tactical network shows indicators consistent with credential theft. In a commercial environment, automated SOAR would isolate the endpoint immediately and notify the analyst. In a military environment, that endpoint might be the only communications terminal for a forward operating unit. Isolating it without human review could disrupt an active mission. The playbook design must account for this.

Human approval gates are mandatory in military SOAR playbooks for any action that affects operational capability. This means the playbook design follows a tiered model: low-impact automated actions (enriching an alert with threat intelligence, creating a ticket, notifying the on-call analyst) proceed automatically. Medium-impact actions (blocking a domain at the DNS gateway, disabling a user account pending investigation) may be automated with a 15-minute notification window for operator override. High-impact actions (isolating a network segment, revoking a privileged account, quarantining an endpoint) require explicit human approval before execution — and that approval must come from an operator with the appropriate authority level.

Playbook platforms suitable for classified environments include Palo Alto XSOAR (formerly Demisto), IBM Resilient, and open-source alternatives such as TheHive/Cortex. Integration between the SOAR platform and the SIEM is typically via REST API, with the SOAR consuming SIEM alerts and the SIEM receiving case enrichment and action audit trails back from the SOAR.

Air-Gapped SIEM Deployment

An air-gapped SIEM deployment — where the SIEM infrastructure has no internet connectivity — is the baseline for any classified network environment. This introduces operational challenges that commercial deployments do not face.

Threat intelligence updates cannot be fetched automatically from vendor cloud services. MISP (Malware Information Sharing Platform) or a commercial CTI platform deployed on the same isolated network must serve as the intelligence source. Threat intelligence from external sources enters via a data diode or an approved cross-domain solution (CDS), not via internet connection. The cadence of intelligence updates is slower — instead of real-time feed updates, intelligence may be delivered in daily or weekly bundles — which must be accounted for in detection coverage analysis.

Software updates and rule packs for the SIEM itself must be transferred via approved removable media (typically an approved USB or optical media workflow) or through the organization's patch management infrastructure. Keeping the SIEM's detection content current — vendor-provided correlation rules, community detection rules such as Sigma — requires a disciplined content management process.

Licensing in air-gapped environments is a practical consideration that is often overlooked in architecture planning. Splunk licensing in air-gapped environments requires offline activation tokens. QRadar and Elastic use different license models; verifying that the chosen platform's licensing does not require internet connectivity for validation is a pre-deployment requirement.

Automated Response to Known IOCs: Detection to Isolation Chain

The most common SOAR automation use case in military environments is automated response to known indicators of compromise (IOCs). The workflow demonstrates how SIEM and SOAR integrate in practice.

Detection: The SIEM receives a DNS query log from the network's recursive resolver. The queried domain matches an entry in the IOC database (a known command-and-control domain associated with a state-sponsored threat actor). The SIEM correlation rule fires, generating an alert with severity HIGH and a reference to the IOC source and confidence level.

Enrichment: The SOAR playbook receives the alert via API. It automatically queries the CTI platform for additional context on the domain: registration date, registrar, passive DNS history, associated IP addresses, related campaigns. It also queries the SIEM for the internal IP that issued the DNS query and retrieves the asset's classification (workstation, server, tactical terminal) and owner (unit, role).

Triage decision: The playbook evaluates the enrichment results against a decision matrix. If the IOC has high confidence, the internal asset is a standard workstation (not operationally critical), and no conflicting operational status is flagged, the playbook escalates to a human analyst with a pre-populated incident ticket containing all enrichment context and a recommended action (isolate endpoint).

Human approval and action: The analyst reviews the ticket, confirms the isolation action, and the SOAR executes: it sends an API call to the EDR platform to isolate the endpoint from the network, places the IOC in the DNS sinkhole blocklist, and creates an evidence preservation task (memory dump and disk image request). All actions are logged with operator identity, timestamp, and authorization reference.

Classification-Aware Logging in Shared SIEM

Many military organizations operate multiple networks at different classification levels — an unclassified administrative network, a SECRET-level operational network, and potentially higher. In some architectures, a shared SIEM monitors all of them. This creates a multi-level security (MLS) problem: log data from the SECRET network must not be visible to analysts with only unclassified clearance.

Data segregation approaches include deploying separate SIEM instances per classification level (architecturally simple, but expensive and operationally burdensome — analysts must context-switch between platforms), using a single SIEM with strict role-based access controls and data tagging (complex to implement correctly, but operationally efficient), or using a hierarchical SIEM architecture where classified SIEM instances forward sanitized, downgraded alerts to an unclassified master dashboard via a one-way CDS.

Event log classification marking must be applied at ingestion. A log event from a SECRET-network endpoint must carry its classification marking through the entire SIEM processing pipeline — normalization, indexing, correlation, alert generation, and case management. If the SIEM does not natively support classification labels as a first-class data attribute, classification marking must be implemented through field-level tagging conventions and enforced through role-based index access controls.

The practical implementation in Splunk uses index-level access controls: events from classified sources are ingested into restricted indexes, and only roles with the appropriate clearance mapping have search access to those indexes. In Elastic, document-level security (DLS) and field-level security (FLS) can be configured to restrict access at the document level within a shared index — though index separation is architecturally simpler and less prone to misconfiguration.

Audit logging of all analyst queries against classified SIEM indexes is mandatory — not just for security, but to satisfy compliance requirements. Who searched what, when, and from which workstation must be recorded and protected as audit evidence.