Event Handler Quarantine Causes NAT Outage
A hospital's FortiAnalyzer 7.4 event handler watches FortiGate VPN logs for failed login and, when 10 failures occur from the same source IP within 5 minutes, runs an automation stitch that quarantines the source IP on the FortiGate for 60 minutes. During an internal vulnerability scan, 280 quarantine actions were created in 20 minutes, including the hospital's NAT egress address, which blocked all remote users for an hour. The event handler has no exclusions. The FortiGate is managed in the root ADOM; the automation stitch uses a Fabric connector with an admin profile that has read-only access. The SOC wants to keep automatic blocking but avoid outages.
1. How should the event handler and automation be redesigned to reduce false positives and prevent another NAT outage?
Read the worked answer
Move from a raw source-IP threshold to a correlated and scoped rule. Match the specific VPN failure log and action, not any failed login; group by source IP plus user; raise the threshold and add a second condition such as failures across multiple usernames. Exclude known scanner ranges, the hospital's NAT egress addresses, and internal RFC1918 sources if remote users should never be quarantined. Use a suppression window so the same IP cannot trigger repeated stitches. For NAT, quarantining the public egress IP blocks everyone behind it; either exclude it or use a user or endpoint quarantine through EMS instead of an IP ban. Add a dry-run or notification-only stage, then enable blocking after a week of clean results. Document the exclusions and review them when NAT changes.
2. Will the quarantine action work with the current read-only admin profile? What should be verified and how should it be tested safely?
Read the worked answer
Read-only will not work. The Fabric connector authenticates to the FortiGate with an admin account, and that account needs permission to create and remove quarantine entries; a read-only profile will make the automation action fail. Check the FortiAnalyzer automation stitch logs and the FortiGate event log for authorization errors. Create a least-privilege admin profile that includes the quarantine or user functions required, bind it to a dedicated service account, and restrict source IPs. Test on a lab FortiGate or a maintenance window with a reserved test IP: trigger a benign event, confirm the quarantine appears in FortiGate's quarantine monitor, confirm expiry, and confirm removal. Do not test with the NAT address.
3. What rollback and monitoring controls should be put in place before re-enabling automatic blocking?
Read the worked answer
Use FortiGate quarantine expiry as the primary rollback, and add an explicit unquarantine action if the playbook needs early release. Before enabling, define a kill switch: disable the automation stitch or event handler, and document who can do it. Monitor automation action failures, quarantine count per hour, and top quarantined IPs; alert on spikes or on any quarantine of a NAT or gateway address. Keep an audit trail of event, action, FortiGate response, and expiry. After the incident, review the 280 actions to see whether the scanner should have been allowlisted and whether the event handler threshold was appropriate.