Fortinet OT Security Architect study materials
Fortinet OT Security Architect study resources

Fortinet OT Security Architect cheat sheet

Fortinet OT Security Architect · Keep the key ideas within reach.

Quick reference

OT Security Fundamentals and Architecture

  • Purdue model levels: 0 process/physical, 1 basic control (PLCs, RTUs, safety systems), 2 supervisory (HMI, SCADA), 3 operations (historians, engineering workstations), 3.5 DMZ, 4 enterprise IT, 5 cloud/Internet.

  • IEC 62443 zones group assets sharing common security requirements; conduits are the only permitted communication paths between zones and must be controlled and monitored.

  • OT priority order is safety, availability, integrity, confidentiality (SIC); IT order is confidentiality, integrity, availability (CIA). Design decisions that trade availability for confidentiality are usually wrong in OT.

  • OT protocols (Modbus/TCP 502, DNP3 20000, IEC 60870-5-104 2404, EtherNet/IP 44818, PROFINET, OPC Classic 135) are largely unauthenticated and cleartext, so identity and policy must be enforced by the network, not the endpoint.

  • IEC 62443 security levels SL1-SL4 describe resistance to increasing attacker capability; SL3 targets attackers with moderate resources using OT-specific knowledge, SL4 targets nation-state-level adversaries.

  • Conduit design rule: no direct path from level 3.5 or below to level 4 or 5; all IT-OT traffic terminates on a DMZ (terminating proxy, jump host, or data diode) rather than traversing the firewall statefully end to end.

  • Purdue level 3.5 DMZ hosts mirrored historians, patch/AV repositories, remote-access brokers, and OPC UA gateways so that level 4 sessions never reach level 2 or lower.

  • Asset inventory is the prerequisite for zoning: identify protocol, firmware, owner, criticality, and patchability per asset before writing policy, because passive discovery is required for fragile level 0-2 devices.

Quick reference

OT Security Design and Deployment

  • FortiGate in transparent (virtual-wire) mode is the default insertion for OT because it forwards without IP reconfiguration and can drop on policy without breaking routing; use NAT/route mode only where routing changes are approved.

  • Industrial protocol signatures (Modbus, DNP3, IEC 60870-5-104, OPC, PROFINET, EtherNet/IP) enforce function-code and register/point-level allowlists; unknown function codes are dropped when the profile is in block mode.

  • FortiGate DoS policies and per-protocol anomaly checks protect fragile PLCs from floods; conservative thresholds are set because level 1 devices may crash under scan traffic.

  • FortiSwitch and FortiAP in an OT fabric segment by VLAN per zone and use 802.1X/MAC-based authentication where endpoints support it; unmanaged legacy devices use MAC allowlist or port-based assignment.

  • FortiNAC performs device profiling and dynamic VLAN assignment for OT; it can quarantine unknown devices into a registration VLAN without touching the PLC configuration.

  • FortiDeceptor deploys decoys and honeytokens mimicking HMI, PLC, and historian assets; any interaction is high-fidelity because legitimate OT traffic never contacts a decoy.

  • Redundancy: FortiGate FGCP HA (A-P or A-A) is deployed inline where link loss is unacceptable; HA failover must be tested against the OT process because gratuitous ARP and session resync can disrupt long-lived control sessions.

  • FortiManager centralizes policy for many OT sites; use metadata variables (site, zone, criticality) with per-device mapping so a single policy package provisions all sites consistently.

Quick reference

OT Security Operations and Monitoring

  • Passive monitoring is mandatory where active scanning risks level 0-2 devices; FortiGate can mirror traffic to FortiAnalyzer/FortiSIEM, and FortiNDR can analyze the copy without inline risk.

  • Log every deny on OT conduits and every allowed industrial-protocol function code; a baseline of expected function codes per conduit turns anomalies into alerts.

  • Key OT detection use cases: new asset appearing in a zone, PLC program download/upload, unauthorized engineering workstation, protocol function code outside baseline, and IT-to-OT direct connection attempt.

  • FortiAnalyzer correlation uses log fields such as srcintf, dstintf, service, and the industrial-protocol log subtype; build reports per zone to prove conduit compliance.

  • FortiSIEM normalizes OT events with IT events; map OT alerts to MITRE ATT&CK for ICS tactics (Initial Access, Lateral Movement, Inhibit Response Function, Impact) for triage context.

  • Alert severity should weight process impact: a blocked Modbus write to a safety PLC is higher priority than a blocked IT scan, because the intent implies process manipulation.

  • Retention: OT logs are kept longer than IT logs (often 12+ months) to support incident reconstruction and regulatory audit; size FortiAnalyzer storage accordingly.

  • Playbooks must separate containment from shutdown: isolating a zone via policy is preferred over powering off a PLC, since unexpected loss of a controller can create a physical hazard.

Quick reference

OT Security Administration and Troubleshooting

  • Before any change, capture a configuration backup (FortiGate config file or FortiManager revision); OT change windows are scheduled and rollback must be pre-approved.

  • Symptom: industrial protocol traffic dropped after enabling a profile. Cause: profile in block mode with an incomplete allowlist. Fix: run in monitor/learn mode, review FortiAnalyzer logs, then add missing function codes.

  • Symptom: HMI loses connection intermittently. Check session timers and idle timeouts; OT sessions are long-lived, so TCP session timers must be raised above the polling interval.

  • Symptom: HA failover breaks control sessions. Cause: no session pickup or asymmetric path through the DMZ; verify session-pickup and that both HA members see the same conduit traffic.

  • Symptom: legitimate device flagged by FortiNAC. Cause: profiling misclassification; correct via device registration or a profiling rule, not by disabling the quarantine VLAN.

  • Diagnose with diagnose sniffer packet, diagnose debug flow, and FortiGate session tables; capture on both sides of the firewall to distinguish policy drop from endpoint failure.

  • Firmware upgrades on OT-firewall pairs follow a tested path: upgrade the secondary, fail over, validate conduit traffic, then upgrade the primary; never upgrade both simultaneously in a live plant.

  • Admin access to OT firewalls uses a dedicated management zone with MFA and role-based admin profiles; direct management from level 4 or the Internet is prohibited by conduit design.

Quick reference

OT Security Integration and Ecosystem

  • FortiGate integrates with FortiSIEM, FortiAnalyzer, FortiManager, FortiNAC, FortiDeceptor, and FortiEDR/FortiXDR via the Security Fabric; Fabric connectors push OT logs and asset data to these systems.

  • FortiGate can export logs to third-party SIEM via syslog (RFC 5424) or the FortiGate Fabric connector; CEF/LEEF formatting is used for ArcSight/QRadar ingestion.

  • FortiNAC integrates with FortiGate as a RADIUS/CoA enforcement point; FortiNAC decides, FortiGate enforces via dynamic address groups and policy.

  • STIX/TAXII and threat-intelligence feeds update FortiGate ISDB and IPS signatures; in OT, apply IPS signatures in monitor mode first because false positives can block control traffic.

  • FortiGate REST API and FortiManager JSON-RPC allow automated provisioning; use least-privilege API admin profiles scoped to the OT policy package.

  • Syslog/NetFlow export to a data lake supports long-term OT analytics; NetFlow shows flow volume and endpoints but not industrial function codes, so pair it with protocol-aware logs.

  • FortiEDR on engineering workstations and historians (level 3) complements network controls; level 0-2 devices generally cannot host agents, so network segmentation is the only control there.