Contractor SaaS Allow-List and App-ID Visibility
A company uses Salesforce and Workday. Contractors on a separate VLAN must use only those two SaaS applications plus Microsoft 365, and must not use personal Gmail or Dropbox. The firewall currently has a rule from Contractors to Untrust with application any and service any, and a URL filtering profile blocking personal-storage and web-based-email. SSL decryption is enabled only for the finance and health URL categories. Contractors report that Salesforce works, but Workday is slow and sometimes blocked, and Dropbox uploads succeed when users type the IP address of the Dropbox endpoint. The security team sees application ssl instead of workday for most Workday sessions.
1. Why does the firewall show ssl instead of workday for Workday sessions, and how do you improve identification without breaking pinned apps?
Read the worked answer
App-ID can identify Workday from TLS SNI, certificate, or payload, but without decryption it may see only SSL/TLS to a shared CDN, especially with TLS 1.3, ESNI, or certificate pinning. Workday also uses multiple domains and CDNs. Because decryption is limited to finance and health, business SaaS is not decrypted. Add a decryption policy for the SaaS URL categories or specific Workday domains, with a no-decrypt exclusion for pinned applications. Use a decryption profile to block unsupported versions and ciphers. Verify App-ID after decryption with a canary policy. If decryption is not possible, use application filters and URL categories, but accept weaker identification. Do not allow ssl broadly as a workaround.
2. Dropbox uploads succeed when users type an IP address. What is the failure, and how do you enforce the contractor allow-list?
Read the worked answer
URL filtering needs a URL, domain, or SNI. An IP-only HTTPS session has no meaningful URL category and may show ssl or unknown, so the personal-storage block does not match. The broad allow with application any and service any also permits it. Enforcement must be positive: replace the broad rule with a rule allowing only approved applications such as salesforce, workday, and ms-office365, plus required dependencies, and deny all below. Do not allow ssl as a catch-all. For IP-based access, use App-ID where possible, decrypt SaaS categories, and if needed use an EDL of known Dropbox IPs, recognizing that EDLs are brittle. Log denied sessions and tune.
3. Design the contractor security policy and profiles. Include application dependencies and where URL filtering fits.
Read the worked answer
Rule 1: source Contractors, destination Untrust, applications salesforce, workday, and ms-office365, service application-default, action allow, with vulnerability, anti-spyware, URL filtering, and decryption profiles. Rule 2: allow DNS to the internal resolver. Rule 3: deny all with logging. SaaS applications depend on ssl and web-browsing; App-ID may require allowing ssl as a dependency, but if ssl is allowed broadly, URL filtering and decryption must restrict it. Prefer allowing the specific SaaS applications and letting App-ID resolve dependencies; otherwise use application filters. URL filtering is a profile on allowed traffic, not a substitute for App-ID. Test with contractor accounts and monitor deny logs for legitimate SaaS endpoints.