TLS Inspection, Certificate Pinning, and Clinical Bypass
Lakeside Regional Hospital has 2,400 staff and 3,000 managed devices. A FortiGate 401F HA pair protects a 1 Gbps ISP link. The security team enabled deep TLS inspection on all outbound HTTPS to stop malware and data exfiltration. Within a week, the new cloud EHR client fails with certificate errors; the vendor says its app uses certificate pinning and will not support a proxy CA. FortiGate CPU averages 88% at shift change and users report 45 ms of added latency. Clinical staff have started using personal hotspots to reach the EHR. Compliance requires malware inspection, but privacy policy restricts inspection of clinical data. The CISO asks for a revised inspection design before the next audit.
1. Why does the EHR client fail, and what exemption design is defensible without disabling inspection globally?
Read the worked answer
The EHR client fails because certificate pinning trusts only the vendor's chain; the FortiGate proxy CA is not trusted, so the client rejects the inspection certificate. A defensible exemption is narrow: exempt only the EHR vendor's published domains or ISDB entries from deep inspection, not all healthcare or all HTTPS. Put those domains in a separate policy with application control, FortiClient or EDR, and destination restrictions, and log the exemption. Document the risk acceptance and review it quarterly. Do not disable deep inspection globally and do not ask the vendor to weaken pinning. If the vendor supports a proxy CA or a dedicated inspection endpoint, prefer that. Confirm the exemption does not open a path for malware; the endpoint control and egress restrictions are the compensating controls.
2. How do you address the 88% CPU, 45 ms latency, and clinical staff using personal hotspots?
Read the worked answer
The 88 percent CPU and 45 ms latency indicate the inspection profile is too broad for the platform and traffic mix, not that inspection is impossible. Split policies by user group and destination risk: inspect uncategorized, newly registered, and high-risk categories; use certificate inspection or exemption for trusted categories with compensating controls; reduce logging of allowed sessions; verify flow-based versus proxy-based mode and hardware acceleration. Check which profiles are applied to guest, IoT, and clinical devices. Size the FortiGate against rated SSL inspection throughput with headroom, or offload guest traffic to a separate pair. For personal hotspots, you cannot inspect them at the perimeter; use FortiNAC to enforce managed devices on clinical VLANs and user education, and report the bypass as a policy exception. Validate latency with a pilot before broad rollout.
3. What evidence would you present to the auditor to show the revised design is risk-based rather than an inspection bypass?
Read the worked answer
For audit, produce a current exemption inventory: domain, business owner, reason, compensating control, approval date, and review date. Show that deep inspection remains on for general internet traffic and that the EHR domains are logged. Provide FortiAnalyzer reports for inspection coverage, blocked malware, and exemption usage. Test with a safe malware sample or EICAR where policy allows. Show that personal hotspots are addressed through NAC and policy, not ignored. The audit argument is risk-based: pinning cannot be inspected without breaking the app, so the control is endpoint protection plus narrow egress and monitoring. If the auditor requires full inspection, escalate the conflict rather than silently disabling controls.