Reads (and creates if missing) a Cortex XSOAR List by a runtime-computed name, for tracking Netskope file hash list content between playbook runs (Netskope's v1 hash-list API has no read-back endpoint).

Builds the setIncident addLabels JSON string from a netskopev2-get-scan-report result (jobid, status, verdict, md5, sha256) - kept separate from the large nested fields (dropped/network/observed_behavior/process_tree) already excluded from the command's own readable output.

Fetches all private apps and matches one by name to resolve its application ID. This is necessary because netskopev2-list-private-apps has no name filter argument and Netskope wraps app_name in brackets in list responses.

Writes to a Cortex XSOAR List via setList, retrying a few times on a transient Elasticsearch version-conflict (409) error, for tracking Netskope file hash list content between playbook runs.

Builds the setIncident addLabels JSON string from a netskopev2-url-lookup result (category names and matched URL list names joined into single label values), since combining several transformed context values into one JSON string argument isn't reliably expressible in plain playbook YAML templating.

Pulls bounded Domain, URL, IP, and CIDR indicators from Cortex XSOAR's Threat Intel Management and formats CIDR values with the "CIDR:" prefix that Netskope's destination profile Definition field expects. It skips values already present in the target profile. When profile_id is given, it appends the new values in batches of at most chunk_size and deploys only when deploy is explicitly enabled. Without profile_id, it only prepares the new-value list for a separate create-profile step.

Builds the JSON array netskopev2-create-private-app/netskopev2-update-private-app expect for their "protocols" argument (e.g. [{"type": "tcp", "port": "443"}]) from a plain comma-separated port list, so callers do not need to hand-write JSON (and cannot accidentally pass a bare number like "443", which parses as valid JSON but is not the array shape the API needs).

Fetches all publishers and resolves each requested name to its publisher_id, building the JSON array that netskopev2-create-private-app and netskopev2-update-private-app expect for their publishers argument. This is necessary because netskopev2-list-publishers has no name filter argument.

Searches Cortex XSOAR's own Threat Intel Management for the generic "File" type plus the hash-specific "File MD5"/"File SHA-256" types (some tenants disable the hash-specific types as selectable options, in which case new hash indicators land under generic "File" instead - searching both covers either case), extracts valid MD5 (32 hex chars) / SHA256 (64 hex chars) hashes from either the indicator's value or its md5/sha256 CustomFields, and - since Netskope's v1 file hash list API has no read-back endpoint and every update replaces the full list - returns both the newly found hashes and the full merged set (existing_hashes plus new) ready to send as a full replace.

Fetches a private app's current host, protocols, and tags, then applies the requested additions or removals without discarding the other values. This is necessary because netskopev2-update-private-app (PATCH) replaces host, protocols, and tags wholesale rather than merging them.

Manages Netskope policy enforcement workflows for URLs, domains, file hashes, destination and network profiles, device classification, private applications, file inspection, and URL reputation.

Adds hashes to a Netskope file hash list via netskopev2-update-file-hash-list.

IMPORTANT: Netskope's file hash list API (v1) has no endpoint to read the current list content -
every update REPLACES the full list, it cannot append. Since Netskope itself can't tell us
what's already there, this playbook tracks the running hash set on the Cortex XSOAR side instead, in
a Cortex XSOAR List named "NetskopeHashList_<ListName>" (auto-created on first run): it reads that
List's current content (via the NetskopeGetXsoarListContent script), merges it with NewHashes,
sends the full merged set to Netskope, then writes the result back (via
NetskopeSetXsoarListContentWithRetry, which retries a few times if Cortex XSOAR's storage backend
reports a transient version conflict from a concurrent write) to the same Cortex XSOAR List so the
next run picks up where this one left off. No manual "what's already in the list" input needed.

Only MD5 (32 hex chars) and SHA256 (64 hex chars) hashes are accepted - the command itself
validates this and rejects anything else. A "duplicate request, no change" response from
Netskope is treated as success, not an error, since the desired state (these hashes being
present) is already true in that case.

The ListName input must reference a Netskope list that already exists (the tracking List on the
Cortex XSOAR side is separate and gets created automatically). If the tracking List is empty,
the playbook stops unless AllowEmptyMirrorOverwrite is explicitly enabled.

Blocks a domain by adding it to an existing Netskope URL List.

Checks whether the Domain and ListName inputs were provided, verifies that a Netskope
integration instance is enabled, and adds the domain to the existing Netskope URL List.

This pack has no "create list" command - the ListName input must reference a list that already
exists.

Blocks a domain via a Netskope Destination Profile: looks up the profile by name and either
appends the domain to that existing profile or, if no profile with that name exists yet,
prompts the analyst to pick a match type and creates a new one with the domain as its first
value.

The match type prompt is a single-select with exactly three choices - sensitive (Exact - Case
Sensitive), insensitive (Exact - Case Insensitive), or regex (RegEx), mirroring the "Match Type"
choice in the Netskope UI's destination profile editor - so there's no risk of a typo or wrong
casing (e.g. "Regex" instead of "regex") getting rejected by the create command. It's only asked
when a new profile actually needs to be created - it's skipped entirely when appending to a
profile that already exists (its match type was already fixed at creation).

The integration performs the profile-name lookup safely by retrieving profile pages and
comparing names locally, without interpolating ProfileName into an API filter. No manual ID
lookup is needed; provide only the profile's display name.

IMPORTANT: unlike the URL List and File Hash List "append" behavior, Netskope's destination
profile values "append" operation has no server-side dedup - calling it twice with the same
domain (e.g. re-running this playbook for a domain that's already blocked) adds it twice. This
playbook checks the profile's current values (fetched by the name lookup) first and only
appends when the domain isn't already present, so re-running it for an already-blocked domain
is a safe no-op. Also make sure only one Netskope integration instance is enabled at a time - if
two are enabled, Cortex XSOAR dispatches the command to both, causing the same double-add.

Destination Profile changes are staged. Set Deploy to true to apply the pending change; it
defaults to false. ChangeNote is recorded only when a deployment is requested.

Looks up a URL's categorization/reputation info via netskopev2-url-lookup and records the
result as labels directly on the incident.

netskopev2-url-lookup is a bulk API (up to 100 URLs per call), but this playbook only ever
queries one URL at a time, matching the single URL input. Building the addLabels JSON string
from the lookup result requires joining nested category/URL-list names into flat values, which
isn't reliably expressible in plain playbook YAML templating (see NetskopeURLLookupLabels for
why) - that script does the real work; this playbook just wires it together.

netskopev2-url-lookup is a licensed feature on the Netskope side - if you get an error mentioning
licensing/enablement, URL Lookup needs to be enabled for your tenant by Netskope support.

Synchronizes bounded Cortex XSOAR Threat Intel indicators to a Netskope Destination Profile.
The profile name is required. Match type and indicator types have editable playbook defaults,
and each input is validated independently before any Netskope command runs.

Existing profiles are updated in batches of at most 10 values. New profiles are created as
pending changes. Set Deploy to true to apply pending changes; it defaults to false so scheduled
jobs cannot enforce changes without explicit authorization. The default indicator query selects
active indicators with a Bad reputation and can be further restricted with tags.

Submits a file for Netskope's sandbox scan (netskopev2-submit-file-scan /
netskopev2-get-scan-report) and polls for the result, since the scan is asynchronous and can
take a while to complete.

