SOC Flooded by OT Alerts After Fabric Rollout
A discrete manufacturer connected 26 FortiGate Rugged firewalls, 3 FortiDeceptor appliances, and a FortiAnalyzer to a new SOC. Within two weeks, the SOC receives 18,000 alerts per day; 92 percent are Modbus/TCP exceptions and policy denies from a vulnerability scanner. The OT engineering team refuses to allow blocking because a previous IPS deployment stopped a production line. The SOC has 6 analysts, follows IT runbooks, and cannot tell whether a source is an HMI, engineering laptop, or transient vendor device. There are change windows every Wednesday 22:00-02:00. No OT asset inventory exists, and FortiSIEM is not deployed. The CSO wants a measurable reduction in alert volume and no increase in missed critical events.
1. Design a prioritization and tuning plan for the first 60 days, naming the data sources and specific Fortinet features you would use.
Read the worked answer
Start with data quality, not signature count. Days 1-10: onboard FortiAnalyzer logs from all 26 FortiGates and FortiDeceptor, enable OT protocol logging only on relevant policies, and build an asset/role map from FortiGate device detection and engineering input. Days 11-30: identify the vulnerability scanner, create scoped and expiring exceptions, and suppress duplicate policy denies by source, destination, and service. Keep them visible in a weekly report. Use FortiDeceptor alerts as high-fidelity incidents. Days 31-60: convert raw Modbus function-code alerts into behavior rules with asset context: who is allowed to write to which PLC, from where, and when. Put low-value signatures in monitor-only or summary mode. Use FortiAnalyzer event handlers and incident aggregation to deduplicate.
Do not globally disable OT IPS; tune per signature and per asset. The 92 percent noise is mostly expected scanner and read traffic, so suppress by identity and schedule, not by turning off the protocol.
2. Define three OT-specific detection use cases and explain why each is higher value than raw Modbus function-code alerts.
Read the worked answer
Unauthorized PLC write: a source that is not an approved engineering workstation writes to a PLC or changes mode. This is higher value than any function-code alert because it links identity, asset, and operation.
New OT asset or rogue device: a previously unseen MAC or IP starts Modbus or Ethernet/IP conversations in a cell; combine FortiGate discovery with FortiDeceptor bait.
Off-window engineering change: a PLC program download or diagnostic session occurs outside the Wednesday window or without a ticket reference.
These use cases reduce false positives because they require context, not just a protocol field. Raw Modbus exception alerts fire on normal polling and vendor tools; they do not tell the analyst whether the action is dangerous. Prioritize rules that answer who, what asset, and whether the behavior is allowed.
3. How do you measure success and avoid creating blind spots?
Read the worked answer
Measure alert volume by category, true-positive rate, median time to detect, and percentage of critical assets covered by an active rule. Track suppressed events by rule and review them weekly; an exception must have an owner and expiry.
Avoid blind spots by keeping monitor-only copies of suppressed signatures, running periodic canary tests such as a known unauthorized write from a lab device, and sampling raw logs. Check that the scanner exception does not hide a real host using the scanner IP.
Report both reduction and coverage to the CSO. A 70 percent volume drop with no canary detection is failure, not success. Require engineering sign-off before any OT IPS block action and keep a rollback path.