The Netskope Threat Exchange module within Cloud Exchange is our open source solution to IoC sharing between security tools. Once configured, Threat Exchange can store and share thousands of IoC’s from tools such as Netskope, CrowdStrike, Microsoft Defender, ThreatConnect and many others, alongside the capability of adding IoC’s via Cloud Exchange’s API. The large amount of data pulled can be overwhelming, so we wanted to share some best practices for Threat Exchange that you can follow and use within your own environment.
Refine Your Business Rules.
Your business rules are one of the most important aspects of your Threat Exchange instance since they are used for your sharing configurations. Unless you want everything being shared over to your set of configured tools, you will need to refine your business rules to the specific items you want to send. You can leverage fields found within the IoC’s you pull. For example, some plugins will allow you to pull severity information from the configured tools which can then allow you to create business rules around high, medium, and low severity IoC’s. Something we highly recommend, is creating groups within your business rules for allowlisting/blocklisting IoC’s, in the event some of them cause issues within your environment. You are then able to add more rules to the group for the values you want to exclude.
For example, the Digital Shadows plugin is able to pull impersonating domain data. If a legitimate domain was pulled but had not been properly configured as “legitimate”, depending on your current business rules, the domain could be shared out to all of your tools. This would cause issues for users navigating to that domain, incorrectly seeing it as an impersonating domain due to your set policies. The best way to stop internal domains or hashes of tools from being shared is by adding the values to the allowlist/blocklist mentioned earlier.
- Remember, there is a Create Business Rule button within the Threat IoC’s section.
Before creating a business rule via the Business Rule section, please keep in mind that there is a Create Business Rule button within the Threat IoC’s section.
We recommend creating your query within the Threat IoC’s section. If you have your plugins configured, and they have polled for IoC’s at least once, you will have some IoC’s to filter through. You can modify the query and get results in real time, which helps in finding the perfect query for your business rule. This way you will have a better idea of what the business rule will actually share out to your tools once it is added to a sharing configuration. You can also copy existing business rule filters and paste them into the filter builder within the Threat IoC’s section. You can then load the filter and look through the results, modify the filter, and create new business rules once you are happy with the modified filter.
Don’t “blitz” tool API endpoints
Keep in mind that most tools won’t have a constant stream of IoC’s coming in every second or minute. Due to this, we highly recommend you keep the sync period for your plugins to every 60 minutes (except for the Netskope plugin since its sync period is set to every 30 seconds), unless you have tested the plugin and are content with a faster refresh period.
We recommend this because we don’t want Cloud Exchange to, as we call it, “blitz” your API, which can cause rate limiting issues. Rate limiting means you have made too many concurrent requests to the same endpoint, and you will need to stop sending requests to it for a certain amount of time before it allows you to interact with it again. This isn’t something we strictly recommend for the Threat Exchange module, as this can be applied to the other modules as well. If the plugin has no need for a short sync period, then it should be extended to at least an hourly sync period.
Test sharing configurations when possible (test lists or environments)
We all expect things to work properly without the need to reconfigure anything or troubleshoot, but sometimes this isn’t true and we end up with issues that have us starting from scratch. To avoid this, use test environments to take a look at what will happen if you were to share and take actions on the IoC’s being shared. One thing you can do in Netskope is create a test URL list within the tenant. You can then set the destination within a sharing rule to your Netskope CTE plugin (if configured), and set the URL list within the sharing configuration to the test URL list you created in your tenant. You can then allow the list to sync and take a look at what that list will look like within the tenant. From there, you can apply the list to a test policy that only affects you or a policy that is only set to alert to assess the impact it will make if applied to everyone as a block policy.
Use tags for IoC reviews and sorting
If you are reviewing your IoC’s, either automatically or manually, you should be aware of tags and how they can be useful for your review process. Tags were made to help sort through your IoC’s without having to rely on the information pulled from each plugin. You can use these tags to mark IoC’s that you have reviewed and you can look for the specific tag within your business rules to make sure you are using IoC’s that have been reviewed within your sharing configurations. For example, if you do a quarterly review of your IoC’s, you can create a tag called “Q2-2022” for your second quarter review. You can then add this tag to each IoC that has passed the review process, either manually or automatically via Cloud Exchange’s API. There are two endpoints that allow you to add tags to IoC’s, “/api/cte/indicators” allows you to update a specific IoC and “/api/cte/indicators/bulk” allows you to make bulk changes. Leverage each or both endpoints to make the tagging process of your IoC’s much easier and faster. For more information on these endpoints reference the Swagger documentation within your Cloud Exchange instance, which is usually found at https://<your-cloud-exchange domain>/api/docs.
Finally, I’d like to point you to our Cloud Exchange hardening document, Cloud Exchange Hardening. Threat Exchange lies within the Cloud Exchange platform, so securing the host instance in which it lives is important. Keep in mind your own environment and its configurations, so not all items within the document might be applicable.
I hope these items help with organizing and improving your Threat Exchange setup. Feel free to comment with suggestions and feedback or reach out to support@netskope.com if you are experiencing any issues with your implementation.