Security Policy and Threat Prevention
Decryption first, policy second
Two rulebases, evaluated in order. The decryption policy decides what is decrypted using SSL forward proxy, a forward-untrust certificate and a decryption profile that controls unsupported versions and cipher suites. The security policy then sees App-ID on the decrypted stream. A bypassed session shows only ssl and web-browsing, so a rule written against a SaaS application name never matches.
What to attach, and where
Attach a profile group to every allow rule: Anti-Spyware with DNS sinkhole and botnet domains, Vulnerability Protection, Anti-Virus, WildFire inline, URL Filtering, File Blocking, Data Filtering and DNS Security. A workable ordering is: block known-bad categories and threat sources at the top, specific allow rules with profiles in the middle, explicit deny with logging at the bottom. Remember the defaults - intrazone-default allows, interzone-default denies without logging - so "it was allowed by default" is rarely the real story.
Worked example
Engineering must use a sanctioned SaaS code repository but must not upload source archives. After decryption, App-ID identifies the application. On the allow rule, attach SaaS Security inline policy to restrict tenant and actions, plus Data Filtering or DLP to block archive and source file types on upload. Leave download permissive. Without a decryption policy covering that category none of it triggers, and the endpoint must trust the forward-untrust CA or users see certificate errors.
Traps
- Attaching threat profiles to a deny rule and expecting them to fire.
- Forgetting exemptions for certificate-pinned applications, which break when decrypted.
- Treating DNS Security as a URL Filtering substitute: it stops resolution, but cannot see paths or apply SaaS controls.
- Reading a mid-stream block as an allow because the session started with an allow rule.