OT-Security-Lab: Integrated Industrial Control System (ICS) Security Environment

Category	Specification
Industry	Water Treatment & Filtration
Frameworks	IEC 62443, MITRE ATT&CK for ICS, ISA-95 Purdue Model
Environment	5-Zone Segmented Docker Lab with L3/L4 Firewall
Monitoring	Protocol-Aware (Modbus/TCP) Anomaly detection
Evidence	Verified Attack Simulation Logs

Project Overview

This repository contains a full-scale, simulated industrial environment designed to demonstrate the implementation of robust security controls within an Operational Technology (OT) context. The project encompasses the entire lifecycle of an IT/OT Security Engineer's responsibilities: from architectural design and network segmentation based on the Purdue Model, to threat modeling, detection engineering, and IEC 62443 compliance mapping.

The lab simulates a Water Treatment & Filtration Facility, facilitating a hands-on platform for validating security configurations and detection rules against realistic ICS attack vectors.

---

2. Architecture: The Purdue Model

The environment is segmented into logical levels according to the ISA-95 Purdue Model, ensuring strict isolation of critical control processes.

graph TD
    %% Level Definition
    subgraph L4_5 ["Level 4 & 5: Enterprise"]
        A[Attacker Simulation]
        B[Corporate Workstation]
    end

    subgraph DMZ ["Industrial DMZ"]
        JH[Jump Host / Bastion]
        RP[Reverse Proxy]
    end

    subgraph L3 ["Level 3: Operations"]
        C[Historian - InfluxDB]
        D[Engineering Workstation]
    end

    subgraph L2 ["Level 2: Supervisory"]
        E[SCADA / HMI Server]
    end

    subgraph L1 ["Level 1: Control"]
        F1[PLC-01: Intake]
        F2[PLC-02: Treatment]
        F3[PLC-03: Distribution]
    end

    subgraph L0 ["Level 0: Field Devices"]
        G[Sensors/Actuators]
    end

    %% Conduits
    B ---|VPN/HTTPS| JH
    JH ---|RDP/SSH| D
    D ---|S7/Modbus| F1
    E ---|Modbus/TCP| F1
    E ---|Modbus/TCP| F2
    E ---|Modbus/TCP| F3
    F1 ---|Process Flow| F2
    F2 ---|Process Flow| F3
    F3 ---|Hardwired| G

    %% Styling
    style DMZ fill:#fff2cc,stroke:#d6b656,stroke-width:2px
    style L1 fill:#fdb,stroke:#333,stroke-width:2px

Loading

Purdue Levels Mapping:

• Level 4/5 (Enterprise): Corporate LAN, Attacker Simulation, External Monitoring.
• Industrial DMZ: Broker for remote access (Jump Host) and data visualization (Proxy).
• Level 3 (Operations): Historian (InfluxDB) and the segregated Engineering Workstation (EWS).
• Level 2 (Supervisory): Centralized SCADA/HMI (Scada-LTS) for plant-wide visibility.
• Level 1 (Control): Distributed Control via three PLCs (Intake, Treatment, Distribution).
• Level 0 (Field): Physical process assets (Valves, Pumps, Flow Meters).

---

3. Table of Contents

1. Architecture & Design
   • Network Segmentation (Zones & Conduits)
   • Architecture Decision Records (ADR)
2. Lab Environment
   • Deployment & Validation Guide
   • Docker Compose Setup
3. Asset Inventory
   • Master Asset List
   • Inventory Schema
4. Threat Model & Risk Analysis
   • Threat Landscape
   • MITRE ATT&CK for ICS Mapping
5. Detection & Monitoring

* [Modbus Anomaly Detection](./detection/rules/modbus_anomaly.py)
* [**Physics-Aware Safety Monitor**](./detection/rules/process_safety_violation.py)
* [Cross-Zone Traffic Alerter](./detection/rules/cross_zone_traffic.py)
*   [Brute Force Detection](./detection/rules/ot_brute_force.py)
*   [**Live Detection Evidence (JSON Logs)**](./detection/logs/alerts.json) — refreshed automatically by the Compliance Gate on every green run

6. Hardening & Compliance
   • Security Hardening Checklist
   • IEC 62443 Gap Analysis
7. Incident Response
   • PLC Unauthorized Change Playbook
8. Engineering Post-Mortem

Integrated SIEM Dashboard (Loki & Grafana)

Forensic Log Analysis (MITRE ATT&CK Mapping)

---

4. Governance, Risk & Compliance (GRC)

To bridge the gap between technical implementation and industrial standards (Exceltic/ISA-62443 requirements), this lab includes formal documentation:

• Asset Inventory (LDR Style): A complete map of the lab's hardware and network footprints.
• Incident Response Playbook: "Safety-First" response procedures for industrial security events.
• Hardening Guide (STIG): Mandatory security baselines for both Gateway and PLCs.
• Verification Test Plan: Formal mapping of simulations to security requirements (V&V).
• Risk Register & BIA: Full risk register (12 scenarios) and business impact analysis with RTO/RPO.
• Remediation Roadmap: Prioritized findings-to-fix mapping with effort estimates.
• Standards Coverage: NIST SP 800-82, ISO 27019, NIS2, C2M2, SIS/BPCS separation, remote-access design.
• Policies & Procedures: Access control, change management (MOC), remote access, backup/DR drafts.
• Assessment Methodology: Scoping questionnaire, discovery checklist, findings template.
• Executive Package & Tabletop Kit: Board-level brief and IR exercise materials.
• To-Be Architecture: Phased future-state roadmap (data diode, SIS zone, OT SOC).

