DSL

Overview

Interceptor has based the DSL (Domain Specific Language) rules on Suricata, which means you can write your own rules based on your framework.

General considerations

Interceptor has added support for Suricata syntax and uses it's engine to process rules. (For example, DSL is designed to allow end-users to use Suricata-based rules with interceptor detection engine.)

You will not need to synchronize suricata and interceptor terms, because the terms have already been synchronized by interceptor wherever possible.

IMPORTANT

You will have to take the following into consideration:

• The difference between suricata and interceptor when creating your own rules
• Individual network packages
• Inspection of buffers (strings)
• Runs simple checks (one condition per rule)
• Unique alerting approach (alert creation and track rules revision)

This means you will need to:

• Synchronize Suricata and interceptor terms. Since interceptor deals with statistics/metrics derived from network traffic, not individual packages as Suricata does, you will need to synchronize terms so that end-users can expect interceptor implementation of Suricata DSL to produce the same results as native engine.
• Figure out the most efficient way to execute multiple rules. Automatic rule optimizations is crucial for performance. Suricata provides suggestions on how to improve rule performance but the main difference is that the native Suricata engine runs in a client infrastructure so performance optimization is end-user responsibility.
• Embed the Suricata alerting approach into interceptor. Suricata assumes there is a rule management system (sid/rev keywords) and provides an ability to customize alerts.
• Adjust Suricata to deal with interceptor-specific data representation. Interceptor per-protocol data representations provides different properties to be inspected in traffic (ports, bytes sent/received, etc.), so we may add support for them in DSL (interceptor-specific dialect)

Suricata DSL support

IMPORTANT

Known limitations:

• Matching on entire packet buffer is not supported. As capture sensor data is a representation of a network packet(s) (network communication stats and metadata), porting rules that match on entire packet buffer is not possible. Such rules have to be modified to specify which part of buffer to match exactly, for example, use of specific sticky buffers in a rule. The rule alert http any any -> any any (content:"index.php"; sid:1;) is not supported as there’s no way to match on entire http packet. It should be re-written to match on ‘http.uri’ instead: alert http any any -> any any (http.uri; content:"index.php"; sid:1;)
• Sticky buffers only will be supported. Suricata has two types of keywords: sticky buffers and content modifiers. The content modifier is the legacy way to specify buffer to apply a rule condition to, such as content:".php"; http_uri;. As the most of content modifiers have sticky buffer analogue, a Suricata rule can be re-written (http.uri; content: ".php"; is the same).

DSL Rule Creation Process

The creation of DSL rules involves several steps (analyst):

1. Finding new attack vectors or toolkits that the attackers might use
2. Looking for publicly known detections (rules)
3. Creating unique rules to cover these attacks
4. Testing them on the development environment first
5. Deploying tested rules to customers

Looking for Publicly Known Detections?

To save some time trying to create a good detection, sometimes it is better to look for existing rules, which experienced analysts have already created.

For more information, we recommend the following sources:

1. https://rules.evebox.org
2. https://github.com/SigmaHQ/sigma
3. https://threatfox.abuse.ch/share/

Documentation on Suricata DSL can be found here https://suricata.readthedocs.io/en/latest/rules/index.html

DSL Rule Editor

Creating a DSL Detection

To Create a DSL detection, follow these steps:

1. Navigate to Settings > Security and click on a + button

2. Provide required information to create a detection:

• Detection name and DSL rules (1 or more)
• Severity and Mitre Technique. Optionally, provide description

The newly created detection is now available in the detections list. Keep in mind that it will take some time (~1hour) for the detection engine to pick it up and start monitoring network traffic for the specified threat.

3. (Optional) Navigate to Cybersecurity > Alerts to check alerts (if any).
   It will take ~1 hour for interceptor to reload updated DSL detections.

Rules validation

In order to create a new DSL detection successfully, all provided rules must be valid. Detection creation will fail if there’s at least one malformed rule.

