Netskope Threat Protection — Malware, Sandbox, CFW, RBI & GenAI

① Anti-malware + the Cloud Sandbox — stopping the unknown

Threat Protection is Netskope’s defense layer: it inspects files and traffic for badness on the same single-pass engine that does web, SaaS and private-app control. The first job is malware. A classic signature scan backed by threat intelligence catches what is already known. But the attacks that hurt are the ones nobody has seen yet.

You don’t build malware controls inline. You build a reusable Malware Detection Profile first, then apply it inside a policy. The path is Policies → Threat Protection → Malware Detection Profiles tab → New Malware Detection Profile. The wizard goes Threat Scan (“The Netskope malware scan” is selected by default and can’t be changed) → Allowlist (a file profile of known-good hashes) → Blocklist → Set Profile (name it) → Save Malware Detection Profile → Apply Changes.

For the unknown file, you need the Cloud Sandbox (also called dynamic threat analysis). It runs the file in an isolated VM, watches its behaviour across 30+ file types (PE, Office, PDF, archives, scripts), and returns a report mapped to MITRE ATT&CK. The killer feature is hold-for-verdict (the “Patient Zero” protection).

② Cloud Firewall (FWaaS) + IPS — beyond the web

A web proxy only sees ports 80/443. But threats and data move on other ports too — SSH, SMTP, custom TCP/UDP, DNS. That’s what Cloud Firewall (FWaaS) is for: cloud-delivered L3/L4 control for the non-web traffic SWG ignores. You write rules at Policies → Real-time Protection → New Policy → Firewall.

A firewall rule’s destination can be a cloud app, a DPI app, or a Custom Firewall Application (IP/CIDR/FQDN/wildcard + port/protocol). The default Non-Web Policy is block-all, editable via the pencil icon. One gotcha that bites everyone: set the Destination before the Source — doing it in the wrong order can drop your data in the form.

IPS rides on top, at Settings → Threat Protection → IPS Settings. You set IPS Status to Alert or Block, pick the traffic scope (Non-Web needs CFW; Cloud Apps & Web; Private App Segments need NPA), and maintain three allowlists — Source IP, Domain (FQDN/wildcard), Destination IP. The golden rule: never go straight to Block.

③ RBI for risky sites + UEBA for risky users

Sometimes you can’t cleanly block or allow. A user genuinely needs to open an uncategorized or Security Risk site. Blocking stops the work; allowing risks malware. The answer is Remote Browser Isolation (RBI): the site runs in a cloud container and the user gets only a pixel stream. No active code (scripts, exploits, drive-by malware) ever reaches the laptop.

You enable it by setting a Real-time Protection policy action to Isolate at Policies → Real-time Protection → New Policy. Targeted RBI auto-isolates the Uncategorized and Security Risk categories. One current requirement bites people: every Isolate policy now needs the Source = Browser access-method criterion (the Netskope Client can’t isolate, only browsers can) — leave it off and matching requests are silently “not isolable” and passed through. Inside the isolated session you can block file upload/download and limit copy/paste/print — so even if a page is hostile, it can neither infect the endpoint nor exfiltrate data.

RBI defends against the site. UEBA (Behaviour Analytics) defends against the user turning bad. It has three categories — Insider Threat, Compromised Device, Compromised Credentials — built on rule-based policies at Policies → Insider Threats & Advanced Compromise → Rule-Based. The Compromised-Credentials DB is refreshed daily (≈2-day detection of leaked creds). The UCI (User Confidence Index) is the score that drives adaptive action.

Four threat-defense ideas worth memorising

Tap each card — these come up in interviews and on the job.

④ GenAI governance with AI Guardrails — and your path forward

The newest threat surface isn’t a file — it’s the prompt. People paste source code, client PII and secrets into ChatGPT, Copilot and Gemini every day (about 72% use personal GenAI accounts, not the sanctioned one). Netskope’s answer, GA since March 2026, is AI Guardrails.

AI Guardrails inspects every prompt and response (in 29 languages), applies your existing DLP profiles to what users type, and stops prompt injection and jailbreaking. It plugs into the same DLP + Threat Protection you’ve already built. The key shift: in Netskope, typing a prompt into a chat box steers as the Post activity — so you must inspect Post (and Download for the reply), not just Upload. The most common GenAI-DLP miss is a policy that only watches uploads, so pasted PII in a prompt sails straight through.

GET /api/v2/events/dataexport/alerts/malware?timeperiod=86400 \
  -H "Netskope-Api-Token: $NS_TOKEN"

# (or in the UI: Skope IT → Alerts → Malware → click the file → Sandbox report)

severity      : high
file_name     : invoice.xlsm
file_type     : MS Office (macro)
sandbox_status: malicious
threat_match  : Dynamic.Analysis (MITRE T1059.005)
action        : blocked
user          : sneha@wipro.com  (UCI: 412 — low)