Logistics Security Reference Architecture

A vendor-neutral, implementation-ready cybersecurity reference architecture for a modern 24/7 logistics & distribution center — covering IT/OT convergence, warehouse automation, robotics, wireless, cloud, and supply-chain risk.

---

What this is

This repository is a fictional but realistic security architecture for Global Distribution Services (GDS), a third-party logistics (3PL) operator running a single regional distribution center, GDS-RDC-01. It is written as a professional consulting deliverable and is designed to be read by engineers (who want the how) and hiring managers (who want to see the thinking).

Everything here is fictional, vendor-neutral, and educational. No real company, product, or address space is referenced. All IP ranges are RFC 1918 private space and are illustrative.

Why this exists. I built this as a portfolio piece to show how I approach security architecture for a converged IT/OT environment end-to-end — from a single authoritative design canon, through segmentation, threat modeling, and framework-mapped controls, down to concrete firewall objects and a phased roadmap. It is meant to be read, critiqued, and reused. — see Author.

The problem it solves

A distribution center is where enterprise IT meets industrial OT at high speed: a Warehouse Management System (WMS) dispatching work to a Warehouse Execution System (WES), driving a Warehouse Control System (WCS), driving PLCs, conveyors, sortation, and Autonomous Mobile Robots (AMRs) — while handheld scanners, RFID, IoT sensors, label printers, CCTV, badge access, cloud integrations, and customer/carrier APIs all share the building. A flat network here means one phishing email can stop the line. This architecture shows how to segment, authenticate, monitor, and recover without breaking 24/7 operations.

---

Architecture at a glance

graph TB
  INET["Internet / Cloud<br/>ERP SaaS · Analytics · Customer Portal · IdP"]

  subgraph ENT["Enterprise — L4/L5 · 10.10.0.0/16"]
    USERS["Workstations · Corp Wi-Fi<br/>VLAN 10/11"]
    ITSRV["AD · DNS · DHCP<br/>VLAN 20"]
    WMS["WMS · TMS<br/>VLAN 21"]
  end

  subgraph IDMZ["Industrial DMZ — L3.5 · 10.30.0.0/24"]
    BROKER["Jump Host · Patch/AV Relay<br/>Historian Replica · Reverse Proxy<br/>MQTT Broker · Vendor Landing"]
  end

  subgraph OT["OT — L0–L3 · 10.20.0.0/16"]
    SITEOPS["WES · WCS · OT-DC · EWS<br/>VLAN 300/301 — L3"]
    AREASUP["HMI · Industrial PC · Print-and-Apply<br/>VLAN 200/210 — L2"]
    L1["PLCs · Safety Controllers<br/>VLAN 100/110 — L1"]
    PROC["Conveyors · AMRs · Sensors · Scanners<br/>L0 / Wireless VLAN 60/61/62"]
  end

  INET -->|"HTTPS · API GW · mTLS"| ENT
  ENT  -->|"NGFW FW-ITDMZ<br/>default-deny"| IDMZ
  IDMZ -->|"NGFW FW-DMZOT<br/>brokered only"| SITEOPS
  SITEOPS --> AREASUP --> L1 --> PROC

  classDef ent fill:#e8f0fe,stroke:#3b6fb5;
  classDef dmz fill:#fff4e5,stroke:#cc8400;
  classDef ot fill:#e9f7ef,stroke:#2e8b57;
  class ENT,USERS,ITSRV,WMS ent;
  class IDMZ,BROKER dmz;
  class OT,SITEOPS,AREASUP,L1,PROC ot;

Loading

Real-time control loops never depend on the cloud or the Internet — if the WAN drops, the line keeps running. The cloud is for optimization and analytics, not control. See docs/architecture.md.

---

Repository map

