Building a Defense Cybersecurity Stack, Part 3: ICS/OT Defense, Digital Forensics, and Cross-Domain Solutions

Parts 1 and 2 built the IT-side cyber stack. Part 3 covers the disciplines that IT-grade tooling does not address: industrial control systems and operational technology defense, digital forensics readiness for post-compromise analysis, and the cross-domain solutions that move appropriate data between classified enclaves. Each is specialized, each is procurement-relevant, and each is the area where IT-trained engineers most often get it wrong. Part 3 walks through them.

The pillar framing is in The Complete Guide to Defense Cybersecurity. The fusion-side classification machinery this part connects to is in Building a Defense Fusion Pipeline, Part 3; the NATO-coalition releasability discipline is in NATO Interop Implementation, Part 3.

Step 1: Why ICS/OT Defense Is Different from IT

The first mistake IT-trained engineers make on ICS/OT is to apply IT defense patterns directly. The patterns transfer; the values do not. ICS/OT defense is shaped by structural differences that make IT discipline insufficient and sometimes actively harmful.

The structural differences:

• Different protocols. Modbus, DNP3, IEC 61850, OPC UA, BACnet — none of which appear in IT environments. The tooling that decodes IT protocols (HTTP, TLS, SMB, DNS) does not decode these. ICS-specific tooling is required.
• Different patch cadences. An ICS controller may go years between updates — sometimes never. Maintenance windows are scheduled around operational rhythms, not security calendars. "Just patch it" is rarely an option.
• Different consequences. An IT outage costs availability. An ICS outage can have kinetic consequences — power dropped, water flow disrupted, weapon system disabled, logistics interrupted. The blast radius shapes the risk calculus.
• Different vendor landscape. Honeywell, Siemens, Schneider Electric, Rockwell, Yokogawa — each with their own engineering conventions, proprietary protocols, and vendor support contracts. IT vendor relationships do not transfer.
• Different operator culture. ICS operators have engineering backgrounds, not IT-security backgrounds. The security conversation must be technical-engineering, not security-engineering. The vocabulary differs.
• Different scanning policies. A vulnerability scan that an IT SOC considers routine can take a vintage PLC offline. Active scanning is the default in IT; the wrong default in ICS.

The detailed engineering treatment of ICS/OT intrusion detection patterns specific to military networks is in ICS/OT Intrusion Detection in Military Networks.

Step 2: Passive Monitoring as the Default

The ICS/OT defense pattern that works: passive monitoring by default, active response only with extensive operator coordination.

The passive-monitoring architecture:

Network tap or SPAN port collection. The detection sensor sees all ICS network traffic but never injects packets. The sensor cannot affect the controlled process.

Protocol-aware deep packet inspection. The sensor decodes Modbus, DNP3, IEC 61850, OPC UA, identifies the operations being performed, and detects anomalies (unexpected commands, malformed packets, unusual source-destination pairs).

Asset discovery from passive observation. The sensor identifies ICS assets from their network behavior — vendor, model, firmware version, role — without active probing. The asset inventory from Part 1 is enriched with the discoveries.

Behavioural baselining. Over weeks of observation, the sensor builds a baseline of normal ICS behavior. Deviations (commands at unexpected times, sequences not in the baseline, traffic to assets that should not communicate) become alerts.

Operator-driven response. When the sensor detects an anomaly, the response is to alert the operations team, not to take automated action. ICS operators have the context to evaluate whether the anomaly is malicious or operational.

Vendor products that implement this pattern: Dragos Platform, Claroty xDome, Nozomi Vantage, Tenable OT Security. Each has its own protocol-decode strengths; defense procurement evaluates them per the specific OT environment.

Step 3: ICS/OT-Specific Threat Intelligence

ICS/OT threat intelligence is its own discipline. Generic IT CTI feeds (covered in Part 1) miss ICS-specific TTPs: Stuxnet-family techniques, Industroyer variants, TRITON, PIPEDREAM. The dedicated ICS CTI sources:

Dragos WorldView. Industry-leading ICS threat intelligence. Covers nation-state ICS actors (ELECTRUM, XENOTIME, ALLANITE, others) with TTPs and detection content.

CISA ICS-CERT advisories. Public-sector ICS advisories from the U.S. Cybersecurity and Infrastructure Security Agency. Free-to-access, well-curated.

NATO and national CSIRTs. ICS-relevant advisories from NCIRC, BSI, ANSSI, and equivalents — particularly during heightened threat periods.

Vendor security advisories. Each ICS vendor publishes its own. Subscribe; integrate into the CTI pipeline; track patching obligations.

The ICS CTI flows into the OT-specific detection layer separately from the IT CTI. Mixing them dilutes the signal — most IT CTI is irrelevant to OT, and the OT environments cannot consume the IT volume.

Step 4: Digital Forensics Readiness

Detection without post-compromise analysis is half a capability. Defense cybersecurity programs need digital forensics readiness — the engineering investments that enable reconstructing what happened after a compromise.

The forensics readiness components:

Long-retention log aggregation. Nation-state campaigns dwell for months. A SOC retaining 30 days of logs cannot reconstruct an 18-month campaign. The retention budget supports investigation timeframes; tiered storage manages the cost. The Part 2 pipeline architecture must accommodate this.

