Decryption coverage, an ICAP DLP blind spot, and a failed backup after upgrade
Halcyon Financial has 4,000 users and 85 percent HTTPS. A WSA pair performs decryption with a self-signed CA distributed only to Windows machines by GPO; 900 macOS and iOS devices are enrolled in MDM but the certificate was never pushed there. The decryption policy does not decrypt Financial Services or Health categories, and a manual do-not-decrypt list holds 60 domains including Office 365 and Salesforce, which break when decrypted. DLP is provided by an external engine reached over ICAP on TCP 1344. Since the cutover, DLP incidents are roughly 80 percent below the baseline the DLP team measured on the previous forward proxy. The team upgraded AsyncOS from 12.5 to 14.0 last month; they report that the DLP policy no longer appears to apply to the Trading identity profile, and the nightly configuration backup to SCP now fails with permission denied.
1. What are the plausible causes of the 80 percent DLP drop, and how would you isolate the actual one?
Read the worked answer
DLP can only inspect what reaches it in cleartext through the ICAP path, so work the path end to end instead of starting with the DLP server.
Candidate causes:
- Decryption gaps. Any HTTPS session that is not decrypted is invisible to the DLP engine. The Financial Services and Health category exclusions plus the 60-domain list may cover exactly the destinations the DLP team cares about (banking portals, webmail, SaaS uploads).
- Policy binding. If the DLP policy is not attached to the access policy serving the Trading identity profile, uploads from that population are never sent to ICAP. This is the most likely explanation for the post-upgrade symptom specifically.
- Connectivity. The ICAP server must be reachable from the data interface path used for proxied requests, not just from management. A firewall rule permitting management-to-DLP but not data-to-DLP would produce a silent or log-only failure depending on the failure mode configured.
- Baseline mismatch. The old forward proxy may have handled different traffic or used a different DLP rule set, so some of the 80 percent may be a measurement artefact.
Isolation: pick three known file-upload test cases (one to a decrypted SaaS site, one to a do-not-decrypt domain, one from the Trading profile) and follow each through decryption policy, access policy, DLP policy, and ICAP server logs. The one that never reaches the ICAP log localises the fault.
2. How would you expand decryption without breaking pinned applications or leaving Mac and iOS users untrusted?
Read the worked answer
Treat decryption as three decisions: who is decrypted, what is decrypted, and what the client trusts.
Client trust: push the WSA signing certificate through MDM to macOS and iOS. Until that is done, expanding decryption to those devices will generate certificate warnings and user workarounds. Use an enterprise CA rather than a self-signed certificate so the trust can be rotated and audited.
Who: apply decryption broadly to managed identities (Windows, managed Mac, managed iOS) and keep unmanaged or guest devices on a narrower policy. A single global "decrypt everything" policy is what creates the pinning failures.
What: replace the blunt category exclusions with a targeted approach. Keep a do-not-decrypt list for applications that pin certificates, and where possible narrow it to specific hostnames rather than whole categories. For Office 365 and Salesforce, test per-application: many endpoints accept an enterprise CA, but specific components (real-time media, some mobile clients) still pin and will fail. Record each exception with an owner and a review date.
Verify: after each change, test with a known pinned application and a known decrypted site from each managed platform, and check the decryption policy reports to confirm the intended categories are actually being decrypted rather than falling through to a default.
3. What is your recovery plan for the DLP binding and the failing backup, including upgrade rollback?
Read the worked answer
Handle the policy regression before touching the backup, because the backup is what protects the recovery.
DLP binding: confirm in the access policy for the Trading identity profile that the correct DLP policy is selected, and compare the configuration against a pre-upgrade backup to see whether the association changed or a referenced object was renamed. Re-apply the binding, then test with a real upload. If the binding is correct and incidents still do not appear, check ICAP reachability from the data path and the DLP server's own logs before assuming an AsyncOS defect.
Backup: the permission-denied error after an upgrade usually means the SCP account, key, or target directory permissions changed, or the host key is no longer trusted. Create a dedicated backup account with write access to the target directory, test an interactive backup, then re-enable the schedule. Verify by restoring the configuration to a lab appliance or at least by inspecting the archive contents, because a backup that has never been restored is unproven.
Rollback: before any further upgrade, take a fresh configuration backup and confirm the appliance's revert capability and the window in which it remains available. Document the sequence: stop changes, back up, record the current build, upgrade, validate decryption, DLP binding, authentication, and backup, and only then close the change. If validation fails, revert using the supported mechanism rather than trying to unwind individual settings.