Resource Types

Resource Types

A resource type is the type of configuration or resource in the SaaS app. Resource type has properties that can be used in the NGL condition or you can refer to linked Resource Types in the condition. For example, in Okta app suite, “Account”, “ApplicationUsers”, “ApplicationUser”, etc are the resource types. Resource Types are specific to the App Suite. To review the list of Resource Types that can be used in your NGL, take a look at the DOM files for your App Suite. Resource Type has properties metadata associated with them, like attribute, type, reference and description for the resource type attribute. For example, ApplicationUser Resource Type have lastUpdated, appId, scope, etc properties.

Primary Resource Type

Resource type mentioned immediately after the app suite is called Primary Resource Type. When your NGL executes as a Rule in your Policy, all findings will be associated with the Primary Resource Type. For example, 

microsoft365 remotedomain should-have autoforwardenabled = false

Here, remotedomain is a primary resource type.

Secondary Resource Type

Secondary resource types are linked resource types that are referred to in the rules, these will be part of the condition section of the rule. For example, 

Okta ApplicationUser should-have Application with-attribute { lastUpdated > 30 } 

That is, ApplicationUser resource type of the Okta app suite should have Application resource, where Application resource type should have LastUpdated property with > 30 result. While Application is a secondary resource type.

Namespace Resource Type

Namespace resource types are created for organising resource types under a single type. These do not have any metadata. For example, ApplicationUsers of Okta app suite is a namespace resource type with no metadata.

For example, ApplicationUsers, Application, Roles, etc in Okta are namespace resource types. Such resources help prevent namespace conflicts, as multiple services tend to use similar names for their resources in different ways.

Let’s consider an example, in this NGL query, it makes sure that there is at least one anti-phishing policy configured in Microsoft 365:

microsoft365 defenderforoffice365 should-have antiphishpolicy exists

defenderforoffice365 resource type is a namespace node which is linked to an antiphishpolicy resource type node with properties. The rule evaluates to true only when there is at least a node for antiphishpolicy linked to the defenderforoffice365.

Using Multiple Resource Types

Conditions in NGL can use multiple linked resource types to express complex conditions. Resource types which are linked to each other can be used in NGL to validate a configuration. This helps to assess how secure are the multiple resource types working in unison. See the list of DOMs to get more information on the resource types. Below are some examples  of using multiple resource types in your NGL:

• When all the links should match a condition. For example,

  azuread conditionalaccess should-have conditionalaccesspolicy with-attribute { state = "enabled" }

  This NGL query will evaluate to true for the ConditionalAccess resource when all the linked ConditionalAccessPolicy have an attribute state =”enabled”.

  

  – To view the ConditionalAccess resource, access the Microsoft Entra ID DOM, then expand IdentityAndSignIn > ConditionalAccess.
  – To view the ConditionalAccessPolicy resource, access the Microsoft Entra ID DOM, then expand IdentityAndSignIn > ConditionalAccess > ConditionalAccessPolicy

  The truth table for the evaluations results of the rule will be as follows:

  	Cp2-state = enabled	Cp2-state = disabled
  Cp1–state = enabled	Success	Fail
  Cp1–state = disabled	Fail	Fail

• When any of the linked resources match a condition. For example,

  azuread conditionalaccess should-have any conditionalaccesspolicy as c with-attribute { c.state = "enabled" }

  This NGL query will evaluate to true for the ConditionalAccess resource when any of the linked ConditionalAccessPolicy satisfies the condition.

  

  – To view the ConditionalAccess resource, access the Microsoft Entra ID DOM, then expand IdentityAndSignIn > ConditionalAccess.
  – To view the ConditionalAccessPolicy resource, access the same Microsoft Entra ID DOM, then expand IdentityAndSignIn > ConditionalAccess > ConditionalAccessPolicy.

  The truth table for the evaluations results of the rule will be as follows:

  	Cp2-state = enabled	Cp2-state = disabled
  Cp1-state = enabled	Success	Success
  Cp1-state = disabled	Success	Fail

• The resources can be linked using the refers-to relationship. For example, in the Salesforce app suite, DelegateGroup which is linked to DelegateGroupMember, which is also linked to User.

  

  – To view the DelegateGroup resource, access the Salesforce DOM, then expand Metadata > DelegateGroups > DelegateGroup.
  – To view the DelegateGroupMember resource, access the Salesforce DOM, then expand Tooling > DelegateGroupMembers > DelegateGroupMember.
  – To view the User resource, access the Salesforce DOM, then expand SObjects > Users > User.

The link between DelegateGroup and DelegateGroupMember exists through the DelegateGroupId attribute. With these three resource types in action, NGL to find DelegateGroup if any of the linked User has a name “demo user1” is written as:

salesforce DelegateGroup should-have DelegateGroupMember with-attribute {any user as u with-attribute { u.Name = “demo user1” }}

The truth table for the evaluations results of the rule will be as follows:

Understanding DOM Files

DOM files are a dictionary of resource types supported by Netskope SSPM. The resource types are specific to an App Suite and could be hierarchical in nature. Detailed information on the hierarchy of the resource types and how they are linked can be found in the DOM files. You can refer to DOM files when you write NGL queries and rules.

List of DOM files

• GitHub

• Google Workspace

• Microsoft 365

• Microsoft Azure AD

• Okta

• Salesforce

• ServiceNow

• Workday

• Zoom