Configure Threat Exchange IoC Sharing

Configure Threat Exchange IoC Sharing

This page describes how to configure IoC sharing between the plugins (and therefore connected vendor systems). Make sure to identify the sharing requirements between systems in advance of configuration. The sharing relationships each require a business rule to control what data is shared with the destination plugin.

Note that each plugin for which a sharing rule is intended may have requirements that dictate the nature of the business rule. There is no point in creating a sharing rule to match IoC for sharing if that rule will be used to push information towards a system that can not use or can not receive those IoC types (STIX/TAXI for example is a push, never a pull, model).

Additionally, there is a section on IoC Sharing Best Practices that suggests mechanisms to insert manual overrides to dictate exactly when IoCs are shared, rather than allowing the system to automatically share all rules. Tags are a central part of this approach.

Threat Exchange URL Handling

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 file hash information for Github repositories to prevent this data from being inappropriately shared using Netskope’s inline DLP functionality.

Netskope will accept IP addresses (v4), CIDR ranges, URL domains, and URI as a “URL” to be used in the custom URL file for invocation as a destination match in a Netskope Real-time policy. The custom URL file must be used in policy, but that policy can result in any of the supported inline outcomes, including, but not limited to: block, alert, coach, justify, etc.

API in use for Threat Exchange Sharing to Netskope