Deep packet capture where threat-warrant supports it. Selective full-packet capture for high-risk segments. The storage is significant; the value is irreplaceable when a compromise needs network-level reconstruction.

Endpoint telemetry with sufficient depth. Sysmon, EDR-vendor agent, command-line auditing, process-tree capture. Surface telemetry is insufficient for nation-state investigation; depth matters.

Chain-of-custody from collection. Forensic evidence must support legal and accreditation review. Collection procedures, hash verification at every transfer, custody documentation. Evidence collected without chain-of-custody is operationally interesting but legally unusable.

Forensic analysis environment. Isolated analysis network, vetted tooling (Volatility, Autopsy, the SANS DFIR suite), trained analysts. The environment is provisioned in advance, not stood up during the incident.

Reproducible analysis pipelines. Repeatable analyses (memory forensics, malware sandboxing, indicator extraction) are scripted and version-controlled. Manual analyses do not scale and do not survive analyst turnover.

The detailed treatment of military-cyber forensics is in Digital Forensics for Military Cyber.

Step 5: Cross-Domain Solutions

Defense networks are not single enclaves. Data legitimately moves between classification levels — an unclassified threat-intel feed to a SECRET SOC, a releasability-scrubbed incident summary down to a coalition partner, OSINT collected on a low-side network flowing to high-side analysts. These movements happen through cross-domain solutions (CDS).

The CDS landscape:

One-way data diodes. Hardware-enforced unidirectional links. Data flows only in the approved direction (typically high-to-low for releasable products, low-to-high for ingest of public information). Owl Cyber Defense, Forcepoint, Garrison are common vendors.

Cross-domain transfer guards. Software-and-hardware solutions that inspect, sanitize, and pass data between classification levels. More flexible than diodes (bidirectional is possible) but with higher accreditation overhead.

Manual review workflows. Where automation cannot safely decide, human reviewers approve specific data movements. The platform surfaces the candidate, captures the human decision with attribution, and propagates the approved transfer with audit.

The engineering integration:

• The cyber stack integrates with CDS infrastructure, never replaces it. CDS is provided by accredited vendors with national-security-authority approval; building one in-house is rarely justified.
• Per-transfer audit logging. Every cross-domain transfer is logged with attribution, justification, and content reference. The audit log is accreditation evidence.
• Classification verification at the boundary. Data entering the CDS is verified to have appropriate labels (STANAG 4774 per Part 3 of NATO interop series); data exiting is re-verified.
• Bandwidth and latency expectations. CDS adds latency. Operational workflows accommodate the latency rather than fighting it.

Step 6: Network Segmentation Between IT and OT

The Purdue Model is the canonical reference for IT-OT network segmentation. Defense environments often extend it with classification-aware segmentation. The pattern that works:

Level 0-1 (Process and Sensing). The actual physical control — PLCs, RTUs, sensors, actuators. Isolated from IT. No direct IT-side connectivity.

Level 2 (Supervisory Control). Local HMIs and engineering workstations. Connected to Level 0-1; minimally connected up.

Level 3 (Site Operations). Operations databases, batch management, control servers. Where ICS-level systems live.

Level 3.5 (DMZ). The crossing point between OT and IT. All IT-OT communication goes through here, with explicit data-flow policies and detection.

Level 4-5 (Enterprise IT). Standard IT environment. Where the SIEM/SOAR from Part 2 mostly operates.

Defense extensions add classification-level segmentation orthogonal to the Purdue levels: an unclassified OT network for facility infrastructure, a NATO-RESTRICTED OT network for coalition exercise infrastructure, a national-classified OT network for weapon-platform OT. Each is its own segmented environment with its own cross-domain solutions where data needs to flow.

Step 7: ICS/OT Incident Response Coordination

When an ICS incident occurs, the response is multi-party. IT-side incident response handles the IT components; OT operators handle the operational components; safety engineers handle physical-process risk; legal handles regulatory reporting (which has specific timelines for ICS in some jurisdictions); leadership coordinates the public messaging.

The engineering investments that support this coordination:

Pre-established playbooks. ICS-specific incident playbooks, exercised periodically, that name the roles and the communication paths. The playbook is in the repository, version-controlled, reviewed annually.

Tabletop exercises. Annual or semi-annual exercises that walk through ICS incident scenarios. Surface gaps in playbooks, communication paths, technical capabilities. The detailed C2-testing discipline that informs this practice is in Testing Mission-Critical C2 Systems.

Cross-team training. IT SOC analysts who never see OT environments cannot respond effectively to OT incidents. Cross-training, OT-environment familiarization, joint exercises.

Vendor escalation paths. Pre-established support relationships with the ICS vendors. During an incident is not the time to discover the support relationship is contractual-only.

What's Next

Part 3 has covered the specialized layers. ICS/OT defense with passive monitoring as default, dedicated OT threat intelligence, digital forensics readiness with long retention and chain-of-custody, cross-domain solutions for inter-enclave data flows, Purdue-model network segmentation, ICS incident-response coordination.

Part 4 closes the series with the engineering-pipeline and architectural disciplines: DevSecOps generating accreditation evidence as a side effect, zero-trust military networks, SBOM and supply-chain integrity, ISO 27001 and AQAP-2110 alignment, and the continuous compliance posture that keeps the cyber stack accredited across 15-20 year operational lifetimes.