Netskope Help

Create a Security Assessment Rule

To create a security assessment rule:

  1. Click NEW RULE.

    The New Custom Rule page opens.

  2. Under RULE NAME, enter a rule name.

  3. Under CLOUD PROVIDER, select a cloud services platform and click SAVE & CONTINUE.

  4. Under SEVERITY, select the rule severity from the drop-down list. The available options are Critical, High, Medium, and Low. Select the level of severity you want to assign to this rule.

  5. Under DEFINITION, enter a rule definition using Domain Specific Language (DSL). For information on DSL, see Custom Rules using Domain Specific Language.

    Alternatively, use the IMPORT FROM RULE option to import and modify an existing rule.

  6. Click SAVE AS DRAFT to continue working on the rule or SAVE to save the rule.

  7. Click VALIDATE DEFINITION to validate the rule and fix any syntax errors.

  8. Click the COMPLIANCE tab and specify the compliance standards that the rule must satisfy.

    • STANDARD: The name of the compliance standard, like CIS-AWSFND-1.2.0, NIST-CSF, etc.

    • SECTION: The section of the document that describes the compliance standard.

    • CONTROL: The section control of the document that describes the compliance standard.

    For example, the predefined rule CIS-AWSFND-1.2.0-2-3 Ensure the S3 bucket CloudTrail logs to is not publicly accessible is defined in the CIS AWS Foundations document. In this example, CIS-AWSFND-1.2.0 is the compliance standard, 2 is the section, and 3 is the control.

  9. Click +ADD to specify a new compliance standard that the rule must satisfy. Click SAVE AS DRAFT to continue working on the rule or SAVE to save the rule.

  10. Click the OTHER tab to specify a rule description. Click SAVE AS DRAFT to continue working on the rule or SAVE to save the rule.

    The rule is displayed in the Rules section of the Profiles & Rules page.

  11. Click APPLY CHANGES.

Custom Rules using Domain Specific Language

Build custom rules under Policies > Security Assessment using Domain Specific Language (DSL) for Security Assessment of AWS, Azure, and Google Cloud resources. 

The following syntax diagram represents the general rule to write a DSL statement.


Rule Format: <entity> [where <condition>] should [not] have <condition>

For example,

S3Bucket should not have any ACL in (
IAMUser where Name eq “root” should have Password.Enabled eq true and MFAActive eq true

An entity defines what the rule is checking against. It can be used alone or with a condition to further specify the entity.


Here are some examples of using an entity.

<entity> should have <condition>

S3Bucket should have LoggingEnabled

AADuser should not have Type eq "Guest"

<entity> where <condition>

The "where" condition further defines the entity to narrow down the result.

IAMUser where Name eq “root” and MFAActive eq true

AWS where CloudTrails with [ MultiRegionTrailEnabled eq true ]

For a complete list of supported entities and attributes, see


A condition is a standard that the rule uses to check against an entity to narrow down the result.


The following table provides examples of using a condition. The formats in this table are applicable to all properties.


AWS should have CloudTrails

<property> [func()] <operator> <value>

IAMUser should have Name eq “root”

IAMUser should have Policies.Managed len() eq 0

<property> with/contain <condition>

AWS should have IAMUsers with [ Name eq “root” ]

<property> in/notin (<value1>, <value2>, <value3>)

IAMUser should have Name in ( “root”, “name2” )

use quantifiers for list and sequence properties

IAMUser should have atleast one Password eq “1234”

use and, or, not, ( ) for complex conditions

IAMUser should have (Name eq “root”) and (MFAActive eq true)


Use functions in rules to find specific information about entities. Functions use the following syntax,

<entity> <function>(<argument>)

For example,

S3Bucket should have Tags len ( ) gt 0

Protocol in ("-1", "tcp")

The following table provides a complete list of functions available to use in rules.


Property Types


Returns property type



list, string



Returns the length of string or list.





Number of hosts in subnet.





Whether IP is private (IPy).





Whether IP is public (IPy).





Whether LHS number is divisible by argument.

in, notin

string, boolean, ip, number



Whether LHS value is in list (shortcut for long OR).





Whether LHS list contains any one of the lists passed in as argument.


number (date)

number, units


Whether LHS number (date) is later than current time +/- number units (arguments). For example, isLaterThan ( -1, "days") means LHS is later than 1 day ago (from scan time). Units must be one of the following: seconds|minutes|hours|days|weeks.

"days" is most common.


number (date)

number, units


Whether LHS number (date) is earlier than current time +/- number units (arguments). For example, Password.LastUsedTime isEarlierThan ( -90, "days")). Units must be one of the following: seconds|minutes|hours|days|weeks.

