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 decryp