Any/Any, QUIC and a Category Block That Broke the Sanctioned SaaS
Tailspin runs a 'Trust to Untrust, any application, allow' rule at the top of its Prisma Access policy with a strict Threat Prevention profile and WildFire attached, followed by a decryption policy that decrypts everything except the 'financial services' URL category. A user downloaded an ISO from a legitimate file-sharing SaaS over TLS 1.3 and executed it; no WildFire verdict was ever generated for the file. In response, the team inserted a rule blocking the 'file-sharing' category above the allow rule. Two days later, sales cannot use the corporate-sanctioned SaaS CRM, which the vendor's URL database categorizes as file-sharing, and the developer team's container registry pulls now fail. Separately, the finance team's banking portal returns certificate errors after an engineer 'fixed' the decryption policy to decrypt all categories.
1. Why was no WildFire verdict generated for the ISO download, and how would you confirm the cause?
Read the worked answer
A security profile only inspects what the session gives it. Start from the traffic log for that user and that SaaS, filtered to the incident window, and read four fields: Application, Decrypted (yes/no), Session End Reason, and whether any file was submitted.
Most likely cause: QUIC. With an any/any rule permitting application 'quic', browsers will prefer HTTP/3 over UDP 443. QUIC is not decrypted by the forward proxy, so the file transfer stays opaque: no file extraction, no WildFire submission, no verdict. This exactly matches 'legitimate SaaS, TLS 1.3, no verdict.' Confirm by looking for quic sessions from that user in the log.
Other candidates to rule out:
- Encryption Client Hello or an unresolvable SNI, leaving the session as ssl or insufficient-data with no decryption - check the Application and Decrypted fields.
- A decryption exclusion matching the destination, for example if the SaaS resolves into the financial services category through a CDN.
- The file exceeding the WildFire maximum size or being an unsupported type, which would show as a submit failure rather than no submission.
Remediation: block quic so browsers fall back to TCP 443 where decryption applies; replace the any/any rule with application-specific allows so unexpected applications cannot ride on a blanket permit; keep the Threat Prevention and WildFire profiles attached to those rules and verify with a known-good EICAR-style test that a verdict actually appears. Then re-test the same download path and confirm a submission is logged.
2. How would you restore access to the sanctioned SaaS CRM without reopening the file-sharing gap, and what does this tell you about the rule design?
Read the worked answer
The block rule is doing what it was told; the policy design was the problem. Category-based blocking cannot distinguish a sanctioned tenant of a file-sharing service from a consumer one.
Immediate fix: put an exception above the category block that allows the specific CRM by App-ID - or, if App-ID is not granular enough for the tenant, by a custom URL category containing the tenant's exact FQDNs - and scope it to the sales user group rather than everyone. Leave the category block below it so unsanctioned file-sharing stays blocked. Log at session end and review the exception weekly to confirm usage matches expectation.
What this reveals about the original design: a single any/any allow means every policy decision is made by whichever profile or category rule happens to be attached, and exceptions get bolted on top under incident pressure. The order of the rulebase - broad allow at the top, specific intent buried in exceptions - is backwards.
Better structure: deny known-bad categories and high-risk applications at the top; then application-specific allows, scoped by user group and destination, with the appropriate security profiles; default deny at the bottom. Use SaaS tenant controls where the platform supports them to restrict the sanctioned instance. Test any new category rule in a monitor-only posture or against a pilot group first, and always ask which sanctioned applications live in that category before blocking it wholesale - the URL database's categories are a starting point, not a representation of your business intent.
3. What is your recommendation for the finance banking portal and the container registry, given that decrypt-all breaks both?
Read the worked answer
Breakage here is expected, not a defect. Certificate pinning and mutual TLS both assume the endpoint's certificate chain is the one the server presents; a forward proxy that re-signs the connection violates that assumption. A container registry using client certificates will also fail because decryption terminates and re-originates the TLS session.
Recommendation: target decryption, not blanket decryption. Build decryption rules that cover the categories and applications that matter - general web browsing, webmail, unsanctioned file transfer, uncategorized sites - and add no-decrypt rules for the specific banking destinations and registry FQDNs or applications. Order matters: the no-decrypt rule must be evaluated before the decrypt rule, and it must log so you can see what is being exempted rather than creating a silent blind spot. If the banking portal is already covered by the financial services category, fix the rule that overrode it rather than carving out a new one.
Accept and compensate. Exempted flows get no content inspection, so compensate with the controls that still work on an encrypted session: App-ID and URL filtering on the observable metadata, destination-based EDLs, user-based policy, and endpoint protection. Document the exemption with an owner and a review date.
Roll out safely. Enable new decryption in stages, watch for user-reported pinning failures per application rather than reacting site by site, and prefer narrow exceptions over broad category exclusions - one no-decrypt for a registry FQDN is a much smaller blind spot than a global no-decrypt for all business categories.