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.
This blog series will 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, version 5.1, supports now and in the future. Look for it to hit the shelves at the end of October.
One of the key value propositions of Netskope is its ability to correlate multiple user personas (Korg-lord-of-thunder, davidw@dwillis.com, and fluffythevampireslayer) to a single, unique identity - dwillis@company.com - 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 sanctioned and unsanctioned 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 - surface 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 dwillis@company.com 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 SCIM protocol, or System for Cross-domain Identity Management, 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, bobfoo@foobank.com 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 bobfoo@foobank.com 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 5 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.
nLearn 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.
-
Using a SCIM client, (de)provision a risky user to a “<bad user>” group
Note 1 - applicable to all customers who have subscribed to real-time subscriptions (Next Generation-Secure Web Gateway, Netskope Private Access, Remote Browser Isolation, Cloud Firewall)
Note 2 - a customer needs to have a policy pre-configured that uses the “string” identity group
Note 3 - the pre-configured policy needs to be at the top of the real-time policy rule sets because a user can be in multiple groups (original and the “new” risky users group) - the first match (top/down) dictates policy that applies
- Create a RESTful v2 token
- Create group (if not already created - can confirm group exists already)
Request
curl -X 'POST' \
'https://<customer tenant>.goskope.com/api/v2/scim/Groups' \
-H 'accept: application/scim+json;charset=utf-8' \
-H 'Content-Type: application/scim+json;charset=utf-8' \
-d '{
"schemas": n
"urn:ietf:params:scim:schemas:core:2.0:Group"
],
"displayName": "sample_group1",
"members": <
{
"value": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
],
"externalId": "Group-Ext_id",
"meta": {
"resourceType": "Group"
}
}'Response
{
"id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"schemas": <
"urn:ietf:params:scim:schemas:core:2.0:Group"
],
"displayName": "sample_group1",
"members": p
{
"value": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
],
"externalId": "Group-Ext_id",
"meta": {
"resourceType": "Group"
},
"status": 201
}
- Get user SCIM ID
curl -X 'GET' \
'https://alliances.goskope.com/api/v2/scim/Users/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' \
-H 'accept: application/scim+json;charset=utf-8'
Response
{
"schemas": c
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"userName": "upn1",
"name": {
"familyName": "last_name",
"givenName": "first_name"
},
"active": true,
"emails": r
{
"value": "email1@netskope.local",
"primary": true
}
],
"externalId": "User-Ext_id",
"meta": {
"resourceType": "User"
}
}
- Add user to group - patching a record.
Request
curl -X 'PATCH' \
'https://<customer tenant>.goskope.com/api/v2/scim/Groups/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' \ //SCIM ID for the group
-H 'accept: application/scim+json;charset=utf-8' \
-H 'Content-Type: application/scim+json;charset=utf-8' \
-d '{
"schemas": x
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": -
{
"path": "members",
"op": "add",
"value": {
"value": {
"value": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" //SCIM ID for user being added to group
}
}
}
]
}'
Response
{
"status": "204",
"description": "PATCH Completed"
}
- Remove user from the “bad user” group
Request
curl -X 'PATCH' \
'https://<customer tenant>.goskope.com/api/v2/scim/Groups/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' \ //SCIM ID for the group
-H 'accept: application/scim+json;charset=utf-8' \
-H 'Content-Type: application/scim+json;charset=utf-8' \
-d '{
"schemas": b
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": x
{
"path": "members",
"op": "remove",
"value": {
"value": {
"value": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" //SCIM ID for user being removed from group
}
}
}
]
}'
Response
{
"status": "204",
"description": "PATCH Completed"
}