Only certain file types are accepted for inspection - this is enforced by
netskopev2-submit-file-scan itself (not just this playbook), per the API spec: the file must be
a password-protected .zip whose one member file is .exe, .pdf, .doc, .xls, .ppt, or .rtf. A
plain .zip (the container format) is also accepted directly. Anything else is rejected with a
clear error before an API call is even made.

Checks whether the EntryID input was provided, checks whether a Netskope integration instance is
enabled (matching any brand name containing "Netskope"), submits the file for scanning, then
uses the standard GenericPolling sub-playbook to repeatedly call netskopev2-get-scan-report
(every Interval minutes, up to Timeout minutes) until the scan's status stops being
"InProgress". The final poll's result is what's left in the Netskope.FileScanReport context
when this playbook finishes - no separate "final fetch" step is needed.

Synchronizes bounded Cortex XSOAR File indicators to an existing Netskope file hash list.
Netskope's v1 API replaces the full list and does not provide a read endpoint, so the playbook
preserves the running set in a Cortex XSOAR List named NetskopeHashList_<ListName>.

ListName is required and has no tenant-specific fallback. The default indicator query selects
active indicators with a Bad reputation. If the mirror list is empty, the playbook stops unless
AllowEmptyMirrorOverwrite is explicitly enabled, preventing accidental replacement of an
existing Netskope list with incomplete state.