There are two types of validations performed:

• Syntax
• Policy type ambiguity

Syntax Validation

Due to the difference between interceptor and Suricata network traffic models not all valid Suricata rules can be ported to interceptor. The following errors can occur during validation:

• Malformed syntax (missing braces, invalid values etc.)
• Unsupported syntax (not yet implemented protocols, unsupported keywords etc.)
• Other syntax errors (unknown keywords, unexpected parsing errors etc.)

DSL detection cannot be created if at least one rule has unsupported syntax.

Malformed rules must either be corrected or removed to create a detection. To get the details on failed rules and failure details, hover over Not approved label.

Detection Type Ambiguity

This check is mandatory given detections are a container for multiple rules. The basic rule is all rules must resolve into the same detection type., meaning:

• different types cannot mixed.

For example, a detection with the rules below will not be valid:

alert dns $HOME_NET any -> any any (msg:"Inline"; dns.query; content:"cnc.domain";)
alert dns $HOME_NET any -> any any (msg:"Limit"; dns.query; content:"cnc.domain"; threshold: type limit, track by_both, count 1, seconds 60;)

As rule 1 has inline type and rule 2 is thresholding, there is a type conflict, which cannot be resolved automatically. To resolve it, either rule 1 should be updated to include thresholding configuration or rule 2 should be updated to remove it.

In the same way, rules with counter type cannot be mixed with thresholding rules and inline rules.

• for thresholding and counter policy types, thresholding/counter configuration should be the same across all rules.

Thresholding configuration includes threshold type (for thresholding type only), aggregation key (track), the threshold value (count) and period (seconds).

Example 1. Conflicting threshold types.

alert http ... (.. threshold: limit, track by_src, count 1, seconds 10; ..)
alert http ... (.. threshold: both, track by_src, count 1, seconds 10; ..)

Example 2. Conflicting aggregation key.

alert http ... (.. detection_filter: track by_src, count 1, seconds 10; ..)
alert http ... (.. detection_filter: track by_dst, count 1, seconds 10; ..)

Example 3. Conflicting threshold values.

alert http ... (.. detection_filter: track by_both, count 1, seconds 120; ..)
alert http ... (.. detection_filter: track by_both, count 5, seconds 10; ..)

To resolve conflicts, either all threshold/counter configurations should be unified across rules (so that all rules are either inline, thresholding or counter) or conflicting rules could be removed from the list of rules so that the remaining rules all have the same type.

Integration with other features

DSL detections can be used with other features:

• Allowlisting to add an allow-list to a DSL detection, find it in the list of detections.
• Allowlist section is available on the bottom of edit policy pane.

• interceptor portal users and zone-based user groups DSL detections have limited support for this feature (support depends on detection type):
  • Inline. Fully supported. Alerts/Incidents are generated based on both client and server zones.
  • Stateful (Thresholding, counter). Partially supported. The level of support depends on type of key used in aggregation. Whereas there will not be any issues when aggregation key includes both source and destination ips, unintended alerts can be generated when the key includes only one IP (either source or destination or none). As alerts are being generated based on attack direction and currently there’s no way to specify it for DSL policies, expected alerts will be raised for a zone corresponding to IP used in aggregation key, but also extra alerts can be raised for a zone that corresponds to IP that is not a part of an aggregation key. As a result incidents may appear a bit misleading.

It is recommended to use track by_both in stateful detections (that is sufficient in most cases) to avoid any inconsistencies.

Important Considerations

Suricata rule providers (such as https://rules.evebox.org/) create multiple rules to detect the same or similar type of network attack, for example:

The dynamic detection support has been designed to combine multiple rules under the same detection. This means that it’s strongly recommended to have one detection with multiple similar rules rather than one policy for each rule.

There is no hard limit on number of rules per detection or overall number of rules across all detections, so it is recommended you do not exceed 100 rules per detections.