Back 
When I talk to customers and partners about Cloud Threat Exchange (CTE), I immediately say, “I’m not in marketing, and didn’t see the future—so I misnamed the module. I should have named it Cloud Data Exchange.” Why do I say this? Because, as Netskope and Cloud Exchange have matured, the number of use cases the module can fulfill has naturally grown beyond the initial vision. How so?
In most customer deployments, Cloud Threat Exchange is enabled to facilitate the sharing of indicators of compromise, or IoCs. IoCs are information elements (IP addresses, CIDR blocks, URL, URI, domains, or file hashes) attributed to known attack elements. We originally built CTE to automate the sharing of this information among multiple, connected parties, including Netskope, because we believed that what one part of the security stack knows about an attack, all parts should know. Doing this via CTE reduces the operational strain of moving these IoC, making it a multilateral, automated push and pull versus a bilateral, manual push or pull. Once the “feed” of IoCs to be shared has been defined, the data movement becomes automatic. In many cases, we have heard customers tell us that the functionality is easy to enable and has resulted in attacks being discovered by other parts of the stack and then remediated by a different component—finding in the cloud, remediating on the endpoint; finding in the endpoint, remediating/blocking in the email solution; finding on the email, remediating/blocking in the cloud. All of this reduces dwell times for persistent, advanced threats and enhances the likelihood for comprehensively protecting against attacks.
As our ecosystem of partners continue to innovate, CTE has been expanded to go beyond exchanging IoC, and can move these data objects (IP addresses, CIDR blocks, URL, URI, domains, or file hashes) regardless of their original categorization. Systems like SecLytics surface indicators of behavior (IoB), which are warnings that an attack may be happening or about to happen. The same data objects can still be pushed into CTE plugged-in systems, but using the CTE feature of “labels”, each could be tagged by a string indicative of risk level provided with that object.
In other words, labels add a rich, additional layer of context that can be used to make decisions about where the data is sent and how it is used. In the case of Netskope policy, this label could be used to take low severity IoC, and low risk IoB, and send each to a URL object used by an alerting rule, whereas medium severity IoC and high risk IoB could be sent to a URL object used to coach users away from engaging with those matching resources. Labels open up many use cases, including indicators of attack sharing, application access governance, URL filtering synchronization (see more below), SSL decryption rule population, SSL bypass rule population, and more.
Additionally, a year after CTE was launched, the Netskope platform expanded the DLP engine to support reading the file hash file object that CTE had previously been designed to use for inline threat prevention policies, the only policy function that could take advantage of custom file hashes at CTE inception. Now file hashes that CTE are able to extract from third-party systems can be used for exact data matches in DLP policy. We built the GitHub CTE plugin to take advantage of this enhancement. CTE could now pull file hashes related to all GitHub content in any given repository and push it into an object that the DLP policy refers to to enforce appropriate data sharing. In GitHub’s case, this enables customers to control sharing any code or content that exactly matches, with continuously automated refresh cycles. I’m looking forward to our planned expansion of how Cloud Exchange can work with innovative Netskope features and ecosystem data protections to make its use easier.
Finally, we see more customers using CTE to help migrate from legacy, premise-based URL filtering solutions to Netskope. In many cases, customers have spent years building custom URL lists. CTE can work with many solutions to extract those lists for use in Netskope, ensuring everyone can benefit from all of that work in the Security Cloud for direct to cloud use cases.
I’m proud of how Netskope has evolved, and how Cloud Threat Exchange, and its parent platform Cloud Exchange, continue to be able to take advantage of those features. If you have a use case that require you to move data between Netskope and IT/security solutions, please contact your Netskope account team and let’s talk. You can learn more about CTE here.
Read the blog