Creates, modifies, or deletes a Netskope private application (ZTNA/NPA) "segment" (Netskope's
own API models this as one Private App object: a host + its protocol/port entries + publishers,
per /api/v2/steering/apps/private/{private_app_id} - there is no separate "segment" sub-resource
in the API, so this playbook manages the whole private app object).

Checks whether the Action input was provided, checks whether a Netskope integration instance is
enabled (matching any brand name containing "Netskope"), then branches on Action:

• "create": creates a new private app using AppName, Host, Ports/ProtocolType, PublisherNames,
  and Tags.
• "modify": updates an existing private app (identified by AppID, or by AppName - see below) -
  only the fields you provide among AppName/Host/Ports/PublisherNames/Tags are changed, the
  rest are left as-is. HostsToAdd/PortsToAdd/TagsToAdd append to the current host/protocols/tags
  instead of replacing them; HostsToRemove/PortsToRemove/TagsToRemove remove specific values from
  the current host/protocols/tags instead of requiring you to retype everything else. The
  playbook fetches the app's current state and applies these merges before the PATCH is sent.
• "delete": permanently deletes the private app identified by AppID or AppName.

The playbook uses the modify operation for partial updates and supports adding or removing
individual field values without replacing the whole object.

For modify/delete, you can provide AppID directly, or leave it blank and provide AppName
instead - netskopev2-list-private-apps has no name filter argument, so the playbook fetches every
private app and resolves AppName to an ID itself (also handling the "[app_name]"
bracket-wrapping Netskope applies in list responses). If no app or more than one app matches
that name, the playbook stops with a clear error rather than guessing.

Similarly, PublisherNames takes plain publisher names (e.g. "AWS-NPA") instead of requiring you
to already know each publisher_id - netskopev2-list-publishers also has no name filter, so the
playbook resolves each name and builds the {"publisher_id": …, "publisher_name": …} JSON
array the create/update commands expect.

Ports takes a comma-separated list of port numbers. The playbook builds the object array expected
by the create and update commands, which validate that protocols is an array of objects.
Host already accepts multiple comma-separated values directly (e.g. "10.0.0.1,10.0.0.2") - no
lookup or building needed for that one.

Blocks an IP address, IP range, or CIDR netmask via a Netskope Network Profile (shown as
"Network Location" in the Netskope UI) - the same "check input / check integration enabled /
act" pattern as Block Domain - Destination Profile - Netskope, adapted for Network Profiles
instead of Destination Profiles.

Looks up the network profile by name and either appends the value to that existing profile or,
if no profile with that name exists yet, creates a new one with the value as its first entry.

Unlike Destination Profiles, Network Profiles have no match type at all (netskopev2-create-
network-profile takes no "type" argument) - so unlike the destination profile playbook, there's
no "choose a match type" prompt here; creating a new profile needs nothing beyond the name and
the value itself.

Profile names are unique in Netskope, so the playbook performs an exact-name lookup without
constructing a filter expression.

IMPORTANT: like Destination Profiles, Network Profile values "append" has no server-side dedup -
calling it twice with the same value (e.g. re-running this playbook for a value that's already
present) adds it twice. This playbook checks the profile's current values first and only
appends when the value isn't already present, so re-running it for an already-blocked value is
a safe no-op. Also make sure only one Netskope integration instance is enabled at a time - if
two are enabled, Cortex XSOAR dispatches the command to both, causing the same double-add.

