Catch a Silently Removed Security Profile — FortiManager + FortiAnalyzer

This is the change that scares me most, because it's invisible: an admin edits a firewall policy and removes the IPS (or AV, or web filter) profile — or flips utm-status to disable. Nothing breaks. Traffic keeps flowing. The dashboards stay green. But the box has quietly stopped inspecting, and you won't know until an incident or an audit six months later.

A generic "config changed" alert won't save you here — it fires on everything, so it gets muted. What you actually want is to catch this specific class of change, and to know instantly whether it was authorised. That takes two systems doing what each is best at.

Two detectors, one edit

The trick is to catch the removal from both directions:

• FortiAnalyzer is the fast signal. The moment the policy is saved, a configuration-change event lands in FAZ. It carries who, when, and what field changed.
• FortiManager is the source of truth. The approved policy package says that profile must be there. The device no longer matches it — that's drift, and drift is proof the change was unauthorised.

Speed from one, authority from the other.

FortiAnalyzer: detect the removal

Config changes arrive as event logs. A removed profile shows up as an attribute change on the policy object — the old value had a profile name, the new value is empty (or utm-status went to disable). Build an Event Handler (Incidents & Events → Handlers) filtered to exactly that:

type == event AND subtype == system
AND cfgpath == "firewall.policy"
AND ( cfgattr ~ "ips-sensor[*->]"
   OR cfgattr ~ "av-profile[*->]"
   OR cfgattr ~ "webfilter-profile[*->]"
   OR cfgattr ~ "utm-status[enable->disable]" )

That handler raises an incident and can notify — so instead of noise, you get one high-signal event that means inspection was just weakened on policy N.

Inspection can die more than one way. Removing the profile reference is one; setting utm-status disable is another; and turning off ssl-ssh-profile blinds deep inspection without touching the UTM profiles at all. Cover all of them, or you'll catch the obvious removal and miss the quiet one.

FortiManager: prove it's drift

FAZ tells you a profile was removed. FortiManager tells you it shouldn't have been. The approved policy package is the baseline; compare it to what the device is actually running:

Device Manager → device → Config Status  → "Modified" / out-of-sync
Policy & Objects → package → Install Preview   → shows the exact CLI delta
Revision History → diff the last two revisions  → the removed profile line

If the running config no longer matches the approved package, that's an authoritative, auditable statement: this change was never sanctioned.

Detection and truth are different jobs. FortiAnalyzer answers "did something change, and who did it?" in seconds. FortiManager answers "was it allowed?" against the approved baseline. Neither alone is enough — the event without the baseline is noise, the baseline without the event is slow.

Close the loop

Once you've caught it, FortiManager is also the fix. Re-install the approved package and the profile snaps back into place:

Install Wizard → select the drifted device → Install Preview → confirm → install

The same package that flagged the drift restores the inspection — and the incident in FAZ keeps the receipt of who removed it and when.

A removed IPS profile that used to surface at the next quarterly audit now shows up as a FortiAnalyzer incident within minutes — "utm-status disabled on policy 14 by admin_j from 10.0.0.20" — with FortiManager confirming it as drift from the approved package and a one-click re-install to restore it.

Why this beats a plain change alert

• Specific, not noisy — you alert on inspection being weakened, not on every comment edit, so the alert stays trusted.
• Attributable — the FAZ event names the admin and source; there's no "who did this?" meeting.
• Authoritative — FortiManager turns "someone changed something" into "this deviates from the approved baseline," which is what an auditor actually wants.
• Self-healing — the source of truth that detects the drift is the same one that repairs it.

The whole point is to make a silent security downgrade loud — and to make it loud in minutes, with a name on it, not at the next audit.