---

5. Scalability & Protocol Realities

This lab currently utilizes Modbus TCP as a representative industrial protocol. In a production rollout (e.g., Railway/Transportation):

• Protocols: The detection logic would be expanded to support PROFINET, Ethernet/IP, and OPC-UA using modular dissectors.
• Asset Discovery: Manual inventory would be replaced by continuous passive monitoring (e.g., Zeek/Nozomi) linked to the asset_inventory.csv.
• Scale: The architecture is designed to handle thousands of tags across hundreds of distributed PLCs.

---

6. Key Findings & Engineering Judgments

• Tiered Data Architecture (ADR-02): By isolating the Historian in Level 3 (Operations) rather than Level 2 (Supervisory), we create a unidirectional data flow that prevents corporate IT users from ever reaching the control network directly. This fulfills the IEC 62443 requirement for restricted data access between functional zones.
• Chokepoint Enforcement (ADR-05): Utilizing a dedicated Linux gateway running iptables instead of standard Docker bridge networking allows for granular L3/L4 traffic control. This architecture ensures that every inter-zone conduit is explicitly authorized, mirroring the functionality of industrial-grade firewalls.
• Availability-First Detection: Our custom detection rules prioritize high-signal industrial anomalies (e.g., Modbus writes from unauthorized IPs) over generic signature matching. This approach minimizes false positives, ensuring that security monitoring does not interfere with the availability of critical industrial processes.

---

7. Getting Started

To spin up the entire simulated environment (OpenPLC, HMI, Historian, and Firewall):

# Clone the repository
git clone https://github.com/LiamCarPer/OT-Security-Lab.git
cd ot-security-lab

# Start the environment (firewall rules and IDS rules apply automatically)
make up

# Validate the environment: simulate attacks and assert detection
make compliance

The gateway container applies the IEC 62443 zone firewall on boot and launches all custom detection rules as persistent services (make up is sufficient; no manual docker cp/docker exec steps are required).

---

8. Technologies Used

• Virtualization: Docker, Docker Compose V2 (pinned images, resource limits, restart policies)
• Industrial: OpenPLC Runtime (v4), Scada-LTS (HMI), InfluxDB 1.8.10 (Historian)
• Security Infrastructure: iptables (Zone Firewall), Scapy (Custom IDS), iputils-ping, nmap
• Frameworks: IEC 62443-3-2 (Zones/Conduits), MITRE ATT&CK for ICS, ISA-95 Purdue Model
• Monitoring: Grafana 11 + Loki 3 (SIEM), Promtail (log shipping), centralized JSON logging
• DevSecOps: GitHub Actions (CI + Compliance Gate + Release), ruff, bandit, shellcheck, gitleaks, pip-audit, checkov, Trivy, pytest, OPA/conftest (policy-as-code), Syft SBOMs with keyless Sigstore signing, pre-commit hooks, Dependabot

8.1 CI/CD & Supply Chain

• CI (ci.yml): 10 gates — lint & SAST (ruff/bandit), unit tests (pytest), shellcheck, gitleaks, pip-audit, checkov, Trivy, OPA policy enforcement on the compose stack, pre-commit hooks, and SBOM generation with keyless cosign attestation (Sigstore).
• Compliance Gate (compliance-gate.yml): boots the full lab, replays all attack simulations, asserts detection, and commits the fresh alert evidence back to detection/logs/alerts.json — the repository always shows current, machine-generated evidence.
• Release (release.yml): tagged releases (v*) with a git-cliff changelog and evidence screenshots attached.
• Dependabot: weekly dependency updates for pip, GitHub Actions, and the lab Dockerfiles.

---

9. Known Limitations & Future Work

Current Limitations:

• Logical vs. Physical Data Diode: Unidirectional flow is enforced via iptables. High-consequence sites require hardware-based optical data diodes.
• Protocol Scope: Detection is currently implemented for Modbus/TCP and DNP3 (see detection/rules/dnp3_anomaly.py).
• Simulation vs. Emulation: PLCs are software-simulated (OpenPLC) rather than hardware-emulated.

Future Roadmap:

• EDR Integration: Wazuh agent on the Engineering Workstation, correlated with network alerts in the SIEM.
• Suricata: Deploy gateway-side Suricata (config and rules exist in siem/suricata/) with the ET ICS ruleset alongside the custom Scapy rules.
• Automation: Full SOAR loop from SIEM alert to automatic containment (playbooks and webhook receiver exist in automation/; the loop is currently demonstrated, not enforced).

---

10. Compliance Mapping

• IEC 62443-3-2: Zones and Conduits implemented.
• MITRE ATT&CK for ICS: Tactics T0800–T0890 mapped in threat model.