Your CISO asks why ZIA needs both Malware Protection AND Advanced Threat Protection — "isn't ATP just better malware?" You explain that disabling either creates a blind spot. Which statement best captures the actual difference?

Correct answer: (b) Malware Protection is signature/heuristic/ML on the actual file bytes streaming through ZIA. ATP is destination & behaviour focused — URL reputation, IOC feeds, C2 callback patterns, phishing pages, cryptominers — many of which don't involve a downloadable file at all. Correct: (b). Malware scans the bytes; ATP scans the context (destination, IOC, behaviour). A phishing landing page has no malicious file to scan — only ATP catches it. A novel binary downloaded from a clean-reputation site has no IOC hit — only Malware/Sandbox catches it. (a)/(c)/(d) are wrong — both engines run in ZIA cloud against the same decrypted stream and are not duplicates.

You're designing the Sandbox rule for a 4000-user tenant. Engineering downloads .exe build tools daily; sales downloads .pdf proposals. Which Hold-and-Deliver choice is most defensible to the business?

Correct answer: (c) Hold-and-Deliver for executables and macro-enabled office docs; Out-of-Band quarantine for low-risk types like plain PDFs. Add a Bypass-Internal-Trusted rule for hash-verified internal artifact sources to keep CI/build pipelines from queuing. Correct: (c). Tier the policy by risk: high-risk file types (executables, macros) get Hold-and-Deliver where blast radius is biggest. Low-risk types (plain PDFs) get faster Out-of-Band. Trusted internal sources get an explicit bypass so build pipelines don't queue. (a) is overkill — adds latency to safe types. (b) abandons your zero-day defence. (d) time-window logic is operationally absurd; attackers don't keep office hours.

You just enabled Sandbox in Hold-and-Deliver mode for all executables. Engineering's CI pipelines now stall on internal Artifactory downloads. The fastest panic-fix is "disable Sandbox for executables." What should you do instead?

Correct answer: (c) Add a scoped Sandbox Bypass rule for the internal Artifactory URL/IP for the CI service accounts (and engineering group), keeping Hold-and-Deliver active for every other source. Internal artifacts are already hash-verified upstream — there is no security value in re-detonating them. Correct: (c). Scoped bypass for one trusted internal source preserves protection for the other 99% of executables. Internal Artifactory is signed/hash-verified by your own pipeline, so detonating it adds latency without adding security. (a) opens a giant hole. (b) leaves you blind to known malware. (d) doesn't address the root cause and isn't operationally meaningful.

Insights → Web shows an ATP "Suspicious Destinations" block for an internal Jenkins URL. The dev team wants the category disabled. What's the right play?

Correct answer: (a) Add the internal Jenkins URL/IP to the ATP Bypass list (per-URL exemption), so Suspicious Destinations still blocks every other low-reputation domain. Optionally also add it as a URL Filtering allowlist category for clarity. Correct: (a). Per-URL exemption is the precise fix; the category stays on and continues to protect against thousands of legitimately-bad newly-registered domains. (b) creates a category-wide hole for one false positive. (c) over-rotates — disabling ATP for a group opens phishing, cryptomining, and C2 visibility. (d) ignores the actual problem.

A user reports a stalled .docm download from a partner site. You suspect Sandbox. Where in the ZIA admin portal do you confirm and view the per-file verdict report?

Correct answer: (b) Analytics → Insights → Web → filter by user/URL, then drill into the matching log row → Sandbox tab shows verdict + behavioural report (registry writes, network calls, MITRE ATT&CK mapping). Correct: (b). Insights → Web is the unified per-transaction log; clicking into a row opens the Sandbox tab when applicable, with the full behavioural report. (a) is for site/location config. (c) is the policy editor, not the log. (d) is for admin-action audit (logins, rule changes), not user traffic.

Your build server CI tools are flagged repeatedly by Malware Protection's heuristic engine even though they're internal-signed binaries. What's the cleanest long-term fix?

Correct answer: (d) Publish SHA256 hashes from your build pipeline on every release to the Malware Protection File Hash custom allowlist (via the documented /api/v1/securityPolicySettings endpoint), so the specific binary hashes are explicitly trusted while the engine still scans everything else. Correct: (d). SHA256 hash allowlist driven by your CI/CD is the surgical, auditable, low-risk fix — only the exact byte sequences you produced are trusted, and the entry is auto-updated each build. (a) blinds the engine to entire heuristic families. (b) creates a privileged-account-shaped hole. (c) is wasted effort that won't necessarily change heuristic verdicts.

