Netskope’s new graph-powered SaaS Security Posture Management (SSPM) engine can help security analysts investigate root causes and identify repeating patterns for all kinds of security misconfigurations. To help one get started with the SSPM and the powerful queries made available by the Netskope Governance Language (NGL), we’ve collated this post to show you some easy sample investigations you can perform with Azure AD / Microsoft 365 environments.
To get to the Next Gen SSPM features and NGL from the Netskope main view, one needs to navigate to “API-enabled Protection -> Security Posture (Next Gen) -> Inventory” and click the icon on the right side of the filters toolbar. This opens up the NGL query tool which we will be using for the rest of the article.
The most basic use case for NGL would be to simply list resources by their type. Since NGL is a pattern matching language designed to identify which resources comply with a given criteria, we need to formulate our query to a statement which evaluates to a true/false result. Therefore an NGL that lists all resources of a given type should be a condition which evaluates to true with all of the resources of the same type. For example, every object in Microsoft Graph which implements the entity resource type carries an id field, which we can use to formulate simple inventory queries. To list all User objects from the NGL search tool, we can try the following query:
azuread user should-have id exists
This query will look for all User objects from the Azure AD app suite which have a property called “id” with them. As every entity in Microsoft Graph carries that property, we get a list of all Azure AD User resources tracked by the SPM. Likewise, if we wish to search for list of all applications visible to the SPM we can use a very similar query:
azuread application should-have id exists
The full syntax of NGL is explained in the Netskope documentation. To get started, we might want to do a slightly more precise query by using properties available for the tracked resources. To filter out for users with a certain type of email address we could use the textmatch() -function of NGL and write:
azuread user should-have textmatch(mail, "onmicrosoft.com") = true
This kind of expression can be useful for finding out users whose email addresses in the AzureAD tenant are of the form organizationname.onmicrosoft.com, which is the default format used by Microsoft 365 accounts which are not associated with a custom domain. This kind of pattern can be helpful for security investigators to find anomalies from incomplete migrations or non-compliant resources.
To invert this search and find the accounts who do not match that pattern, we simply change the “should-have” condition to “should-not-have” and will get a list of every user record who do not have that text pattern in their registered email address.
The Netskope SSPM models the SaaS applications we monitor as closely to their object data models and their relationships as possible. Many artifacts the security analyst wishes to monitor are actually collections of resources connected to each other by object links. For example, for a user to grant a web application access to their personal and Azure AD organization resources will involve multiple Azure AD objects such as:
- “Application” which represents the public registration of a Enterprise application using Azure AD authentication
- “Service Principal” represents the local representation of an application inside the AAD tenant or directory. This can be useful to think of as an “installation of an application” to your specific environment.
- “App Role Assignments” which are used to link Microsoft Graph principals such as users and application roles to individual representations of application deployments in the environment
- “Oauth2 Permission Grants” which link application service principals with delegated permissions from individual users.
With Netskope SSPM, we find all of these resources from our inventory and are able to perform queries to them with NGL. Being able to navigate these resources, identify the most sensitive assets, find what entities, permissions and relationships exist between them and codify into automatically monitored rules is what the Netskope SSPM, the underlying graph engine and Netskope Governance Language is designed to do.
For instance, a good common query for investigations could be to find applications installed by an individual user. One place where this kind of information can be found is from the App Role Assignment objects. Therefore, one could find all app role assignments belonging to principal/user named “Eetu Korhonen” with NGL such as:
azuread approleassignment should-have principaldisplayname = "Eetu Korhonen"
For another use case, let’s say that the security administrator wants to be notified of Microsoft 365 Add-Ins which have been given permissions to read (and write) company document files from Microsoft 365 environment and to communicate with external servers. This can be an indication of compromise of malicious or dangerous plugins potentially leaking sensitive information. As this kind of information is available in the Service Principal objects, we can find such elements using an NGL such as:
azuread serviceprincipal should-have addins with-any-element v
properties with-any-element n
key = "Capabilities" and
value = "ReadWrite Document;Send Data"
]
]
Should the administrator wish to use this query to create an automatic monitoring alert from any new applications with similar properties, they can use the “Create Rule” option to save it as a custom rule that can be deployed to Netskope compliance monitoring policies like every other built-in detection.
Tip: To make an effective compliance check, one should remember to check that the “should-have/should-not-have” expression is set correctly. When doing investigations with NGL search, one is typically looking for non-compliant anomalies with “should-have” expressions. But when the user wants to be alerted from similar resources they’ve been searching for and to fail their compliance checks if the condition is met, it’s important to change the expression to “should-not-have” in the continuous monitoring rule.
NGL is an incredibly powerful tool for a security administrator and we will be digging into more of her capabilities in upcoming articles. A great way to get started on NGL is to take a closer look at the built in content of the SSPM and the detailed definitions of individual rules. NGL is not only an investigative tool for the user, but it’s the language used by our own security engineers to develop content for the platform. The detections Netskope releases to the platform can be directly run and modified by the user to be perfectly tailored to their organisations individual needs.
