CCSE Exam study materials
CCSE Exam study resources

HTTPS Inspection Saturation on a 5900 Gateway

CCSE Exam · Put your knowledge to work in context.

All case studies

HTTPS Inspection Saturation on a 5900 Gateway

A 5900 Security Gateway protects 8,000 users and 1.4 Gbps of outbound traffic. The Threat Prevention profile blocks IPS, Anti-Bot, and Anti-Virus, and outbound HTTPS inspection is enabled for all categories. During a quarterly audit, the gateway's eight vCPUs stay above 95 percent, latency to SaaS increases from 18 ms to 310 ms, and fw_worker processes show high CPU. SecureXL is enabled and the rulebase is clean. The customer wants to keep TLS 1.3 inspection for finance and HR but reduce load for the other 90 percent of users. There are two 10GbE uplinks in an active/active bond, and the 5900 is not clustered. No additional appliance budget is approved this quarter, and the audit starts in 10 days.

1. Why does enabling HTTPS inspection reduce throughput even though SecureXL is enabled?

Read the worked answer

SecureXL accelerates the TCP and packet path, but HTTPS inspection is a proxy function. Decrypted traffic must be handled by the mediation and worker path so that IPS, Anti-Virus, Anti-Bot, and content checks can inspect the payload. That moves a large share of the connection from the accelerated path into the slow path. The effect grows with TLS 1.3, large downloads, and many concurrent inspected connections because each inspected flow consumes proxy memory and worker CPU.

The symptom pattern confirms this: high fw_worker CPU with SecureXL enabled, rising SaaS latency, and a gateway that is not clustered. SecureXL cannot accelerate payload inspection, and adding more IPS signatures or AV scanning to every decrypted flow makes the slow path the bottleneck. The design question is therefore not 'turn on SecureXL' but 'which flows truly need decryption and full payload inspection.'

2. Propose a rule and profile design that keeps inspection for finance and HR while reducing load for other users.

Read the worked answer

Use identity-aware HTTPS inspection policy rather than a global on/off switch.

  • Create an inspection policy with a first rule for Finance and HR identity groups, destination Any, action Inspect. Keep IPS, Anti-Bot, and Anti-Virus on this rule.
  • Add a second rule for the remaining users with action Bypass for HTTPS inspection, but keep IPS and Anti-Bot enabled on the clear-text metadata and on non-inspected traffic. Do not bypass Threat Prevention entirely.
  • For non-finance downloads, use Threat Extraction instead of full Anti-Virus scanning where content reconstruction is acceptable. This removes active content and reduces AV load.
  • Apply an IPS profile with 'bypass under load' only as a safety valve, not as the primary design. It protects availability but reduces detection, so document the trade-off.
  • Exclude certificate-pinned applications and categories that cannot be inspected cleanly, and use a separate bypass rule with logging so the audit trail shows why traffic was not decrypted.

This keeps the compliance-critical population under TLS 1.3 inspection while removing 90 percent of decrypted flows from the proxy path.

3. What metrics would you monitor to prove the change works, and what is your rollback plan?

Read the worked answer

Monitor per-core CPU and fw_worker utilization in cpview, concurrent inspected connections, HTTPS inspection throughput, and SaaS latency before and after the change. Use fwaccel stats -s to confirm the accelerated path is carrying more traffic, and tpstat to watch Threat Prevention queue depth and inspection latency. Check logs for bypass reasons and for finance/HR flows that accidentally match the bypass rule.

Success criteria: CPU below 75 percent at peak, SaaS latency back under 50 ms, no increase in unresolved Threat Prevention queues, and 100 percent of finance/HR HTTPS flows still inspected. Rollback: disable only the non-finance bypass change and restore the previous global inspection rule, keeping the finance/HR rule intact. Because the audit is in 10 days, stage the change in monitor mode first, compare one peak day, and keep the old profile exportable. If CPU remains above 90 percent, the next lever is capacity or a second gateway, not disabling inspection for finance and HR.