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 in Salesforce environments.

Netskope Governance Language (NGL) is a rule description language created by Netskope to allow for the most granular and specific expression of security policies. With NGL, enterprises can create policies that go beyond the traditional configuration value checks to express complex rule logic that take into account the unique needs of their business infrastructure. In this article, we'll show you how to use this language with some handy queries, rules and workflows you can easily copy and modify to the needs of your own organization. For more information on how to get started with Netskope SSPM and NGL in Microsoft Azure AD context, check out our previous tutorial. The full syntax of NGL is explained in the Netskope documentation.

To find 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 "Switch to NGL" -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.

Let’s say that you are running a SaaS application such as Salesforce which relies on her own user and identity management. This might be synced with an external Identity Provider such as Azure AD or Okta, but you also have identity and access requirements for external users such as contractors, channel sales partners and programmable service accounts. As a security administrator, you want to investigate what kind of external users your managed SaaS service has and whether they might present elevated risk to your data.

To start your investigation, you might want to find every account that you could consider to belong to a non-company entity. A common way to do that would be to look for accounts that are linked to email addresses that do not match your company domain. With NGL search, you could try a query like:

Now we have filtered out all users who have been registered to Salesforce with our corporate email address. However, we notice that a default installation of salesforce creates a bunch of service users with “example.com” and “salesforce.com” email addresses, so let’s add a few more checks to the NGL to find users with “Standard” Usertype and “example.com” email addresses for more accurate filtering.

As a security administrator this kind of filtering is already very useful for me as I can use it to do a review on the users my organisation grants external access for and their security configurations. I can perform tasks such as reviewing when the last time external users had logged in and set old accounts for removal.

External Salesforce users are probably outside the scope of the company identity management platforms. Therefore we want to use this filter to ensure that critical information fields are filled for any user accounts that do not seem to belong to our organisation. For example, to ensure that any user who fits our earlier filter criteria should have their “CompanyName” field populated in their user records, we could write the following query:

Note that since we changed the “should-not-have” selector to “should-have” in this query, we now get a list of all the resources which are compliant to this criteria. Filtering for violations is useful when we are looking for anomalies and developing rules, but for continuous monitoring rules, we need to formulate the rule in the form of desired state of our resources.

We can save this query as a rule from the UI using the “Create Rule” button, name it and fill the description and remediation guides as we see fit. After we deploy the rule as instructed in Netskope Documentation, we can instantly see all violations of this rule from the Security Posture Compliance pages.

Your organisation might have a policy that all people who have Access to Salesforce should be company employees or only use company-allowed email-addresses and login methods. For this kind of enforcement, simpler rules like salesforce user should-have textmatch(Email, "netskope.com") = true can be enough. Or for application wide checks for undefined fields, a check like salesforce user should-have CompanyName exists will work. Whether your need is for straightforward blanket checks for huge numbers of resources or want to define very granular criteria for high-value monitoring tools, NGL is an expressive and powerful tool for skilled security teams.