Network Profile changes are staged. Set Deploy to true to apply the pending change; it defaults
to false. ChangeNote is recorded only when a deployment is requested.

Reads (and creates if missing) a Cortex List by a runtime-computed name, for tracking Netskope file hash list content between playbook runs (Netskope's v1 hash-list API has no read-back endpoint).

Pulls bounded Domain, URL, IP, and CIDR indicators from Cortex's Threat Intel Management and formats CIDR values with the "CIDR:" prefix that Netskope's destination profile Definition field expects. It skips values already present in the target profile. When profile_id is given, it appends the new values in batches of at most chunk_size and deploys only when deploy is explicitly enabled. Without profile_id, it only prepares the new-value list for a separate create-profile step.

Builds the setIncident addLabels JSON string from a netskopev2-get-scan-report result (jobid, status, verdict, md5, sha256) - kept separate from the large nested fields (dropped/network/observed_behavior/process_tree) already excluded from the command's own readable output.

Fetches all private apps and matches one by name to resolve its application ID. This is necessary because netskopev2-list-private-apps has no name filter argument and Netskope wraps app_name in brackets in list responses.

Fetches a private app's current host, protocols, and tags, then applies the requested additions or removals without discarding the other values. This is necessary because netskopev2-update-private-app (PATCH) replaces host, protocols, and tags wholesale rather than merging them.

Builds the setIncident addLabels JSON string from a netskopev2-url-lookup result (category names and matched URL list names joined into single label values), since combining several transformed context values into one JSON string argument isn't reliably expressible in plain playbook YAML templating.

Searches Cortex's own Threat Intel Management for the generic "File" type plus the hash-specific "File MD5"/"File SHA-256" types (some tenants disable the hash-specific types as selectable options, in which case new hash indicators land under generic "File" instead - searching both covers either case), extracts valid MD5 (32 hex chars) / SHA256 (64 hex chars) hashes from either the indicator's value or its md5/sha256 CustomFields, and - since Netskope's v1 file hash list API has no read-back endpoint and every update replaces the full list - returns both the newly found hashes and the full merged set (existing_hashes plus new) ready to send as a full replace.

Fetches all publishers and resolves each requested name to its publisher_id, building the JSON array that netskopev2-create-private-app and netskopev2-update-private-app expect for their publishers argument. This is necessary because netskopev2-list-publishers has no name filter argument.

Builds the JSON array netskopev2-create-private-app/netskopev2-update-private-app expect for their "protocols" argument (e.g. [{"type": "tcp", "port": "443"}]) from a plain comma-separated port list, so callers do not need to hand-write JSON (and cannot accidentally pass a bare number like "443", which parses as valid JSON but is not the array shape the API needs).

Writes to a Cortex List via setList, retrying a few times on a transient Elasticsearch version-conflict (409) error, for tracking Netskope file hash list content between playbook runs.

Manages Netskope policy enforcement workflows for URLs, domains, file hashes, destination and network profiles, device classification, private applications, file inspection, and URL reputation.

Looks up a URL's categorization/reputation info via netskopev2-url-lookup and records the
result as labels directly on the alert.

netskopev2-url-lookup is a bulk API (up to 100 URLs per call), but this playbook only ever
queries one URL at a time, matching the single URL input. Building the addLabels JSON string
from the lookup result requires joining nested category/URL-list names into flat values, which
isn't reliably expressible in plain playbook YAML templating (see NetskopeURLLookupLabels for
why) - that script does the real work; this playbook just wires it together.

netskopev2-url-lookup is a licensed feature on the Netskope side - if you get an error mentioning
licensing/enablement, URL Lookup needs to be enabled for your tenant by Netskope support.

Blocks a domain via a Netskope Destination Profile: looks up the profile by name and either
appends the domain to that existing profile or, if no profile with that name exists yet,
prompts the analyst to pick a match type and creates a new one with the domain as its first
value.

The match type prompt is a single-select with exactly three choices - sensitive (Exact - Case
Sensitive), insensitive (Exact - Case Insensitive), or regex (RegEx), mirroring the "Match Type"
choice in the Netskope UI's destination profile editor - so there's no risk of a typo or wrong
casing (e.g. "Regex" instead of "regex") getting rejected by the create command. It's only asked
when a new profile actually needs to be created - it's skipped entirely when appending to a
profile that already exists (its match type was already fixed at creation).

