Manufacturing Security Reference Architecture

A vendor-neutral, fictional reference architecture for securing a discrete + process manufacturing campus, modeled on IEC 62443, NIST SP 800-82 Rev 3, NIST CSF 2.0, CIS Controls v8.1, and MITRE ATT&CK for ICS.

This repository documents how a Senior/Principal Security Architect would design the cybersecurity architecture for Acme Manufacturing — a fictional industrial manufacturer running a single ~600-employee production campus with corporate IT, full OT/ICS, engineering workstations, industrial wireless, remote vendor maintenance, and limited cloud connectivity.

It is written as portfolio/reference material: everything here is invented and generic — no real company, product, vendor, or proprietary information. It is intended for engineers to learn from and adapt.

Most public ICS security material is either too abstract (a Purdue diagram and a paragraph) or too narrow (one product's config). This repo aims for the middle: a complete, internally consistent engagement-grade package — design principles, asset inventory, segmentation plan, zones & conduits, firewall policy, threat model, controls traceability, a risk register, and a phased roadmap — all referencing the same canonical IP plan, VLANs, zone IDs, and asset tags so the documents actually fit together.

manufacturing-security-reference-architecture/
├── README.md ← you are here
├── LICENSE ← MIT (content also CC BY 4.0; see LICENSE)
├── DESIGN_BASIS.md ← canonical source of truth: IP plan, VLANs, zone/conduit IDs,
│ Security Levels, asset tags, firewall labels (every doc derives from this)
├── docs/
│ ├── architecture.md ← flagship: exec summary, objectives, principles, asset inventory,
│ │ trust boundaries, Purdue mapping, 62443 zones/conduits, IAM/PAM, HA, ADRs
│ ├── segmentation.md ← VLAN/IP plan, IDMZ design, microsegmentation, SIS isolation, E-W/N-S controls
│ ├── threat-model.md ← STRIDE, attack surface, 5 detailed scenarios w/ ATT&CK for ICS mappings
│ ├── controls-mapping.md ← master traceability matrix across all 5 frameworks (100+ controls)
│ ├── firewall-rules.md ← example deny-by-default policy for FW-EDGE / FW-IDMZ / FW-CELL / FW-SIS
│ ├── implementation-guide.md← phased roadmap, Zero-Trust-for-OT, hardening, patching, backup/DR
│ ├── risk-register.md ← 24-risk register, heatmap, logging/monitoring & IR architecture
│ └── assumptions.md ← scope, assumptions, constraints, and out-of-scope items
├── diagrams/ ← Mermaid (.mmd) source — render at https://mermaid.live
│ ├── network-overview.mmd
│ ├── trust-boundaries.mmd
│ ├── data-flow.mmd
│ └── segmentation.mmd
├── drawio/
│ └── manufacturing-network.drawio ← editable at https://app.diagrams.net
├── images/ ← exported diagram PNGs (optional)
├── detections/ ← hands-on artifact: example OT NDR/IDS rules mapped to ATT&CK for ICS
│ └── ot-detections.rules
└── templates/ ← reusable artifacts (change request, risk entry, firewall rule request)

Additional diagrams (Purdue levels, zones & conduits, authentication flow, vendor access, logging, IR, and the five attack-path flows) are embedded inline as Mermaid in the relevant docs/ files.

1. DESIGN_BASIS.md — the canonical IP/VLAN/zone/asset values every other doc references.
2. docs/assumptions.md — what is and isn't in scope.
3. docs/architecture.md — the big picture and design decisions.
4. docs/segmentation.md — how the network is carved into zones and conduits.
5. docs/firewall-rules.md — the policy that enforces the segmentation.
6. docs/threat-model.md — what we're defending against and how.
7. docs/controls-mapping.md — traceability to the standards.
8. docs/risk-register.md — residual risk, monitoring, and incident response.
9. docs/implementation-guide.md — how to actually roll it out.

Cedar Falls campus network overview — Purdue-aligned reference architecture

Rendered from diagrams/network-overview.mmd (pre-rendered PNGs for all four diagrams are in images/). High-level shape:

flowchart TB
 INET([Internet / SaaS]) --- FWEDGE{{FW-EDGE}}
 FWEDGE --- L4["L4 — Corporate IT<br/>AD · ERP · SOC/SIEM"]
 L4 --- FWIDMZ{{FW-IDMZ HA}}
 L4 -. enterprise WAN .- L5["L5 — Enterprise / Cloud<br/>(off-campus)"]
 FWIDMZ --- IDMZ["L3.5 — Industrial DMZ<br/>Remote-Access Broker · Jump Hosts · API/Patch/Historian/Syslog relays"]
 FWIDMZ --- L3["L3 — Site Operations<br/>MES · Historian · OT-AD · File · Immutable Backup"]
 L3 --- LCORE{{L3-CORE-OT}}
 LCORE --- FWCELL{{FW-CELL-A..D}}
 FWCELL --- L2["L2 — Line SCADA / HMI / EWS"]
 L2 --- L1["L1 — PLCs / Controllers"]
 SIS["L1-S — Safety (SIS)"] -. one-way log + read-only status .-> L1
 L1 --- L0["L0 — Sensors / Actuators / Drives"]

Key design moves: a hardened Industrial DMZ brokers every IT↔OT crossing (no direct L4→L3 path); a separate OT Active Directory forest with no trust relationship of any kind to corporate; per-line zoning so one line can't reach another's controllers; SIS isolation with no inbound conduit (programming happens intra-zone from a normally-disconnected safety engineering workstation); and passive-first monitoring so visibility never disrupts the process.

The opinions a reviewer should take away in 60 seconds — each is argued in docs/architecture.md (ADRs) and the design basis:

Brownfield realism: this is a target-state retrofit, not greenfield. Legacy/unpatchable assets are assumed permanent and contained rather than fixed; the implementation guide carries rough cost/effort and the friction each phase tends to hit.

• Pre-rendered PNGs — all four diagrams are exported to images/ for offline/non-GitHub viewing.
• Mermaid .mmd — paste into https://mermaid.live, or view the docs/ Markdown in any Mermaid-aware renderer (GitHub renders fenced Mermaid blocks natively).
• .drawio — open drawio/manufacturing-network.drawio at https://app.diagrams.net (File → Open) or with the draw.io desktop/VS Code extension.

This is fictional reference material for education and portfolio purposes. It is not a turnkey design. Real deployments must be engineered to the specific process, safety case, regulatory context, asset vendors, and risk appetite of the operator, and validated by qualified engineering and safety personnel before any change is made to a live control system. Nothing here should be applied to a production OT environment without site-specific analysis and a management-of-change process.

Code/config samples: MIT. Documentation and diagrams: CC BY 4.0. See LICENSE.