Netskope Help

Configure Threat Exchange IoC Sharing

Make sure to identify the sharing requirements between systems before configuring.

Netskope Threat Exchange enables the sharing of IoC from 3rd-party platforms to and from Netskope (and each other). Though originally designed for managing attack indicators, it has evolved to support additional use cases including synchronizing and managing secure web gateway (SWG) to allow and block lists, populating SSL interception or bypass lists for CASB and SWG, and surfacing filehash information for Github repositories to prevent this data from being inappropriately shared using Netskope’s inline DLP functionality.

API in use for Threat Exchange Sharing to Netskope

To communicate with Netskope tenants, Threat Exchange uses the APIv2 endpoint, if it is enabled in the Netskope tenant and configured in Cloud Exchange, or APIv1 if that is the only token either configured or available, as is the case for updating file hashes for use in threat prevention policies.

Threat Exchange pushes this IoC information to Netskope into one of two locations. URL and IP addresses are pushed to a custom category file that is used by the custom categories function of the Next Generation Secure Web Gateway (https://<your-tenant>.goskope.com/ns#/web-profiles-page?subview=webList) and filehashes (MD5 and/or SHA256) are pushed to a file profile file (https://<your-tenant>.goskope.com/ns#/file-filter-profile).

However, just because information can be pushed by Threat Exchange does not mean that the information is usable by the receiving system. File hash types, URL formatting, or the availability of data repositories all can reduce the potential functionality of the sharing function.

URL Sharing Supported per Plugin

Plugin

Pull URL

Ingest URL

Netskope

Yes

Yes

CrowdStrike

Yes

Yes*

SentinelOne

No

No

Mimecast

Yes

No**

VMware Carbon Black EDR

Yes

Yes

VMware Carbon Black NGAV

Yes

No

Cybereason

Yes

Yes

Microsoft Defender for Cloud

Yes

No

Microsoft Defender for Endpoint

Yes

No**

MISP

Yes

Yes

STIX/TAXII

Yes

No

ProofPoint

Yes

No

ServiceNow

Yes

Yes

ThreatQuotient

Yes***

Yes

* CrowdStrike ingests the URL from Threat Exchange, but removes everything after the domain

** Enhancements to ingest URL in Mimecast and MS Defender for Endpoint plugins are in progress

*** ThreatQuotient plugin shares up to the website domain, but does not yet share the FQDN. This Threat Exchange plugin enhancement is in progress.

URL Requirements/functionality for Threat Exchange to Netskope

Netskope accepts some URL, depending on their formatting.

https://docs.netskope.com/en/create-custom-categories.html

As you can see URL in the custom URL list, the file must be formatted a particular way, specifically each must look like one of the following

http(s)://url.domain.com/fullURI

OR

http(s)://ipaddress

OR

http(s)://*.domain.com/fullURI

When Threat Exchange sends a Non-compliant URL to Netskope

When Threat Exchange sends a URL (alone or as part of a larger update) that is rejected by the Netskope client, Threat Exchange parses the Netskope response, identifies the invalid URL, and marks it as “invalid”. By default, Threat Exchange will not attempt to push it again to the Netskope tenant.

These invalid URL can be found in the Threat Exchange tenant by using the filter and searching for any indicators tagged as “invalid”

https://<your Cloud Exchange host>/cte/threat_iocs?query=tags+IN+%28%22invalid%22%29

image1.png
  1. Go to Threat Exchange and select Sharing. The Sharing page displays the existing relationships for each sharing configuration in grid view as shown below. The Sharing page also has inputs to configure new sharing from one plugin to another.

    image6.png
  2. Click Add Sharing Configuration and select a source plugin configuration.

    image7.png
  3. Select a Business Rule and a Destination Configuration. Sharing configurations are unidirectional. data obtained from one plugin is shared with another plugin. To achieve bi- or multi-directional sharing, configure each separately.

    image9.png
  4. Select a Target. Each plugin will have a different target or destination for the IoC.

  5. Select an Action. Some plugins support multiple actions that equate to where the IoC could go, and therefore, what the receiving system will do with a matching indicator.

    image8.png

    Some systems will support the IoC only to be used to match for certain endpoint OS (Windows, Mac, Linux).

  6. Click Save.

Adding a new sharing configuration on the active source poll will share the existing IoCs of the configuration to the destination configuration. Whenever a new sharing configuration is built, all the active IoCs will also be considered for sharing if they match the source/destination combination.

Note

Plugins that do not have API for ingesting data cannot receive threat data. This is true of the installed plugin API Source, which provides a bucket associated with an API endpoint for remote 3rd-party systems to push data to. Once a Sharing policy has been added, it takes effect.

After a sharing configuration has been created, the sharing table will show the rule being invoked, the source system providing the potential IoC matches, the destination system that will receive matching IoC, and the target applicable to that rule. Multiple Sharing configurations can be made to support mapping certain IoC to multiple targets even on the system destination system.

Each configuration supports 3 actions:

image10.png
  • Edit the rule by clicking on the pencil icon.

  • Test the rule by clicking on the synchronization icon. This tests how many IoC will actually be sent to the destination system based on the timeframe and the rule.

  • Delete the rule by clicking on the garbage can icon.