Path	What's inside
docs/assumptions.md	Design canon — company facts, Purdue zones, the canonical IP/VLAN scheme, wireless, identity. Start here; every other doc derives from it.
docs/architecture.md	Executive summary, business requirements, security objectives, design principles, asset inventory, zone & conduit model.
docs/warehouse-network.md	Network architecture, IT/OT separation, segmentation, Industrial DMZ, wireless, NAC, device authentication, network hardening.
docs/threat-model.md	STRIDE analysis + 7 attack-path scenarios (supply chain, ransomware, rogue Wi-Fi, compromised scanner, cloud API, insider, vendor remote access) with mitigations.
docs/controls-mapping.md	Control catalog (GDS-C-nn) crosswalked to NIST CSF 2.0, SP 800-82, IEC 62443, CIS v8, and MITRE ATT&CK / ATT&CK for ICS.
docs/firewall-rules.md	Default-deny rulesets for every boundary (FW-ITDMZ, FW-DMZOT, FW-OTINT, FW-MGMT, FW-PHYS), egress control, JIT vendor rules.
docs/implementation-guide.md	Cloud, API security, identity, vendor access, zero trust, logging, detection, IR/BC/DR, supply chain, IoT/robotics/conveyor security, baselines, and the roadmap + 3-year maturity model.
docs/risk-register.md	Quantified 5×5 risk register (R-nn), heat map, and top-risk treatment plan.
diagrams/	Standalone Mermaid sources: warehouse network, cloud connectivity, trust boundaries, wireless segmentation, logging pipeline.
images/	Pre-rendered SVGs of the standalone diagrams.
templates/	Reusable artifacts: ADR, firewall-change request, vendor-access request, risk-register entry.
drawio/	Convention/placeholder for optional editable draw.io sources (Mermaid is preferred).

---

Design principles (the short version)

1. Availability & safety first in OT — controls fail toward safe and running.
2. The plant runs if the Internet is down. Cloud ≠ control plane.
3. Segment by zone and conduit (Purdue / IEC 62443); no flat OT network.
4. No protocol traverses IT→OT end-to-end — everything is brokered in the Industrial DMZ.
5. Assume breach. Identity-centric zero trust, least privilege, microsegmentation.
6. Vendors are hostile-by-default until brokered, time-boxed, MFA'd, and recorded.
7. Legacy devices get compensating controls (segmentation + monitoring), not agents.
8. Monitor everything, IT and OT, into one correlated picture.

---

Frameworks mapped

Framework	Used for
NIST Cybersecurity Framework 2.0	Govern/Identify/Protect/Detect/Respond/Recover coverage
NIST SP 800-82 Rev. 3	OT/ICS security overlay
IEC 62443 (-3-3, -2-4, -4-2)	Zones/conduits, security levels, service-provider & component requirements
CIS Critical Security Controls v8	Safeguard-level baseline (IG2 target)
MITRE ATT&CK & ATT&CK for ICS	Threat techniques, detection & mitigation coverage

See docs/controls-mapping.md for the full crosswalk.

---

How to read the diagrams

Diagrams are authored in Mermaid and render natively on GitHub. The standalone sources live in diagrams/, with pre-rendered SVGs in images/:

Diagram	Source	Rendered
Warehouse network (full topology)	.mmd	.svg
Cloud connectivity	.mmd	.svg
Trust boundaries & conduits	.mmd	.svg
Wireless segmentation	.mmd	.svg
Logging & detection pipeline	.mmd	.svg

To re-render locally:

npm install -g @mermaid-js/mermaid-cli
for f in diagrams/*.mmd; do mmdc -i "$f" -o "images/$(basename "${f%.mmd}").svg"; done

---

Scope & disclaimer

This is an educational reference architecture, not a deployment package or a security guarantee. It is intentionally vendor-neutral — product selection, sizing, and detailed engineering are out of scope and would follow from a real assessment. The organization, its facility, and all addressing are fictional. See docs/assumptions.md §10 for explicit out-of-scope items.

Author

Rick Ramirez — cybersecurity & information security risk management. GitHub: @rick-rami94

This is an independent portfolio project. The scenario, organization, and all addressing are fictional; the architecture, threat model, and controls reflect my own approach to securing a converged IT/OT logistics environment. Feedback and issues are welcome.

License

Released under the MIT License. You are free to reuse and adapt this material with attribution.