To communicate with Netskope tenants, Threat Exchange uses the REST API V2 if it is enabled in the Netskope tenant and configured in Cloud Exchange, or REST API V1 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 file hashes (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.

Filehash and URL Sharing Supported per Plugin

PluginPull URLPush URLPull FilehashPush Filehash
NetskopeYesYesYesYes
CrowdStrikeYesYes*YesYes
SentinelOneNoNoYesYes
MimecastYesYesYesYes
VMware Carbon Black EDRYesYesYesYes
VMware Carbon Black NGAVYesNoYesYes
CybereasonYesYesYesYes
Microsoft Defender for CloudYesNoYesYes
Microsoft Defender for EndpointYesYesYesYes
MISPYesYesYesYes
STIX/TAXIIYesNoYesYes
ProofPointYesNoYesYes
ServiceNowYesYesYesYes
ThreatQuotientYesYesYesYes
ThreatConnectYesYesYesYes
MandiantYesNoYesYes
AWS GuardDutyYesNoYesYes
SentinelOneYesYesYesYes

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

URL Requirements/Functionality for Threat Exchange to Netskope

Netskope accepts some URL, depending on their formatting. To learn more, go to: Create Custom Categories

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

Threat Exchange Filehash Handling

Netskope provides, and will accept, SHA256 and MD5 filehashes for use in files for invocation by inline threat prevention policies (or DLP rules relying on a filehash match). The file must be added into a policy, but that policy can result in any of the supported inline outcomes, including, but not limited to: block, alert, coach, justify, etc.

Duplicate IoC Handling

Netskope Threat Exchange allows write-access users to choose how to reconcile and manage duplicate IoC provided by the same or different sources. If ‘never override’ is chosen, all subsequent matching IoC metadata will be shown under the master IOC. Master or child IoC metadata can be used for creating sharing rules to decide what and which IoC and IoC metadata to send.

Add a Sharing Configuration

  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.
  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 source 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.

Manage a Sharing Configuration

Each configuration supports three actions: edit, sync, and delete.

Edit Sharing

Write-access users can update sharing or its target of an existing sharing configuration.

  1. Click the Edit icon.
    image2.png
  2. Update the required fields which you want to change.
  3. Click Save.

Sync Sharing

Write-access users can sync an already configured sharing. This will trigger a sharing mechanism to share the IoCs to a destination configuration.

  1. Click on the Sync icon.
    image4.png
  2. Enter the Time Period (in days). Only the IoCs fetched during this period will be considered while evaluating the business rule. Checking the All Time will evaluate the IoCs from last year.
  3. Click Fetch. This will display the number of IoCs will be shared with destination configuration. this action will be performed on.
  4. Click Sync.
    image5.png

Delete Sharing

Write-access users can delete any of the existing configured sharing.

  1. Click on the Delete icon.
    image6.png
  2. Click Delete.

List IoCs and Filtering Capability

Threat Exchange maintains a database of IoCs provided from all configured plugins. You can view all available IoCs, view the metadata for each, and filter IoCs.

  1. Go to Threat Exchange and click Threat IoCs.
  2. A list of all active IoCs appear. The first time you see this screen, the default view will present IoCs added or updated (via API) in the last 7 days.
    image8.png

    More can be pulled from the database of active IoCs, depending on the filtered query. The IoCs list is paginated with a default page size of 10 records that can be increased to show up to 100 records. By default, records are sorted in descending order of Last Seen.

  3. You have different filter options available based on the IoC metadata or IoC Sources that is or can be associated with each IoC. Each user can add one or more filters and can add a group of filters to dive into a subset of all the active IoC. The detailed list of filter options and field meanings is presented below. You can also select Not for a negative filter criterion.
    image9.png

IoC Metadata

FieldFilter String variableDescriptionFilter operators
ValuevalueIoC value – MD5 SHA256 for filehash or URL.Is equal and contains (Regex also supported).
CommentscommentsComments provided for that IoC.Is equal and contains (Regex also supported).
TypetypeType of the IoC. MD5, SHA256, URLany in, not in operator (Multiselect)
Netskope HitsnetskopeHitsNumber of times Netskope has seen this IoC.!=, <, <=, >, >=
Other HitsOtherHitsNumber of times third parties have seen this IoC.!=, <, <=, >, >=
TesttestBoolean value whether IoC is marked as Test from Netskope (a metadata field value used for testing)Is equal, !=
ActiveactiveBoolean value whether IoC is expired or not.Is equal, !=
SafesafeBoolean value whether IoC is safe or not. (Metadata field value used to denote a non-malicious IoC for the Github DLP plug-in)Is equal, !=
Shared WithsharedWithList of plugin configurations where IoC was pushed.any in, not in operator (Multiselect)
Expires AtexpiresAtTime at which the IoC becomes inactive!=, <, >, >=

IoC Sources

FieldFilter String variableDescriptionFilter operators
Sourcesources.sourceIoC value – MD5 SHA256 for filehash or URL.Is equal and contains (Regex also supported).
Severitysources.severitySeverity of IoC.Is equal and contains (Regex also supported).
Reputationsources.reputationConfidence of the information. Low 1 – High 10.!=, <, <=, >, >=
Netskope Hitssources.netskopeHitsNumber of times Netskope has seen this IoC.!=, <, <=, >, >=
All Other Hitssources.externalHitsNumber of times third parties have seen this IoC.!=, <, <=, >, >=
First Seensources.firstSeenTime when CTE first saw IoC from a plug-in!=, <, >, >=
Last Seensources.lastSeenTime when CTE last saw IoC from a plug-in!=, <, >, >=
Tagssources.tagsTags associated with the IoC dataany in, not in operator (Multiselect)
Commentssources.commentsComments provided for that IoC.Is equal and contains (Regex also supported).
  1. For more than one filter criteria, move the mouse to the upper right of the filter box and click Add rule. Select the appropriate comparison operator And or Or by moving the mouse over the Not button in the upper left; options will then be shown.
  2. For alternative multi-data criteria, click Add group. Rules will be processed from top to bottom. Move the mouse to the upper right of the filter box to see the Add group option.
  3. After selecting the desired filter, click Apply Filter. IoCs matching the filtering criteria will be listed in the UI.
  4. Click Clear to remove the applied filter; the UI will revert to the default filter, and IoCs matching the default filter will be listed when the screen refreshes.
    image10.png
  5. Users can copy the filter string created in the rules engine after applying the filter. Click Copy Filter to copy the actual search string. The copied string can be used as a filter in any plugin configuration to limit the data Threat Exchange sends to a third-party plugin.
  6. Also users can enter the filter query manually and can load the filters according to the query.
    image11.png

Select and Modify Tags

Write-access users can modify Tags. Tags are used to add metadata to IoCs so SecOps teams can create workflows for filtering, viewing, staging, or pushing particular IoCs to plugins. Please note, when an IOC is tagged (regardless of type), any subsequent table entries of the same IoC will be similarly tagged, as it is a global setting.

Tags are displayed in IoC Sources of the IoC shown by clicking on the down arrow.

image1.png

You can add or edit the tags from this view, or select multiple IoCs from the summary list and click on the Tags button to select and apply tags.

image2.png

You can also select or deselect the tags for selected IoC from the Threat IoCs page, plus create new tags and apply a tag color.

image3.png

Manage Tags

Write-access users can create new Threat tags or delete them in this Settings menu. Click Add to create a new tag, and then enter a name and select color. You can delete the tag by clicking on the X icon on each tag.

Share this Doc

Configure Threat Exchange IoC Sharing

Or copy link

In this topic ...