"days" is most common.


Property is used to define the condition the rule is checking as well as to narrow down the entity the rule is checking against. Property can be nested using “.” such as, MFADevices.Virtual where the rule checks for all the virtual devices.

The following is the syntax format.

<entity> should [not] have <property>...

<entity> where <property>...

The following table provides the list of property types and the functions they support.

Property Type

Operators and Functions



in, notin, contain, with, len()

IAMUsers with [ Name eq “root” ]


in, notin

MFADevices in ( “ID1”, “ID2” )


eq, neq, like, not like, len()

Name eq “root”


eq (=), neq (!=), gt (>), gte (>=), lt (<), lte (<=)

Topic.Subscriptions len() > 0


eq, neq

Password.Enabled eq true


eq, neq

IPRanges with [ ip eq ]

Compliance Rules

Netskope provides a list of predefined rules to check your IaaS and SaaS environment for security posture compliance. For a complete list of predefined rules, see:

Common elements used to write a DSL rule

The following elements are commonly used in a DSL rule.

  • with - To access the elements in any list.

  • "."

  • where - To restrict evaluated assets.

  • Operators - Such as, eq, gte, gt, lt, lte, neq.

  • Functions - Such as, like, has, in, len, isEarlierThan, isLaterThan, len.

  • Numeric range syntax - For example, to check for port 137 and port 138, include the following in the syntax.

    FromPort lte 138 and ToPort gte 13


    Will match any security group or firewall ruleset that has a port range including 137, 138 or both.

Custom DSL rule writing best practices

The following best practices are recommended when writing custom DSL rules.

  1. Start by looking at existing predefined rules. If a predefined rule can perform the required checks on your IaaS resources, add the rule to your custom profile.

  2. If an existing rule partially satisfies your requirement, then copy and modify the existing rule.

  3. Check the property types and expected values on the Cloud Service Provider (CSP) side and Netskope supported entities. The types and hierarchy may differ. To check the property types and values:

    • on the CSP side use the CSP test environment through CLI.

    • on Netskope side use the Inventory API. For example, get details about the S3 Bucket resources in AWS run,

      curl --request GET "https://&amp;lt;tenant_url&amp;gt;/api/v1/public_cloud/inventory?token=NS_API_TOKEN&amp;amp;limit=10&amp;amp;skip=0&amp;amp;resource_name=&amp;lt;name_of_asset&amp;gt;&amp;amp;resource_type=S3Bucket" | python -mjson.tool
  4. Test the new custom rule by running a command like the following:

    curl --location --request POST "https://<tenant_url>/api/v1/public_cloud/rule_evaluate?token=NS_API_TOKEN" --header 'Content-Type: application/json' --data-raw '{ "cloud_provider": "aws", "rule_code": "S3Bucket should not have Access eq \"Public\"",  "instance": "NS_UI_CONNECTION_INSTANCE",  "resource_ids": [  ]  }'

    Ensure that the instance name matches the name configured in your AWS tenant stack.

  5. Debug the rule based on the test results. Netskope recommends testing the rule using at least two property values where one matches the rule, and the other does not. For example, test using different users such as, root, admin, non-admin. When testing policies, test using both inline and managed policies.

  6. Consider false positives and false negatives in the rule output and refine the rule.

    • Include a "where" clause in your rule. For example, to flag any non-root users that haven't logged in, in the past 90 days write a rule like,

      IAMUser where RootUser eq False and LastUsedTime isEarlierThan ( -90, "days" ) 
    • Make sure you know the CSP entities and how they're configured. It is important to know all values that are allowed for the property to ensure that there aren't missing values. For example, to check a TCP protocol you must understand that in addition to tcp-only ("tcp") there is a wildcard "All Protocols" which is saved as -1.

      Refer to the Netskope documentation as well as the CSP documentation to understand all supported values for an attribute field.