cancel
Showing results for 
Search instead for 
Did you mean: 

Custom Rules using Domain Specific Language

cshernaman
Community Manager
Community Manager

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.

 

Screen Shot 2021-09-15 at 8.03.25 PM.png

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

 

For example:

Screen Shot 2021-09-15 at 8.03.41 PM.png
Entity

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

Screen Shot 2021-09-15 at 8.05.49 PM.png
Here are some examples of using an entity.

Screen Shot 2021-09-15 at 8.06.45 PM.png
Condition

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

 Screen Shot 2021-09-15 at 8.08.09 PM.png

 

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

Screen Shot 2021-09-15 at 8.09.05 PM.png
Function

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.

Screen Shot 2021-09-15 at 8.09.34 PM.png
Property

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.

Screen Shot 2021-09-15 at 8.10.31 PM.png

Compliance Rules

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.

    Screen Shot 2021-09-15 at 8.19.03 PM.png
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,

  4. Test the new custom rule by running a command like the following:
  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:

       Screen Shot 2021-09-15 at 8.18.32 PM.png
    • 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.

 

 

For more on custom rules, check out the "Custom Rule" label in the SPM Discussions board.

 

 

Much appreciated,
Chris

Chris Shernaman
Online Community Manager
0 REPLIES 0