Deep Inspection Breaks SaaS and Saturates CPU
An insurance company runs a FortiGate 600E with 4,000 daily users. A single outbound policy applies deep SSL inspection, web filtering, IPS, and antivirus to all HTTPS traffic. The internal CA certificate is deployed by Group Policy to domain-joined Windows laptops only. Contractors, mobile devices, and a growing BYOD population do not trust the CA. Since a recent profile update, users report certificate warnings on banking and healthcare portals, Teams and Zoom calls fail, and the FortiGate CPU reaches 85% during peak hours. The web filter blocks newly registered domains, and the IPS profile blocks a signature that the claims team says is a false positive on an internal application. Security leadership will not approve disabling deep inspection globally or removing IPS. They want a targeted design that preserves inspection where it matters and reduces helpdesk load.
1. Design an SSL inspection and policy structure that reduces breakage without abandoning deep inspection.
Read the worked answer
Split the single outbound policy into at least three profiles. For domain-managed Windows devices, keep deep inspection but exempt financial and healthcare categories and known pinned applications using SSL exemption entries; certificate inspection still gives category and certificate visibility without breaking pinning. For BYOD, contractors, and mobile, either deploy the CA through MDM or use a policy with certificate inspection only, not deep inspection. For high-risk categories such as newly registered domains, keep deep inspection where the client trusts the CA. Do not create a global no-inspection policy. Use address and user groups in policy so the decision is based on device trust, not destination alone. Validate with a small pilot group and check the SSL exemption log to ensure the intended traffic is exempted, not silently bypassed.
2. How would you validate and tune the IPS false positive safely?
Read the worked answer
Find the signature ID and destination in the IPS log, then reproduce with a test client on the claims subnet. Clone the IPS profile and set that signature to monitor, not block, so traffic is logged but not dropped. Confirm the application works and that no other signatures are involved. If the signature is a true false positive for that internal app, add a narrow exception for the specific destination or signature rather than disabling the profile. Keep the production profile blocking for all other traffic. Test during a low-risk window, compare IPS logs before and after, and document the exception with an expiry date for review. Never set the whole IPS profile to monitor just to resolve one application.
3. Explain the performance tradeoffs and what changes you would make to protect peak-hour capacity.
Read the worked answer
Deep inspection is CPU-intensive because decryption and re-encryption are not fully offloaded like plain forwarded traffic. Use flow-based inspection where the profile allows it, reserve deep inspection for managed devices and high-risk categories, and avoid inspecting bulk backup or video categories that do not need it. Check get system performance status and diagnose sys top during peak to see whether CPU is consumed by inspection or by logging. Reduce logging of allowed sessions if log processing is contributing. If peak load still exceeds capacity, add a dedicated inspection policy for the highest-risk user group or schedule full inspection outside peak hours; do not simply disable antivirus or IPS globally.