IPS Custom Policy Best Practices

[WiliRGasparetto]

Increase coverage without blowing up CPU, logs, or false positives

When you customize IPS (the IPS blade inside Threat Prevention), the goal is not “enable everything.” The goal is relevant, measurable coverage for your environment while controlling three critical variables: accuracy (false positives), performance impact, and operability (event volume + triage).

1) Start the right way: baseline profile + controlled rollout

1.1 Use a solid Threat Prevention Profile as your baseline

• Start from a baseline profile (e.g., “Recommended/Optimized”) instead of building everything from scratch on day one.
• Define upfront:
  • Default action: Detect vs Prevent
  • Exceptions: only after evidence, not instinct

1.2 Build a baseline before changing policy

Before enabling additional protections, measure during peak hours:

• gateway CPU / memory / throughput
• IPS event/log volume
• top talkers / dominant applications

IPS tuning without baselines becomes trial-and-error — and MTTR grows the moment something breaks.

2) Technical criteria to decide what to enable

2.1 Severity

• Use Severity for prioritization: High first, then Medium based on risk.
• Interpret it correctly: Severity reflects probable damage if the attack succeeds, not “likelihood.”

2.2 Confidence

• Prioritize High Confidence for early Prevent rollouts:
  • lower false-positive probability
  • safer Detect → Prevent transition
• Low-confidence protections require stricter validation and tighter scoping.

2.3 Performance Impact

• Use the performance attribute to guide rollout:
  • Low/Medium impact: first wave
  • High/Critical impact: only after sizing + real traffic validation
• If the gateway is near saturation, prefer scope-based enablement (networks/hosts/apps) rather than enabling globally.

2.4 Environment relevance (asset-driven IPS)

Your IPS policy should reflect real exposure:

• OS and versions in use
• exposed services (HTTP/S, DNS, SMB, RDP, SIP, etc.)
• critical applications (ERP, VDI, APIs, SaaS)
• attack surface (perimeter vs internal/DC)

IPS is most effective when “where to enforce” is part of the design, not an afterthought.

3) Reducing false positives without losing coverage

3.1 Scope your enforcement by gateway role

• Perimeter gateways: prioritize web exploits, botnets, malware delivery paths
• Internal/DC gateways: prioritize lateral movement patterns (SMB/RDP/AD-related) based on traffic reality

3.2 Exceptions must be evidence-driven and granular

An exception is not “turn it off.” An exception should:

• narrow scope by host/network/service
• allow only a known safe pattern
• document the reason (ticket/incident/validation)
• include a review/expiry date

Best practice: prefer targeted exceptions over globally disabling a protection.

3.3 Disabling “non-applicable” categories is real performance gain

If a category is irrelevant to your environment (OS/service not present), disabling it reduces CPU and noise.

4) Encrypted traffic: HTTPS Inspection, done responsibly

“Enable HTTPS Inspection” is not universal advice — it’s an architectural decision.

4.1 When it makes sense

• when most risk sits inside encrypted web flows (phishing, malware delivery, SaaS/API exfil) and you need visibility for Threat Prevention controls

4.2 Key operational safeguards

• test impact per application (pinning, mTLS, sensitive apps)
• controlled bypass for breaking apps
• rollout by waves (groups/policies)
• align with privacy/compliance requirements

5) Operationalizing IPS: keep it effective, not noisy

5.1 Continuous tuning loop (what mature teams do)

• weekly review of top-triggering protections (volume + severity)
• false positive analysis by application
• small, measurable changes
• quarterly exception review (expiring old exceptions is instant value)

5.2 Keep protections updated

• keep IPS protections current and track meaningful updates
• in critical environments, validate changes under real traffic (staging when possible)
•  

6) Quick decision matrix

Criterion	Initial recommendation	Controlled evolution
Severity	High	Add Medium as needed
Confidence	High	Medium/Low only with validation
Performance Impact	Low/Medium	High/Critical scoped + sized
Relevance	Only applicable to assets	Periodic review as environment changes
Exceptions	Minimal and granular	Review/expire; avoid global disable
HTTPS Inspection	Planned (not automatic)	Wave rollout + governed bypass

 

7) Final TAC-grade notes

• Never disable a protection without:
  • evidence of false positive
  • understanding residual risk
  • an alternative mitigation (granular exception, tuning, segmentation)
• IPS tuning is continuous: baseline → small change → measure → repeat.
• “More protections” is not “better security” if performance/visibility collapses.

If the community wants, I can share a practical “Exception Template” (fields + rationale + expiry) and a short troubleshooting flow to identify which protection is driving CPU/log spikes.

[PedroRFernandes]

Excellent insights, Wili. I’m currently working on a case where the client is experiencing a high volume of false positives on the network caused by poorly defined internal rules. I believe your post will help them when creating their next policies.

[WiliRGasparetto]

That's great that you found this post helpful! I'll post a few more soon.

[PedroMacena24]

Great article! Very functional and easy to follow, with practical best practices that are straightforward to apply in real environments. Thanks for sharing!

[WiliRGasparetto]

Thank's great that you found this post helpful! I'll post a few more soon.

[israelfds95]

This is the way

[WiliRGasparetto]

thank's

[PhoneBoy]

One thing I will point out on this: Detect and Prevent have somewhat different performance characteristics.
This is because in Detect mode, traffic is still passed and inspected, whereas in Prevent, the traffic will be dropped at a certain point.
While I expect this will be environment specific to some degree, Detect likely has a larger performance impact than Prevent.

[Timothy_Hall]

Indeed, here is the content for this exact topic from the upcoming Max Power 2026 book  (link 404 until release).

Performance Impact of Actions: Inactive vs. Prevent vs. Detect

Having a protection set to Detect consumes much more CPU than setting it to Prevent, especially if the protection's Performance Impact rating is High or Critical. An action of “Prevent” immediately kills the offending packet and all its retransmissions, dropping or stalling the rest of the connection if it is TCP–based. A setting of Detect just logs the finding and allows the connection to continue, thus consuming far more CPU as it continues to monitor the live connection for the same or additional threats, potentially logging (but not blocking) the same type of offending event repeatedly. A setting of “Inactive” means the protection is not enforced at all, and the firewall isn’t even looking for it, so no overhead is incurred for that particular protection whatsoever.

As you scroll through the list of protections in the next few sections, ideally, look for any protections set to Detect and either set them to Prevent or Inactive. But at a bare minimum, make sure that any protections with a Performance Impact rating of Critical or High are set to either Prevent or Inactive! Also, be sure to double-check that when you change the Action for a particular Protection, you are doing it for the correct TP profile in use by your firewall. Check the Custom Threat Prevention policy rules to verify which TP profile(s) apply to your firewall; there may be more than one, depending on how your TP policy is configured.

[WiliRGasparetto]

I agree with both of you, @PhoneBoy  and @Timothy_Hall ; the detection action really serves as a way to analyze whether a specific signature makes sense for the environment, so it depends heavily on the client's architecture. And @Timothy_Hall , I’m eagerly awaiting the release of your book so I can get a copy.