A user's HTTPS request to a normal-looking SaaS site is suddenly blocked by ATP under "Cryptomining & Cryptocurrency Miners". The user insists they didn't open any miner. What's the most likely cause and right next step?

Correct answer: (a) The SaaS page loaded an embedded third-party script (ad network, compromised CDN, dependency) that contains an in-browser miner. ATP detected the miner script behaviour in the page content. Investigate via Insights → drill into the destination URL; flag the third-party CDN to the SaaS vendor; keep ATP block in place to protect the user's CPU and battery. Correct: (a). Pages embed many third-party scripts the user never sees; a compromised dependency can inject a cryptominer (the Magecart-style supply-chain pattern is the same idea applied to mining). ATP sees the miner behaviour in the page content and blocks. (c) is the wrong framing. (b) creates a tenant-wide hole for one event. (d) doesn't address the root cause at all.

Browser Control is set to block IE11. After the company finished Win11 rollout, helpdesk reports new tickets — users in Edge with legacy IE-mode tabs are being blocked from intranet apps that require IE-mode for compatibility. What's the right adjustment?

Correct answer: (b) Audit the Browser Control rule: keep the standalone IE11 block but exempt the specific intranet URLs that legitimately need IE-mode, OR scope the IE-UA block to external destinations only. Pair with a quarterly Browser Control audit against actual fleet UA telemetry so stale rules don't keep creating false friction. Correct: (b). Scope the block to where the risk lives (external) and exempt the internal apps that require IE-mode for compatibility — keeps the protection on while resolving the operational friction. Quarterly audits prevent stale Browser Control rules from being a chronic helpdesk source. (a) reintroduces IE11 exposure on the open internet. (c) over-rotates. (d) doesn't fix the underlying intranet-app compatibility requirement.

Sandbox detonates a download and returns verdict "Suspicious" (not "Malicious"). Default policy is set to Block on Suspicious. The user files a ticket — they need the file. What's the right L3 response?

Correct answer: (d) Open the Sandbox per-file report in Insights → review the behavioural indicators (registry writes, network calls, MITRE mapping, file source). If the indicators are clearly benign-but-noisy and the file source is trusted, add a targeted SHA256 hash allowlist entry. If the indicators look genuinely IOC-y or the source is unverified, hold the block and escalate to the SOC for additional analysis. Correct: (d). Suspicious is a "borderline, needs judgment" verdict — the full behavioural report is exactly the input you need. Targeted SHA256 allowlist if benign; SOC escalation if questionable. (a) is superstition. (c) is the worst kind of blanket downgrade. (b) is a severe security policy violation regardless of the verdict.

Your SOC manager asks: "When a Malicious verdict fires in Cloud Sandbox at 03:00, does a ticket open in our SIEM automatically?" You realise you never wired the integration. What's the correct architecture to fix this fleet-wide?

Correct answer: (c) Stand up an NSS (Nanolog Streaming Service) instance, configure NSS Web Logs with the threatcategory , threatname , threatclass , mwcat , and sandbox_verdict columns enabled, and forward in real time to the SIEM. Add a correlation rule: sandbox_verdict = "MALICIOUS" OR threatcategory IN ("Phishing","Cryptominer","BotnetCallback") → auto-open SOC case with the full log row + per-file report link. Correct: (c). NSS is the production-scale telemetry path — sub-second forwarding of every web log to the SIEM with the threat columns enabled, then a SIEM correlation rule to open SOC cases at machine speed. (a) doesn't scale and loses the 03:00 incident. (b) is too slow for threats. (d) is the wrong direction entirely.

Threat Protection — Malware, ATP, Sandbox & Browser Control — Batch 11 · Lesson 7

Why this lesson matters

SSL Inspection (Lesson 6) gives ZIA the cleartext stream. Threat Protection is what justifies the price tag once that stream is visible. URL Filtering only blocks bad domains. Threat Protection blocks bad content — the actual payload, the actual JavaScript, the actual binary that's about to drop a ransomware DLL on a finance laptop.

