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 URLs, MD5 hashes, SHA256 hashes, IPv4 addresses, IPv6 addresses, hostnames, domains, and fully qualified domain names (FQDNs) 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.
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.
For instance, 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 indicators can be found in the Threat Exchange tenant by using the filter and searching for any indicators tagged as “invalid_host” or “Unshared”. Invalid App tags can be found using the tag “Invalid app”.
https://<your Cloud Exchange host>/cte/threat_iocs?query=sources.tags+IN+%28"Invalid+host"%29
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
- 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.
- Click Add Sharing Configuration and select a source plugin configuration.
- 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.
- Select a Target. Each plugin will have a different target or destination for the IoC.
- 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.
Some systems will support the IoC only to be used to match for certain endpoint OS (Windows, Mac, Linux).
- 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.
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.
Write-access users can update sharing or its target of an existing sharing configuration.
- Click the Edit icon.
- Update the required fields which you want to change.
- Click Save.
Write-access users can sync an already configured sharing. This will trigger a sharing mechanism to share the IoCs to a destination configuration.
- Click on the Sync icon.
- 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.
- Click Fetch. This will display the number of IoCs will be shared with destination configuration. this action will be performed on.
- Click Sync.
Write-access users can delete any of the existing configured sharing.
- Click on the Delete icon.
- 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.
- Go to Threat Exchange and click Threat IoCs.
- 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.
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.
- 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.
| Field | Filter String variable | Description | Filter operators |
|---|---|---|---|
| Value | value | IoC value – MD5 SHA256 for filehash or URL. | Is equal and contains (Regex also supported). |
| Comments | comments | Comments provided for that IoC. | Is equal and contains (Regex also supported). |
| Type | type | Type of the IoC. MD5, SHA256, URL | any in, not in operator (Multiselect) |
| Netskope Hits | netskopeHits | Number of times Netskope has seen this IoC. | !=, <, <=, >, >= |
| Other Hits | OtherHits | Number of times third parties have seen this IoC. | !=, <, <=, >, >= |
| Test | test | Boolean value whether IoC is marked as Test from Netskope (a metadata field value used for testing) | Is equal, != |
| Active | active | Boolean value whether IoC is expired or not. | Is equal, != |
| Safe | safe | Boolean 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 With | sharedWith | List of plugin configurations where IoC was pushed. | any in, not in operator (Multiselect) |
| Expires At | expiresAt | Time at which the IoC becomes inactive | !=, <, >, >= |
| Field | Filter String Variable | Description | Filter Operators |
|---|---|---|---|
| Source | sources.source | IoC value – MD5 SHA256 for filehash or URL. | Is equal and contains (Regex also supported). |
| Severity | sources.severity | Severity of IoC. | Is equal and contains (Regex also supported). |
| Reputation | sources.reputation | Confidence of the information. Low 1 – High 10. | !=, <, <=, >, >= |
| Netskope Hits | sources.netskopeHits | Number of times Netskope has seen this IoC. | !=, <, <=, >, >= |
| All Other Hits | sources.externalHits | Number of times third parties have seen this IoC. | !=, <, <=, >, >= |
| First Seen | sources.firstSeen | Time when CTE first saw IoC from a plug-in | !=, <, >, >= |
| Last Seen | sources.lastSeen | Time when CTE last saw IoC from a plug-in | !=, <, >, >= |
| Tags | sources.tags | Tags associated with the IoC data | any in, not in operator (Multiselect) |
| Comments | sources.comments | Comments provided for that IoC. | Is equal and contains (Regex also supported). |
- 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.
- 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.
- After selecting the desired filter, click Apply Filter. IoCs matching the filtering criteria will be listed in the UI.
- 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.
- 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.
- Also users can enter the filter query manually and can load the filters according to the query.
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. More information regarding managing the tags can be found on Manage Tags section.