MSSP Multi-Tenant OT Monitoring With Customer SIEMs
An MSSP monitors 12 OT customers using a shared FortiManager and FortiAnalyzer, with FortiGate Rugged at each site. Each customer has its own SIEM: 7 use Splunk, 3 use Microsoft Sentinel, and 2 use FortiSIEM. The MSSP wants automated containment via FortiNAC when a rogue device appears on an OT VLAN, but customer engineers must approve any port shutdown on critical lines. Log volumes vary from 2 GB/day to 40 GB/day per customer; API rate limits and data residency rules apply. One customer has a 15-minute emergency change process, another requires 24-hour notice. The MSSP has 10 analysts and no authority to change customer firewall policy.
1. Design the multi-tenant data flow, log normalization, and access model, including ADOMs, log forwarding, and API integration.
Read the worked answer
Use FortiManager ADOMs per customer, with RBAC so MSSP analysts have read/write only where contracted and customer engineers have read-only or approval roles. FortiAnalyzer should also use per-customer ADOMs and separate retention; do not mix raw logs across tenants.
Forward only the required event types to each customer SIEM: syslog/CEF for Splunk and FortiSIEM, API or connector for Sentinel. Normalize fields for tenant, site, Purdue level, asset role, protocol, action, and severity; keep the original vendor field for investigation. For data residency, deploy regional FortiAnalyzer collectors or filter at the edge before forwarding.
Respect API rate limits with batching, backoff, and a local buffer; never let a SIEM outage drop OT security logs. The MSSP should not have customer firewall policy authority; use FortiManager workflows and customer approval for changes.
2. Design a containment playbook that satisfies both customers' approval requirements while still reducing risk.
Read the worked answer
Tier the playbook by asset criticality and customer process. Detection: FortiNAC identifies a rogue device on an OT VLAN and opens a ticket with MAC, switch port, VLAN, and first-seen time.
For non-critical cells, auto-quarantine after a 10-minute grace period by applying a FortiGate block policy or FortiNAC VLAN change, with immediate notification. For critical lines, do not shut the port; require customer engineer approval in the ticket, then apply the least disruptive action. One customer's 15-minute emergency process can support a phone bridge; the other's 24-hour notice means pre-approve a narrow emergency playbook or accept monitoring-only.
Never automate a port shutdown on a line with safety or production impact. Include a rollback action and a post-change verification that the legitimate device still communicates.
3. What integration risks would you call out before go-live, and how do you test them?
Read the worked answer
Call out API rate limits and throttling, log loss during WAN outages, clock skew between FortiGate and SIEM, duplicate events from multiple collectors, tenant data leakage through shared indices, approval latency, and FortiNAC's ability to control third-party OT switches.
Test with synthetic rogue-device traffic in a lab, then a non-production VLAN, then a pilot site. Load-test the log pipeline at the 40 GB/day customer, simulate SIEM and FortiManager outages, and verify buffering and replay. Confirm that a containment action cannot lock out the MSSP or the customer engineer.
Document data residency and retention per tenant. Go-live only after a tabletop exercise of the approval workflow and a rollback drill.