Evolving the Netskope Risk Exchange Ecosystem: Making User-based Changes

Early last month, Netskope announced a few key security innovations across the Netskope One platform and some of my colleagues kicked off the conversation about Netskope Risk Exchange in a previous blog, Evolving the Netskope Risk Exchange Ecosystem.

This blog series will continue to explore a number of different workflows that those comfortable using basic scripting, or enablement tools like Postman, can employ to programmatically update and inform your inline policy actions. These are just some of the functions that the newest version of Cloud Exchange (CE), version 5.1, supports now and in the future. Look for it to hit the shelves at the end of this month (Oct. 2024).

Netskope’s Adaptive Risk Framework

Netskope wishes to make it easier for our customers and partners to identify and respond to high risk users, instances, apps, and workloads using automated enrichment and correlation actions. This will enable our customers to leverage multi-vendor sourced or single vendor correlated findings to continuously tune Netskope’s adaptive trust policy enforcement framework.

One of the key value propositions of Netskope is its ability to correlate multiple user personas (Korg-lord-of-thunder, [email protected], and fluffythevampireslayer) to a single, unique identity–[email protected]–managed by our IdP partners and leveraged by almost every vendor in a customer’s IT/security stack. This correlation enables us to take disparate user behavior when engaging with managed and unmanaged applications, instances, workloads, and data and bind it to a unique user. Regardless of which systems see a particular user’s persona behaving strangely, we can pivot off that common schema and map it from system A to system B. 

(As an aside from zero trust, this also means that we can apply policies based on that unique user identity, even if they have engaged with a system using a completely different persona–including triggering conditional access or step up authentication for activities where the solution is not even federated with the identity provider. But I digress.)

What does this mean? It means that even if a totally different system–like Mimecast, CrowdStrike, or Okta–surfaces different measures of risk, all can be tied to a user and can result in changes to these systems. Cloud Risk Exchange illustrates how to do this by collecting various risk scores from many different systems, normalizing them, and aggregating/weighting them so the numbers “add up” and can be used to change risky users’ access to and through connected solutions.

In the case of Netskope, there are two ways to use externally sourced risk. First, systems like CE can modify, aka “impact,” machine-learning derived User Confidence Index scores for customers that have purchased Netskope’s User Behavior Analytics license. The score can be incrementally reduced while providing the source (Mimecast, for example) and reason code for why [email protected] should have his score dropped from 1000 to 800 (because Mimecast says he can’t stop clicking on phishing links in email containing puppy pics). 

Second, CE and other systems like CrowdStrike Falcon NG-SIEM can leverage the System for Cross-domain Identity Management (SCIM) protocol to provision a risky user into one or more groups that are already in a “ready to go” policy for enforcing a different, usually less permissive, set of access combinations. For example, [email protected] is a member of the “/teller_team” and can normally download files from websites and fully access the team database server. If Microsoft tells us that [email protected] is high risk, CE can add bobfoo to “/bad_users” which is configured in a top level policy to only allow browsing websites and blocks their access to the database. Bob’s risk to the enterprise is reduced until their overall risk is seen as restored.

There are implications and benefits to both methods. Adding a user to a different group may take up to 30 minutes to synchronize, but you don’t have to purchase the UBA license. The change is absolute–once Bob is in the new group, they are there until someone/thing removes them.

On the other hand, impacting a user score will take effect in approximately five minutes. You have an audit trail as to why it changed, the ability to revert the specific score change, and the ability to change other triggers Netskope uses to calculate the main UCI score. User scores are also high fidelity indicators for other systems, like Microsoft or Okta, to use to make their own intelligent risk responses.

Learn more about how SCIM works from a RESTful API perspective as shown below. Learn more about how to best use the UCI “impact” score here.

A complete walkthrough of what we covered here is captured in our Netskope Community article for our more technical audience, here.