The integration performs the profile-name lookup safely by retrieving profile pages and
comparing names locally, without interpolating ProfileName into an API filter. No manual ID
lookup is needed; provide only the profile's display name.

IMPORTANT: unlike the URL List and File Hash List "append" behavior, Netskope's destination
profile values "append" operation has no server-side dedup - calling it twice with the same
domain (e.g. re-running this playbook for a domain that's already blocked) adds it twice. This
playbook checks the profile's current values (fetched by the name lookup) first and only
appends when the domain isn't already present, so re-running it for an already-blocked domain
is a safe no-op. Also make sure only one Netskope integration instance is enabled at a time - if
two are enabled, Cortex dispatches the command to both, causing the same double-add.

Destination Profile changes are staged. Set Deploy to true to apply the pending change; it
defaults to false. ChangeNote is recorded only when a deployment is requested.

Synchronizes bounded Cortex File indicators to an existing Netskope file hash list.
Netskope's v1 API replaces the full list and does not provide a read endpoint, so the playbook
preserves the running set in a Cortex List named NetskopeHashList_<ListName>.

ListName is required and has no tenant-specific fallback. The default indicator query selects
active indicators with a Bad reputation. If the mirror list is empty, the playbook stops unless
AllowEmptyMirrorOverwrite is explicitly enabled, preventing accidental replacement of an
existing Netskope list with incomplete state.

Submits a file for Netskope's sandbox scan (netskopev2-submit-file-scan /
netskopev2-get-scan-report) and polls for the result, since the scan is asynchronous and can
take a while to complete.

Only certain file types are accepted for inspection - this is enforced by
netskopev2-submit-file-scan itself (not just this playbook), per the API spec: the file must be
a password-protected .zip whose one member file is .exe, .pdf, .doc, .xls, .ppt, or .rtf. A
plain .zip (the container format) is also accepted directly. Anything else is rejected with a
clear error before an API call is even made.

Checks whether the EntryID input was provided, checks whether a Netskope integration instance is
enabled (matching any brand name containing "Netskope"), submits the file for scanning, then
uses the standard GenericPolling sub-playbook to repeatedly call netskopev2-get-scan-report
(every Interval minutes, up to Timeout minutes) until the scan's status stops being
"InProgress". The final poll's result is what's left in the Netskope.FileScanReport context
when this playbook finishes - no separate "final fetch" step is needed.

Blocks a domain by adding it to an existing Netskope URL List.

Checks whether the Domain and ListName inputs were provided, verifies that a Netskope
integration instance is enabled, and adds the domain to the existing Netskope URL List.

This pack has no "create list" command - the ListName input must reference a list that already
exists.

Creates, modifies, or deletes a Netskope private application (ZTNA/NPA) "segment" (Netskope's
own API models this as one Private App object: a host + its protocol/port entries + publishers,
per /api/v2/steering/apps/private/{private_app_id} - there is no separate "segment" sub-resource
in the API, so this playbook manages the whole private app object).

Checks whether the Action input was provided, checks whether a Netskope integration instance is
enabled (matching any brand name containing "Netskope"), then branches on Action:

• "create": creates a new private app using AppName, Host, Ports/ProtocolType, PublisherNames,
  and Tags.
• "modify": updates an existing private app (identified by AppID, or by AppName - see below) -
  only the fields you provide among AppName/Host/Ports/PublisherNames/Tags are changed, the
  rest are left as-is. HostsToAdd/PortsToAdd/TagsToAdd append to the current host/protocols/tags
  instead of replacing them; HostsToRemove/PortsToRemove/TagsToRemove remove specific values from
  the current host/protocols/tags instead of requiring you to retype everything else. The
  playbook fetches the app's current state and applies these merges before the PATCH is sent.
• "delete": permanently deletes the private app identified by AppID or AppName.

The playbook uses the modify operation for partial updates and supports adding or removing
individual field values without replacing the whole object.

