Threat Intelligence and FortiGuard Tuning: Making IPS Signatures Actually Work for You
FortiGuard is a delivery mechanism, not a feature
NSE4 Part 2 covered FortiGuard as a licensing gate: without an active subscription, signature databases freeze and category lookups stop returning results. That’s true, but it undersells what FortiGuard actually is operationally. It’s the distribution channel for three separate things that get lumped together under one brand name: the IPS signature database, the antivirus/outbreak-protection hash feed, and the URL/application category ratings. Each one updates on a different cadence, gets consumed by a different engine on the box, and needs a different tuning conversation. Treating “FortiGuard” as a single on/off feature is how you end up with an IPS sensor that’s either too loud to act on or too quiet to matter.
This post is about the IPS and outbreak-prevention piece specifically, because that’s the one with a real, ongoing tuning cost. Category-based web filtering is largely a policy decision once. IPS is a decision you keep making, signature by signature, as the database grows underneath you.
What ships in a signature update, and what FortiOS does with it by default
Every FortiGuard IPS signature carries a Fortinet-assigned severity and a default action. When a new or updated signature package lands, whatever an IPS sensor is configured to inherit from that default takes effect immediately unless you’ve explicitly overridden it. NSE4 Part 6 covers the IPS sensor’s basic structure: a sensor is a set of filters (protocol, severity, target, OS) plus explicit overrides for individual signature IDs. What that post doesn’t dwell on is what happens when you never touch the overrides at all, which is the common case and the source of most IPS complaints.
Running purely on inherited defaults means every signature update can silently change your enforcement posture. A signature that shipped as “monitor” last month can ship as “block” this month if Fortinet reclassifies its severity, and a sensor that inherits defaults will pick that change up on the next signature pull with no change log entry in your own configuration. That’s not a bug, it’s the point of a managed threat feed, but it means “we didn’t change anything” is not actually true of an IPS deployment running on inherited defaults. The database changed, and your enforcement changed with it.
Outbreak prevention runs on a different clock
The IPS signature database and the antivirus/outbreak feed both come from FortiGuard, but they don’t update on the same schedule for the same reason. Routine IPS and AV signature updates follow FortiGuard Labs’ regular research and release cadence. Outbreak prevention exists because that cadence isn’t fast enough for an actively-exploited zero-day: FortiGuard Virus Outbreak Protection Service supplements the local AV database with third-party malware hash intelligence pulled from FortiGuard’s global threat data, giving a FortiGate coverage for something the local signature set hasn’t caught up to yet, without waiting for the next scheduled database pull.
The practical implication for design: don’t treat “how often do signatures update” as a single answer you can quote once and forget. Routine coverage is a scheduled push. Outbreak coverage is closer to continuous, specifically because the threats it exists for don’t wait for a release window. If your change-management process treats every signature change as equally routine, you’ve built a process that’s structurally too slow for the one category of update that actually needs speed.
Where the pattern-matching work actually happens
IPS signature matching against decrypted payload is CPU/CP9-bound work, the same content processor doing the crypto lift for SSL/TLS deep inspection. That’s not a coincidence, it’s the same architectural fact showing up twice: anything that needs to look at payload content, whether that’s an AV scan or an IPS signature match, needs the payload decrypted first, and decryption is the thing that pulled the session off the NP7 fast path in the first place. A firewall policy stacking deep inspection and a fully-enforced IPS sensor on the same traffic is asking the CP9 and the CPU to do both jobs on every byte, and sizing for that combination against the platform’s NP7-offloaded throughput number will disappoint you for exactly the reasons that post describes.
This is worth knowing before you tune, because it changes what “tune IPS aggressively” actually costs. Enabling every available signature at full severity on a sensor bound to a policy that’s also running deep inspection isn’t free visibility, it’s a specific, measurable throughput trade, and it’s better to make that trade on purpose than to discover it during an incident when the box that’s supposed to be catching the attack is also the box struggling to keep up with normal traffic.
Tuning for false positives without tuning yourself blind
The reflexive fix for IPS noise is to flip the whole sensor to monitor mode until the complaints stop. That solves the noise problem by discarding the thing IPS exists for. The better fix is narrower and slower, and it looks like this:
Override specific signature IDs, not whole severity bands. A signature that consistently fires on legitimate traffic in your environment is a bad match for your traffic pattern, not evidence that the entire severity tier is unreliable. Override that one signature ID to monitor or disabled, with a note on why, and leave the rest of the sensor’s inherited defaults intact. This is slower than blanket-disabling a severity tier, and that’s the point: it keeps the sensor’s coverage close to what Fortinet actually shipped, instead of eroding it one frustrated exception at a time.
Stage new signature behavior before trusting inherited defaults blindly in a sensitive environment. If a segment genuinely can’t tolerate an unreviewed action change landing with the next signature pull, a change-controlled sensor that pins explicit actions rather than inheriting Fortinet’s default is the honest way to get that guarantee. It’s more maintenance, not less, because now updates to that segment’s sensor are a deliberate review step rather than an automatic pull. Reach for this selectively, for the traffic where an unreviewed action change is a genuine risk, not as a blanket policy that turns every sensor into a manually-curated list you now own the accuracy of.
Use rate-based signatures and DoS sensors as a separate tuning problem from content signatures. A rate-based signature (connections-per-second thresholds, request-flood detection) has a threshold value that’s meaningful only relative to your own traffic baseline. A default threshold tuned for Fortinet’s general customer base will be wrong for your specific link, in one direction or the other, and no amount of severity-tier tuning fixes a threshold problem. If DoS sensors are firing on legitimate traffic spikes, the fix is the threshold value, not the sensor’s enable state.
Look at hit logs before assuming a signature is a false positive at all. A signature that fires once during an odd traffic pattern isn’t automatically noise, and disabling it on that basis is how real coverage quietly erodes over months. The judgment call worth making explicitly, signature by signature, is whether the traffic that triggered it was actually benign, not just whether it was inconvenient.
Where this leaves an IPS deployment
A well-tuned FortiGuard IPS posture isn’t “enabled” or “aggressive,” it’s a sensor whose overrides you can explain individually, sitting on a policy whose CPU/CP9 cost you sized for deliberately, with outbreak coverage treated as the faster-moving exception to the routine signature cadence rather than folded into the same mental model as everything else FortiGuard delivers. None of that shows up as a single setting. It shows up as the accumulated record of decisions about specific signature IDs, made with the hit logs open, over time — which is a less satisfying answer than a best-practice checklist, but it’s the actual difference between a sensor that’s protecting the traffic it sees and one that’s just generating log entries nobody reads.