A reference architecture for securing a converged IT/OT environment: Purdue level model, ISA/IEC 62443 zone-and-conduit design with security-level targets, IT-to-OT attack path analysis, asset inventory data model, segmentation and egress design, NERC CIP evidence mapping, and the control substitutions that OT actually requires.
Secure. Zone-and-conduit partitioning with SL-T assignment per zone, a worked conduit register including conduits deliberately not created, layered segmentation enforcement, and egress deny-by-default design.
Assess. Eight IT-to-OT attack paths with preconditions, technique-mapped steps, detection opportunity and signal quality per step, and the cheapest break in each chain — the ordering that tells a plant where to spend finite engineering hours.
Detect. Monitoring requirements per Purdue level with the response constraint stated alongside each detection, honest signal-quality assessment, and vendor-neutral Sigma rules for the highest-value signals.
Govern. NERC CIP control-to-evidence mapping with the producing system and owner per artefact, an asset inventory data model built around discovery confidence rather than assumed completeness, and a control-substitution register that makes every OT deviation an auditable decision with a named accepting role.
Respond. Response constraints per level, including where automated containment is prohibited because the response can cause the incident.
- Synthetic reference implementation. Every zone, conduit, asset, attack path, metric, and target in this repository is invented to exercise the method. No real plant, inventory, finding, or architecture is described.
- No employer or client data. No production topology, no real control-system inventory, no real compliance position. Illustrative numbers are labelled as such.
- No proprietary architecture. The environment is described generically — a converged IT/OT environment operating discrete and continuous production at one or more sites — because the transferable content is the design reasoning, not a topology.
- Not a compliance opinion. The NERC CIP mapping is a method for building an evidence position. It is not legal or regulatory advice and does not represent any registered entity's programme.
- Vendor-neutral. No security product is named as a dependency. Detections are Sigma format. Control-system vendors are referred to generically because the constraints described are common to the class rather than specific to a supplier.
| Standard | Version / part | Where it is applied |
|---|---|---|
| Purdue Enterprise Reference Architecture | PERA level model | architecture/purdue-model.md — consequence taxonomy and per-level expectations |
| ISA/IEC 62443-3-2 | Risk assessment and system design (ZCR 1–6) | architecture/zones-and-conduits.md — partitioning method and SL-T derivation |
| ISA/IEC 62443-3-3 | System security requirements and security levels (FR 1–7) | Requirement allocation per zone; restricted data flow in network/segmentation-and-egress.md |
| ISA/IEC 62443-4-2 | Component requirements | Component-versus-zone SL discussion; compensating design for legacy equipment |
| ISA/IEC 62443-4-1 | Secure development lifecycle | Vendor software acceptance criteria in attack path AP-7 |
| ISA/IEC 62443-2-1 | Security programme requirements | Asset management, transient assets, conduit governance |
| MITRE ATT&CK for ICS | Current | Technique mapping (T0xxx) for OT segments of every attack path and detection |
| MITRE ATT&CK Enterprise | Current | Technique mapping (Txxxx) for IT segments of every attack path |
| NIST CSF | 2.0 | Function mapping: ID.AM for inventory, PR.IR for segmentation, DE.CM for monitoring, RC.RP for recovery |
| NIST SP 800-53 | Rev 5 | Control references: SC-7 boundary protection, AU family for logging, CP family for recovery |
| NERC CIP | CIP-002 through CIP-013 | compliance/nerc-cip-control-evidence-mapping.md — requirement-to-evidence mapping with producing systems |
| IEC 61511 | Alignment reference | Safety-system independence in the Purdue and zone models |
| Sigma | Current rule specification | Detection content in monitoring/monitoring-requirements-by-level.md |
it-ot-security-reference/
README.md
DECISIONS.md
LICENSE
.gitignore
architecture/
purdue-model.md level model, consequence framing, where PERA breaks
zones-and-conduits.md 62443-3-2 partitioning, conduit register, SL-T rationale
attack-paths/
it-to-ot-attack-paths.md 8 paths: preconditions, chain, detection, cheapest break
asset-inventory/
asset-data-model.md entity model and the practical limits of passive discovery
network/
segmentation-and-egress.md enforcement layers, egress design, rule hygiene, verification
compliance/
nerc-cip-control-evidence-mapping.md CIP requirement to evidence artefact, owner, cadence
operations/
why-it-controls-fail-in-ot.md patching, agents, credential rotation, scanning, and substitutes
monitoring/
monitoring-requirements-by-level.md telemetry, detections, and response constraints per level
If you are designing segmentation for a converged environment: read architecture/purdue-model.md
for the consequence taxonomy, then architecture/zones-and-conduits.md for the enforcement design.
Build the conduit register before touching a firewall — the register is the artefact that keeps the
design and the running configuration the same thing, and §6 of that document is the governance that
prevents the decay every segmentation project suffers.
If you are prioritising a limited OT security budget: read the cross-path summary at the end of
attack-paths/it-to-ot-attack-paths.md. Six of the eight cheapest breaks are configuration, process,
or workflow changes rather than purchases. Sequence by cheapest break, not by product roadmap.
If enterprise IT policy is being applied to your OT environment unchanged:
operations/why-it-controls-fail-in-ot.md gives, for each of patching cadence, endpoint agents,
credential rotation, active scanning, MFA, log collection, automated containment, and production
penetration testing: why the control fails as written, what substitutes, the residual gap, and the
metric that should replace the IT metric. Use the summary table in §7 as the basis for a
compensating-control register.
If you are building an asset inventory: read asset-inventory/asset-data-model.md §4 before
selecting tooling. Passive discovery is the right default and it does not produce a complete
inventory; §4.1 states what an inventory programme can credibly promise instead.
If you are preparing OT compliance evidence: use
compliance/nerc-cip-control-evidence-mapping.md, and specifically §12 — classify each requirement's
evidence as generated, assembled, or manual, then engineer the manual and high-cadence rows upward.
That classification predicts audit cost more reliably than a control-maturity score.
If you are building OT detection capability: monitoring/monitoring-requirements-by-level.md gives
telemetry requirements, detections with honest signal quality, and the response constraint per level.
Start with the four High-quality signals that need no product purchase: brokered sessions without a
change record, denied egress from a control zone, baseline diff without an approved change, and an
industrial engineering protocol from an unexpected source.
Reading order for a first pass: Purdue model → zones and conduits → attack paths → why IT controls fail → monitoring → asset inventory → segmentation → compliance.
Sibling repositories in this portfolio, referenced by name only:
threat-model-library— the threat-modeling method and format, including a fully worked threat model of a converged IT/OT plant network that applies this reference architecture.