For modify/delete, you can provide AppID directly, or leave it blank and provide AppName
instead - netskopev2-list-private-apps has no name filter argument, so the playbook fetches every
private app and resolves AppName to an ID itself (also handling the "[app_name]"
bracket-wrapping Netskope applies in list responses). If no app or more than one app matches
that name, the playbook stops with a clear error rather than guessing.

Similarly, PublisherNames takes plain publisher names (e.g. "AWS-NPA") instead of requiring you
to already know each publisher_id - netskopev2-list-publishers also has no name filter, so the
playbook resolves each name and builds the {"publisher_id": …, "publisher_name": …} JSON
array the create/update commands expect.

Ports takes a comma-separated list of port numbers. The playbook builds the object array expected
by the create and update commands, which validate that protocols is an array of objects.
Host already accepts multiple comma-separated values directly (e.g. "10.0.0.1,10.0.0.2") - no
lookup or building needed for that one.

Blocks an IP address, IP range, or CIDR netmask via a Netskope Network Profile (shown as
"Network Location" in the Netskope UI) - the same "check input / check integration enabled /
act" pattern as Block Domain - Destination Profile - Netskope, adapted for Network Profiles
instead of Destination Profiles.

Looks up the network profile by name and either appends the value to that existing profile or,
if no profile with that name exists yet, creates a new one with the value as its first entry.

Unlike Destination Profiles, Network Profiles have no match type at all (netskopev2-create-
network-profile takes no "type" argument) - so unlike the destination profile playbook, there's
no "choose a match type" prompt here; creating a new profile needs nothing beyond the name and
the value itself.

Profile names are unique in Netskope, so the playbook performs an exact-name lookup without
constructing a filter expression.

IMPORTANT: like Destination Profiles, Network Profile values "append" has no server-side dedup -
calling it twice with the same value (e.g. re-running this playbook for a value that's already
present) adds it twice. This playbook checks the profile's current values first and only
appends when the value isn't already present, so re-running it for an already-blocked value is
a safe no-op. Also make sure only one Netskope integration instance is enabled at a time - if
two are enabled, Cortex dispatches the command to both, causing the same double-add.

Network Profile changes are staged. Set Deploy to true to apply the pending change; it defaults
to false. ChangeNote is recorded only when a deployment is requested.

Adds hashes to a Netskope file hash list via netskopev2-update-file-hash-list.

IMPORTANT: Netskope's file hash list API (v1) has no endpoint to read the current list content -
every update REPLACES the full list, it cannot append. Since Netskope itself can't tell us
what's already there, this playbook tracks the running hash set on the Cortex side instead, in
a Cortex List named "NetskopeHashList_<ListName>" (auto-created on first run): it reads that
List's current content (via the NetskopeGetXsoarListContent script), merges it with NewHashes,
sends the full merged set to Netskope, then writes the result back (via
NetskopeSetXsoarListContentWithRetry, which retries a few times if Cortex's storage backend
reports a transient version conflict from a concurrent write) to the same Cortex List so the
next run picks up where this one left off. No manual "what's already in the list" input needed.

Only MD5 (32 hex chars) and SHA256 (64 hex chars) hashes are accepted - the command itself
validates this and rejects anything else. A "duplicate request, no change" response from
Netskope is treated as success, not an error, since the desired state (these hashes being
present) is already true in that case.

The ListName input must reference a Netskope list that already exists (the tracking List on the
Cortex side is separate and gets created automatically). If the tracking List is empty,
the playbook stops unless AllowEmptyMirrorOverwrite is explicitly enabled.

Synchronizes bounded Cortex Threat Intel indicators to a Netskope Destination Profile.
The profile name is required. Match type and indicator types have editable playbook defaults,
and each input is validated independently before any Netskope command runs.

Existing profiles are updated in batches of at most 10 values. New profiles are created as
pending changes. Set Deploy to true to apply pending changes; it defaults to false so scheduled
jobs cannot enforce changes without explicit authorization. The default indicator query selects
active indicators with a Bad reputation and can be further restricted with tags.