When the CISO asks "what stopped the breach that hit our competitor last week?" the answer is rarely "URL Filtering." It's one of four engines: signature AV caught the known dropper, ATP caught the C2 callback to a freshly-registered domain, Cloud Sandbox detonated the .docm and flagged the macro behaviour, or Browser Control blocked an IE11 client from rendering the exploit kit. As an L3, you're the person who tunes those engines so they fire when they should and stay quiet when they shouldn't. Get it wrong in either direction and you lose — too loose: zero-day walks in; too tight: engineering can't pull build tools and Procurement asks why you're paying for a security cloud that breaks work.

The four layers of ZIA threat defense

ZIA inspects every fetched object through four engines. Each catches a different threat class — overlap is intentional. Turn one off, you create a blind spot the others can't fill.

Note: ATP and Malware Protection run on response content (server → client) while Browser Control evaluates on request (User-Agent). Drawing them as a strict series is a teaching simplification; in production they fire on different transaction phases.

From PAN/Fortigate: ATP ≈ Wildfire (behavioral cloud sandbox + ML); IPS ≈ Threat Prevention (signature-based). Two engines, two policy families in ZIA.

Engine	What it inspects	Detection method	Catches
Malware Protection (AV)	File payloads (after SSL decrypt)	Multi-engine signatures + heuristics + ML	Known malware families, viruses, trojans, PUAs, spyware, adware
Advanced Threat Protection (ATP)	URLs, destinations, page content, callback patterns	Cloud reputation, IOC feeds, behavioural signatures	Phishing pages, C2 callbacks, cryptominers, browser exploits, anonymizers, suspicious destinations, botnets
Cloud Sandbox	Files that pass AV/ATP but match a sandbox-eligible type	VM detonation + static AI/ML + behavioural verdict	Zero-day malware, polymorphic samples, document macros, novel droppers
Browser Control	User-Agent, plugin versions, document app versions	Version-string detection + policy match	Vulnerable browsers (IE11, EOL Chrome), legacy Java applets, unpatched Adobe Reader, ActiveX, Flash

SVG #1 — Layered defense stack: how a request walks through the four engines

Each engine evaluates independently. A single request can pass three layers and be blocked at the fourth. Every action — block or allow — writes to Insights and NSS for SIEM consumption.

Malware Protection — the first signature gate

Classic AV, cloud-delivered. Unlike a laptop AV that needs daily signature pulls, ZIA's malware engine refreshes from Zscaler's ThreatLabz cloud continuously — new signatures land in your tenant within minutes. No update window to schedule, no out-of-date client to worry about. Internally it's a stack: multiple commercial AV signature databases in parallel, a heuristic engine for variant detection, and an ML model for "looks like family X". Files are scanned inline as they stream through the PSE — for clean files this adds <100ms; for large files the engine uses chunked scanning so bytes flow as soon as they're cleared.

What it inspects

Windows PE (.exe, .dll, .sys, .scr), macOS Mach-O, Linux ELF binaries
Office docs (.doc/.docx/.xls/.xlsx/.ppt) including macro-enabled .docm/.xlsm/.pptm
PDFs and embedded JavaScript inside PDFs
Archives — .zip, .rar, .7z, .tar, .gz (recursive, with depth limit)
Scripts — .js, .vbs, .ps1, .bat, .sh; mobile installers — .apk, .ipa

Configuration path

ZIA · Malware Protection policy

Policy → Malware Protection → Malware Protection Policy

  Inspection:           ENABLED   (default; only off for compliance carve-outs)

  Malware Categories:
    Adware              Block + log
    Spyware             Block + log
    Virus               Block + log + alert
    Trojan              Block + log + alert
    Worm                Block + log + alert
    P2P / IRC malware   Block + log
    Webspam             Allow + log  (often noise-heavy; tune per tenant)
    Cross-Site Scripting (XSS detection) Block + log
    Unauthorized Communication  Block + log

  Suspicious Content Protection:
    Detect & block files with embedded executables    ON
    Detect & block password-protected archives        ON (pair w/ Sandbox)

  File Hash Custom List:
    SHA256 allowlist  →  hashes of your known-good build artifacts
    SHA256 blocklist  →  IOC hashes from your TIP / MISP feed

  Send Notifications:   ON  (user sees branded block page w/ ticket link)

💡Pro Tip — wire the SHA256 allowlist to your build pipeline

