roam/ot-ics-security-rampnetwork-simulator-blueprint.org

ot-ics-security-ramp/network-simulator-blueprint

• Decision (2026-10-06)
• Options Considered
  • MiniCPS (chosen) — https://github.com/scy-phy/minicps
  • ICSSIM — https://github.com/AlirezaDehlaghi/ICSSIM
  • ICS-SimLab — https://github.com/JaxsonBrownie/ICS-SimLab
  • tymyrddin/ics-access-simlab — https://codeberg.org/tymyrddin/ics-access-simlab (reference only, not selected)
• Open Questions / Next Steps

Research/blueprint notes for the "network simulator project" TODO in ot-ics-security-ramp/todos (targeted for the week after 2026-10-06). Goal: an auto-network-creation tool to generate ICS/OT networks for educational attack/defense practice, building on the hands-on lab tools already catalogued in ot-ics-security-ramp/glossary.

Decision (2026-10-06)

Foundation: MiniCPS (https://github.com/scy-phy/minicps), chosen over ICSSIM and ICS-SimLab. Why: core requirement is simulating at scale (many devices/topology size), not per-device isolation. MiniCPS is Mininet-based — devices are lightweight Linux network-namespace processes with virtual Ethernet links, not full Docker containers, so it scales to much larger topologies per host than the Docker-per-device model ICSSIM/ICS-SimLab both use. Per-device filesystem/cgroup isolation (Docker's main advantage) isn't a requirement here. Tradeoffs accepted: topology/devices defined in real Python code (Mininet `Topo` subclass, PLC base-class subclasses with `pre_loop()`/`main_loop()`), not a declarative config file like ICS-SimLab's JSON; no bundled attacker-script tooling or traffic-observer component (unlike ICSSIM) — these will need to be built/ported separately. MIT licensed, actively maintained (commits into 2026), real SWaT/WADI testbed examples included (`examples/swat-s1`) alongside a minimal `examples/toy`.

Options Considered

MiniCPS (chosen) — https://github.com/scy-phy/minicps

• Mininet-based: network namespaces + veth links, not containers. Lightweight, scales well.
• Topology/devices defined in Python (Topo subclass; PLC subclass with pre_loop/main_loop, tag tuples mapping sensor/actuator names to memory addresses).
• Most academically credentialed: built by SUTD SCy-Phy group, includes real SWaT (Secure Water Treatment) testbed scenario, not just synthetic demos.
• No bundled attacker scripts or observer/flow-logging component — security research relies on running standard Linux tools (tcpdump/scapy/arpspoof) directly against namespaced hosts.
• MIT license. Actively maintained (last commit 2026-06-16); older readthedocs install notes mention "Python 2.X" — likely stale given recent pyproject.toml modernization, but unverified — check directly before relying on it.

ICSSIM — https://github.com/AlirezaDehlaghi/ICSSIM

• Docker-based, one container per device (PLC/HMI/Attacker/HIL), MIT licensed.
• No topology constraints — fully custom via code, three published example scenarios (smart grid, water bottling, IED network) are just demos, not limits.
• Tier 1-2 (HIL-PLC "wiring") faked via shared memory; Tier 2-3 (PLC-HMI) is a real Docker bridge network with genuine Modbus-TCP/Modbus-RTU(via socat) packets.
• Ships an Attack Generator: mostly thin shell scripts wrapping standard tools (nmap/ping/scapy/ettercap for recon/MITM/replay — portable to any Docker network with zero changes) plus two Python agent classes needing protocol-aware glue (CommandInjectionAgent, DDosAgent).
• "Observer" component described in the paper not found in ICSSIM's own src/ — likely actually the separate companion repo ICSFlow (https://github.com/AlirezaDehlaghi/ICSFlow, MIT), which sniffs a live interface or PCAP, aggregates to flow records, and labels them from ICSSIM's `logs/attack-logs/` format, a pre-trained ML model, or packet metadata. Since it just sniffs an interface, ICSFlow should work against MiniCPS's traffic too with no porting needed (minus the auto-labeling, which assumes ICSSIM's specific log format).

ICS-SimLab — https://github.com/JaxsonBrownie/ICS-SimLab

• Docker-based, one container per device, MIT licensed (corrected 2026-10-06 — an earlier search had wrongly suggested CC BY 4.0).
• Models Purdue Levels 0-2 only (Sensor/Actuator/HIL, PLC, HMI) — no SCADA/historian/Level 3+, no attacker component at all.
• Config is declarative JSON (`configuration.json` + a `logic/` directory of Python for HIL process behavior) — devices get name/network/registers(Modbus coils/discrete/holding/input)/connections/monitors/controllers. Arbitrary custom topologies supported, not locked to the three shipped demos (smart grid, water bottling, IED network).
• Distinctive design: physical process state centralized in a single SQLite3 DB — sensors read from it, actuators write to it, HIL modules evolve it per custom logic. Simpler/more inspectable than shared-memory IPC, less "realistic" to real hardwired I/O.
• Supports both Modbus-TCP (Docker network) and Modbus-RTU (virtual serial via socat).
• Paper accepted at First International Workshop on Secure ICS and Industrial IoT (2025).

tymyrddin/ics-access-simlab — https://codeberg.org/tymyrddin/ics-access-simlab (reference only, not selected)

• Different project despite similar name to ICS-SimLab above (different author).
• Network-topology/segmentation simulator, not a device simulator: 5-zone Purdue-mapped network (internet/enterprise/operational/control/DMZ) with real FRR routers + deny-by-default iptables between zones, built on containerlab + Linux bridges.
• Design philosophy: vulnerabilities are intrinsic to how the topology/firewall rules are built, not toggled flags; built for red-team/CTF lateral-movement practice, not protocol-level device research.
• License: Polyform Noncommercial — not OSI-approved open source; free for learning/research/defense, requires a commercial license for paid training/consultancy/corporate use. Could be complementary (network/segmentation layer) to a device simulator like MiniCPS/ICSSIM for the Control-zone contents, but the license rules it out if this ever needs to be used commercially.

Open Questions / Next Steps

• Attacker tooling for MiniCPS: nothing bundled: plan to either write directly against namespaced hosts (tcpdump/scapy/arpspoof, same as any Linux host) or port ICSSIM's shell-script wrappers (scan-nmap.sh etc. need no protocol awareness, so should port with minimal change).
• Traffic observation: evaluate pointing ICSFlow directly at a MiniCPS-generated network's interface — likely works unmodified for raw flow capture; auto-labeling would need either replicating ICSSIM's attack-log format or using ICSFlow's other labeling modes.
• Verify current Python version support in MiniCPS before building on it (stale Python 2.X mention in docs vs. recent pyproject.toml modernization).
• Not yet scoped: how "auto-generation" of topology/devices (the actual point of this project) will work on top of MiniCPS's Python Topo-class API — likely a generator that programmatically emits Topo subclasses + PLC device scripts from a higher-level spec, analogous to what ICS-SimLab's JSON config does declaratively.