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
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
- Architecture & Design
- Lab Environment
- Asset Inventory
- Threat Model & Risk Analysis
- 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](./hardening/)
* [Security Hardening Checklist](./hardening/HARDENING_CHECKLIST.md)
* [IEC 62443 Gap Analysis](./iec62443/gap-analysis.csv) 7. [Incident Response](./incident-response/)
* [PLC Unauthorized Change Playbook](./incident-response/ir-playbook-unauthorised-plc-change.md) 8. [Engineering Post-Mortem](./LESSONS_LEARNED.md)
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
iptablesinstead 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,
restartpolicies) - 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 todetection/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.