Internal builds (your own signed installers, custom DLLs, in-house Python wheels) regularly trip heuristic AV because they look like generic dropper templates. Don't disable scanning — publish SHA256 hashes from CI/CD on every build and push them to the Malware Protection allowlist via the documented API endpoint /api/v1/securityPolicySettings. One automation; thousands of false positives gone.

Advanced Threat Protection (ATP) — the destination & behaviour layer

ATP is not "malware scanning, but more advanced" — it's a different problem entirely. Where Malware asks "is this file's bytes-on-the-wire known bad?", ATP asks "is the destination, the URL, or the request pattern itself indicative of attack?" Concretely it fires on threats that don't depend on a file at all — phishing landing pages, JS-based browser exploits, cryptominer scripts running in the page, C2 callbacks to algorithmically-generated domains, anonymizer use, and traffic to destinations on Zscaler's IOC feeds (ThreatLabz research plus third-party intel).

ATP categories you'll configure

Category	What it catches	Sane default
Malicious URLs	URLs on the live ThreatLabz blocklist	Block + alert
Phishing	Credential-harvest pages, brand-impersonation domains	Block + alert + notify user
Cryptomining	In-browser miners (CoinHive lineage), wallet-drain scripts	Block
Suspicious Destinations	Newly registered, low-reputation, parked, fast-flux domains	Block (high catch on emerging threats)
Anonymizer	Tor exit nodes, public proxies, "anonymous" VPNs	Block (policy bypass risk)
Botnet Callback / C2	Known C2 panels, DGA-pattern domains	Block + alert (lateral movement)
Browser Exploits	Exploit kit pages (RIG, Fallout, Magnitude lineage)	Block + alert
Adware/Spyware (in-page) & Webspam	Trackers, adware loaders, SEO-spam pages	Allow + log (high-noise; tune per tenant)

How ATP differs from URL Filtering

This trips up every new engineer. URL Filtering uses categories (Sports, News, Adult, Gambling) — slow-moving, manually curated taxonomies; it's your acceptable-use enforcer. ATP uses threat verdicts — fast-moving, IOC-driven, updated minute-by-minute as ThreatLabz pushes new intel; it's your security enforcer. A site can be URL-categorised "Business" (URL Filter allows) but ATP-flagged "Suspicious Destination" because it was registered four hours ago — ATP blocks. Both engines run; the more restrictive verdict wins.

⚠Common Mistake — disabling ATP for a "false positive" that wasn't

An internal dev tool gets ATP-blocked under Suspicious Destinations. First impulse: disable the category — don't. Almost always the destination is genuinely on the IOC list (newly registered, low reputation, sketchy issuer). Right fix: per-URL or per-IP exemption on the ATP rule, not a category-wide toggle. Disabling the whole category opens thousands of legitimately-bad sites for one false positive.

Cloud Sandbox — the zero-day catcher

The Malware engine can only block files whose signature is already known. Cloud Sandbox closes that gap. When an inline file passes AV but matches a sandbox-eligible type (unknown PE, unknown .docm, unknown .zip from a new destination), ZIA copies the file to a sandbox VM, executes it in an instrumented environment, observes behaviour for 30–120 seconds, and returns a verdict.

Hold-and-Deliver vs. Out-of-Band

Out-of-Band (Quarantine): file delivered to the user immediately while the sandbox detonates. If the verdict comes back malicious, the user is notified and an SOC alert fires — but they may already have opened it. Faster UX, weaker security posture. Default for low-risk types.
Hold-and-Deliver: the download blocks at the PSE until the verdict is in. Slower UX (5–120s wait depending on file size and sandbox queue depth), but zero risk of pre-verdict execution. Recommended for executables, installers, and macro-enabled docs from any source not on the trusted bypass list.

Verdicts and AI/ML scoring

The sandbox returns one of three verdicts: Benign (clean, deliver), Suspicious (borderline — default Block + analyst review), or Malicious (clear malware behaviour — always Block + alert) — plus a "Sandbox Was Unable to Analyse" state for files the engine could not detonate (corrupt, encrypted, unsupported). There is no formal "Other" verdict. Alongside dynamic detonation, modern Cloud Sandbox also runs static AI/ML scoring on the binary before the VM runs. The ML model is trained on millions of known-bad and known-good samples; for very high-confidence hits, ZIA blocks instantly without waiting for the full detonation, cutting Hold-and-Deliver latency to under a second for the obvious cases.

