Skip to main content

Netskope Help

AWS GuardDuty Plugin for Threat Exchange

This document explains how to configure the AWS GuardDuty plugin with the Threat Exchange module of the Netskope Cloud Exchange platform. This integration allows for pulling SHA256 IoCs from AWS GuardDuty to the AWS GuardDuty plugin.


To complete this configuration, you need:

  • A Netskope Tenant (or multiple, for example, production and development/test instances).

  • A Netskope Threat prevention subscription for malicious file hash sharing.

  • A Netskope Cloud Exchange tenant with the Threat Exchange module already configured.

  • Access to your AWS Access Key ID (Public Key), AWS Secret Access Key (Private Key), AWS Session Token (Optional, only for temporary user), Region Name, and Detector ID (Unique Detector ID).

  1. Get your AWS GuardDuty credentials.

  2. Configure the AWS GuardDuty plugin.

  3. Configure sharing between Netskope and AWS GuardDuty.

  4. Validate the AWS GuardDuty Plugin.

Click play to watch a video.

  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 in the Source Configuration dropdown list, select AWS GuardDuty.

  3. Select a Business Rule, and then select Netskope for the Destination Configuration. Sharing configurations are unidirectional. data obtained from one plugin is shared with another plugin.

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

  5. For Add a File Hash List, enter a List Name, List Size, and Default File Hash. The List Name needs to exist in your Netskope UI at Settings > Policies > Profiles. For information about creating a File Profile for hashes, refer to Adding a File Profile

  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.


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.

Modify, Test, or Delete a Sharing Configuration

Each configuration supports 3 actions:

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