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

Fortinet OT Security Architect: OT Security Administration and Troubleshooting

Fortinet OT Security Architect · Work through your exam, one topic at a time.

All guide sections

OT Security Administration and Troubleshooting

This domain tests day-two competence: licenses and FortiGuard health, configuration backup and revision control, and the CLI diagnostics that find a fault in a conduit without waiting for a maintenance window. Exam items often present a symptom (an HMI stopped talking to a PLC after a change) and ask for the first diagnostic or the most likely root cause.

Administrative fundamentals

Keep FortiGate configurations under FortiManager revision control so a change can be diffed and rolled back; take local backups before upgrades and follow documented FortiOS upgrade paths rather than skipping releases. Verify FortiGuard connectivity and license state before blaming signatures: if the OT Security Service or IPS engine has no updates, detection silently degrades. Confirm NTP synchronization across FortiGate, FortiAnalyzer and FortiSIEM, since unsynchronized clocks destroy correlation.

Diagnostic toolkit

  • diagnose sniffer packet on the relevant interfaces with a host and port filter to prove whether packets arrive and leave.
  • diagnose debug flow with filters for source, destination and port to see which policy matched, or that none did.
  • diagnose sys session filter plus diagnose sys session list to confirm session creation, NAT translation and timeouts.
  • get system status and diagnose autoupdate status for firmware and FortiGuard state.
  • diagnose hardware deviceinfo nic for interface errors and link state on rugged appliances.

Worked example

After a policy push, an HMI can no longer poll a PLC. Reasoning: start with debug flow filtered on the HMI address and TCP/502. If output shows the packet matched the deny policy, the change is a policy-ordering or object problem, not a routing problem; fix the rule order. If it shows no match at all, the traffic never reached the FortiGate, so check the virtual wire pair or switch path. If sessions are created but the PLC replies slowly, inspect session timers: OT polling with long idle gaps can be torn down by default TCP timeouts, and the fix is a targeted session TTL or keepalive, never a global timer change.

Traps that cost marks

Testing reachability with ICMP when the protocol itself is blocked, then concluding the path is broken; changing the default session TTL globally instead of per-flow; forgetting that asymmetric routing across a transparent pair drops sessions; and pushing changes without a rollback plan on a system where downtime is measured in production loss.