SVG #2 — Sandbox flow: from user download to verdict to deliver/block

Hold-and-Deliver is the security default for executables. Static ML scoring shortens the wait for the obvious cases; full dynamic detonation handles the rest. Every verdict is logged with the per-file report (network calls, registry writes, dropped files).

Sandbox rule configuration

ZIA · Sandbox policy — Hold-and-Deliver for executables

Policy → Sandbox → Sandbox Policy → + Add Rule

  Order:               10
  Name:                Sandbox-Executables-HoldAndDeliver
  Action:              Quarantine (Hold-and-Deliver)
  File Types:          Windows Executable (PE), Installer (.msi),
                       Mach-O (.dmg / Mach-O), Linux ELF,
                       Office docs w/ macros (.docm/.xlsm/.pptm),
                       Scripts (.js, .vbs, .ps1)
  URL Categories:      All EXCEPT Whitelisted-Internal
  User / Group:        All
  First-time Action:   Block on Suspicious + Malicious verdicts
                       Allow on Benign
  Use AI Instant Verdict for high-confidence files:  ON
                       (no threshold input — Zscaler manages ML confidence internally)
  Notification page:   ON  ("Scanning download — please wait…")

Sandbox-eligible file types (memorise)

Sandbox focuses on file classes that historically carry payload. Plain PDFs go through Malware AV only; PDFs with embedded JS get sandboxed. The list:

Executables & installers: PE, Mach-O, ELF, .msi, .pkg, .deb, .rpm
Office macro docs: .docm, .xlsm, .pptm (NOT plain .docx unless it contains active content)
PDFs with active content (embedded JS, form submission actions); scripts: .js, .vbs, .ps1, .bat, .sh
Archives: .zip, .rar, .7z, .tar, .gz — recursive detonation up to depth 5 by default
Mobile installers: .apk, .ipa. Coverage gaps: .iso, .dmg, .img — recent additions on Sandbox Advanced+; verify in your tenant before relying on them.

📦Sandbox SKU tiers

Sandbox SKU tiers: Sandbox Standard (PDF/Office/EXE/archives, limited eval time); Sandbox Advanced (+ scripts, macros, Linux ELF, Mach-O); Sandbox Advanced+ (extended detonation, multi-environment). ZDTA exam tests this — know which SKU your tenant has before configuring policy.

Browser Control — the user-agent gate

The fourth engine doesn't look at the file or the destination. It looks at the user's client. Outdated browsers are exploit-kit magnets; legacy Java applets and Flash plugins are how 2010-era attacks still work in 2026. Browser Control reads the User-Agent string via regex (User-Agent spoofing trivially defeats it — that's why you layer ATP behind it). No deep fingerprinting.

What you can enforce

Browser version floor — block IE6–11, block Chrome older than N, block Firefox older than ESR-N. Keeps the rendering surface modern.
Plugins — block the Java browser plugin, Adobe Flash, Silverlight, ActiveX (all EOL, all exploit magnets).
Adobe Reader version — block in-browser opens from old Reader; Office macro behaviour — companion control that pairs with Sandbox for .docm decisions.

Configuration path

ZIA · Browser Control settings

Policy → Browser Control → Browser Control Policy

  Browsers:
    Internet Explorer 6, 7, 8, 9, 10, 11   →  Block + custom notify
    Chrome < 110                            →  Warn (give user upgrade prompt)
    Firefox < 102 ESR                       →  Warn
    Edge Legacy (pre-Chromium)              →  Block
    Safari < 15                             →  Warn

  Plugins:
    Java Plugin (all versions)              →  Block
    Adobe Flash (all)                       →  Block
    Silverlight (all)                       →  Block
    ActiveX                                 →  Block

  Documents:
    Adobe Reader < 2020 (in-browser)        →  Block
    Office macro auto-execute               →  Block (route through Sandbox)

  Notify page:                              Branded + IT-helpdesk link

⚠Common Mistakes — production gotchas across all four engines

Skipping Sandbox because of latency fear. Reserve Hold-and-Deliver for executables (downloaded once a week, not constantly) and set expectations with the branded notification page. Disable it and you'll be the on-call who explains how the zero-day got in.
ATP false positive on internal Jenkins / Artifactory blocked. Self-hosted dev infra lands in Suspicious Destinations because the domain reputation is unknown. Don't disable ATP — add the internal hostname to the ATP Bypass rule (per-URL, not per-category).
Sandbox file-type coverage misunderstood. Engineers assume .iso and .docm are auto-detonated; depending on licence tier and tenant settings they may not be. Cross-check Policy → Sandbox → Configuration → File Type Coverage before promising it works.
"Malware and ATP look like duplicates — turn one off." They aren't. Malware is signature/heuristic on file bytes; ATP is reputation/IOC on destinations and behaviour. Disjoint sets — disabling either creates a hole.
Browser Control still enforcing IE11 block after Win11 rollout. IE11 is retired but stale policies block embedded IE-mode in Edge (legitimate for legacy intranet apps). Audit Browser Control quarterly against actual fleet UA telemetry.
Skipping Suspicious Content Protection on archives. Password-protected ZIPs are how attackers ship malware past AV (AV can't see inside). Enable "Detect & block password-protected archives" and route to Sandbox; never blanket-allow.
Not wiring NSS to SIEM for Sandbox verdicts. A Malicious verdict in Insights doesn't auto-create a ticket. Wire NSS Web Logs with the right columns enabled — threatcategory, threatname, threatclass, mwcat, sandbox_verdict — into SIEM so every Malicious verdict opens an SOC case the same minute.

💡Pro Tips — small moves with big payoff

Always Hold-and-Deliver executables from new destinations. Trusted internal mirrors get bypass; everything else gets quarantine. The single highest-value Sandbox choice you'll make.
Tie ATP IOC lookup latency into your SLA monitoring. Synthetic monitor hits a known-bad test URL from a probe and alerts if the block-page time exceeds baseline by 2× — early indicator of cloud-side incident.
Treat Sandbox reports as detection telemetry, not noise. Every Suspicious/Malicious verdict ships a full behavioural report (registry writes, dropped files, network calls, MITRE ATT&CK mapping). Feed them into threat-hunt — half the value of Sandbox isn't blocking the file, it's the IOCs you extract from the verdict.

✓Verify — confirm each engine is firing correctly

After enabling/changing any threat-protection rule, run this loop end-to-end before declaring victory:

Malware: download https://secure.eicar.org/download/eicar.com from a test endpoint. Should block with reason "Malware: EICAR-Test-File". Insights → Web → filter Action=Blocked, Threat Category=Virus.
ATP: hit a known test phishing URL (Zscaler publishes the list). Should block with reason "ATP: Phishing". Confirm in Insights → Web → Threat Name column.
Sandbox: Zscaler hosts a sandbox test page with a benign executable. Download with Hold-and-Deliver on — request should hold 5–10s, then deliver with verdict "Benign". Insights → Sandbox tab for the per-file report.
Browser Control: hit any HTTPS site with a spoofed UA (curl -A "MSIE 10.0"). Should block with reason "Browser Control: Browser version not allowed".
NSS log: tail NSS / SIEM for the last 5 minutes and confirm every test hit produced one log line with the right threat_type and policy_action.

Threat Protection Troubleshooting Lab Sandbox Verdict Walkthrough Branch Connector Telemetry

Real-world scenario — Friday afternoon: the engineering build pipeline stops cold

16:40 Friday. Engineering Slack is on fire. CI can't pull from artifactory-internal.company.com — Maven/Gradle time out mid-download on every .jar and on the build-tools-2.4.0.exe toolchain installer. Release-candidate ship is at 18:00.

Reproduce. SSH to a CI runner. curl -O https://artifactory-internal.company.com/builds/build-tools-2.4.0.exe hangs at ~3% then 504s with a Zscaler "Scanning download — please wait…" interstitial. ZIA is stalling it.
Locate in Insights. Analytics → Insights → Web. Filter: URL contains "artifactory-internal", last 30 min. Every request shows Action = "Quarantine", Policy = "Sandbox-Executables-HoldAndDeliver"; sandbox queue depth elevated, verdicts 90+ seconds.
Hypothesis. The binary is large (~250 MB) and Sandbox is hold-and-delivering under the Executables rule; the tenant's Sub-Cloud sandbox queue is deep right now. Every runner queues behind every other runner.
Wrong fix. "Disable Sandbox for executables tenant-wide." Works for 30 minutes; costs you the next zero-day. Don't.
Right fix. Add a Sandbox Bypass rule scoped to the trusted internal Artifactory URL. The build pipeline already signs artifacts cryptographically and CI/CD enforces hash checks — no security value in Sandbox-detonating files you produced yourself.

Policy → Sandbox → + Add Rule (above catch-all): Order: 5 · Name: Bypass-Internal-Artifactory Action: Allow (No Inspection) URL Custom: artifactory-internal.company.com/* User/Group: CI-Service-Accounts, Engineering
Activate. Wait 60s for distribution. Re-run curl — streams at line rate; Insights shows Policy = "Bypass-Internal-Artifactory", Action = "Allow".
Notify & document. Slack-back engineering. File a separate support ticket on the regional sandbox queue depth. Update the runbook "Internal trusted artifact sources" with the URL list.

Ticket-to-green-build: 18 minutes. You didn't disable Sandbox for executables company-wide — you carved out one trusted source. The other 99% still get Hold-and-Deliver. Zero-day posture intact; 18:00 release ships.

Sandbox Bypass Rule Lab Insights Filter Drills

📌 Quick reference (memorise — Threat Protection arc)

Four engines: Browser Control → ATP → Malware AV → Cloud Sandbox. Each catches a different class; overlap is intentional.
Malware AV = signature + heuristic + ML on file bytes; multi-engine; updates continuously from ThreatLabz.
ATP = destination reputation + IOC feeds + behavioural categories (Phishing, Cryptomining, C2, Suspicious Destinations, Anonymizer, Browser Exploits).
URL Filtering ≠ ATP. URL = slow categories. ATP = fast IOCs. Both run; stricter wins.
Cloud Sandbox = detonate unknowns in a VM, observe behaviour, return verdict (Benign / Suspicious / Malicious) plus a "Sandbox Was Unable to Analyse" state in 5–120s. AI/ML static scoring runs in parallel and instant-blocks obvious cases.
Hold-and-Deliver = security default for executables & macros. Out-of-Band only for low-risk types or trusted sources.
Sandbox-eligible: PE/Mach-O/ELF, .msi/.pkg, .docm/.xlsm/.pptm, PDF-with-JS, scripts, archives (recursive), .apk/.ipa. .iso/.dmg depend on licence — verify.
Browser Control blocks vulnerable client surfaces: old IE/Chrome, Java plugin, Flash, Silverlight, ActiveX, old Adobe Reader. Audit quarterly against fleet UA telemetry.
EICAR + Zscaler sandbox test files are your standard verify-it-fired sources. Confirm in Insights + NSS.
Never disable an engine to fix a false positive. Add a scoped Bypass for the specific URL/user/group.
Wire NSS Web Logs into SIEM with threatcategory, threatname, threatclass, mwcat, sandbox_verdict columns — every Malicious verdict opens an SOC case automatically.

▶ QUICK LAB · ~15 MIN

Trigger and trace a sandbox detonation:

Generate a benign sample with a fake "macro" — upload to a test SaaS or HTTP endpoint.
From a Z-App-protected endpoint, download the sample. Check ZIA Web Insights for the request.
Search ZIA → Insights → Sandbox Report for the file hash. Note: verdict, ML score, detonation engines used.
If verdict = Sandbox Was Unable to Analyse, check why (size limit, unsupported type, archive password).

What's next?

Module 8 takes you from blocking what's bad to controlling what's sensitive — DLP and CASB for protecting data leaving the org.

Lesson 8 — DLP & CASB → Practice on exam.techclick.in

Threat Protection — Malware, ATP, Sandbox & Browser Control

Why this lesson matters

The four layers of ZIA threat defense

Malware Protection — the first signature gate

What it inspects

Configuration path

Advanced Threat Protection (ATP) — the destination & behaviour layer

ATP categories you'll configure

How ATP differs from URL Filtering

Cloud Sandbox — the zero-day catcher

Hold-and-Deliver vs. Out-of-Band

Verdicts and AI/ML scoring

Sandbox rule configuration

Sandbox-eligible file types (memorise)

Browser Control — the user-agent gate

What you can enforce

Configuration path

Real-world scenario — Friday afternoon: the engineering build pipeline stops cold

📌 Quick reference (memorise — Threat Protection arc)

📝 Check your understanding

What's next?