Performance and rulset optimization

How Suricata/Match performance is measured, what drives throughput, and practical ruleset tuning tips (noise reduction, profiling, bypass rules, and resizing guidance).

About IDS Performance:

IDS performance is largely dictated by 3 factors:

1. The underlying IDS engine performing the inspection. In this case Suricata.

2. The IDS ruleset loaded: This can be the Vectra Match Curated Ruleset or provided by the customer, or some combination therof.

3. The network traffic: This is where the most variability will be. Every network is going to have different applications, systems, and other unique factors that can impact what traffic is present.

How Vectra Determines Vectra Match Performance: Methodology

In order to accurately measure performance, Vectra leverages the industrial grade traffic generator Ixia Breakingpoint to simulate real world deployments at scale.

1. Vectra leverages an Enterprise Traffic Mix within Breakingpoint to simulate real world customer networks with a realistic mix of applications consistent with averages that Vectra observes in customer networks who have opted-in to share metadata with Vectra.

2. Vectra leverages a tuned version of the ETPro ruleset. The ruleset is updated to run the latest rules available at the time of testing.

3. Each sensor model is tested with the same traffic mix, just with different scale according to the specs.

4. The test will must run for XX period of time, with 0.001% or less of drops at a rated performance

While there is no one size fits all traffic mix or test, this is a good representation and stress test of real world networks.

Performance Tuning Considerations

Given the IDS engine and the traffic in your environment are not variables, you can affect the performance of the IDS based upon the ruleset itself. There are a few things to note:

1. Rules that start with # are disabled and will not be compiled or have any impact on the system at all.

2. Performance is not linearly attributed to the number of signatures that are enabled. Suricata is a highly optimized engine such that rules that share common matching criteria are optimized so that the performance is not O(n) where n is the number of signatures. It is more important to write efficient signatures than the number of signatures.

3. You should consider which rule categories that you enable in your ruleset. For instance, Info, Policy, and Hunting categories are typically audit signatures, which may be noisy in your environment. These can be removed or disabled to avoid noise and performance impact.

   1. You can identify the Category of a rule by looking at the second word in the msg field. For instance the following rule is of Category Info. This field will always identify the category, and can be used to craft your policy if desired.

      1. alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET INFO DYNAMIC_DNS HTTP Request to a *.adistra .com Domain"; flow:established,to_server; http.host; content:".adistra.com"; endswith; reference:url,freedns.afraid.org/domain/registry/page-10.html; classtype:bad-unknown; sid:2044594; rev:1; metadata:attack_target Client_and_Server, created_at 2023_03_14, deployment Perimeter, signature_severity Informational, updated_at 2023_03_14, mitre_tactic_id TA0011, mitre_tactic_name Command_And_Control, mitre_technique_id T1568, mitre_technique_name Dynamic_Resolution;)

4. The Vectra Match Curated Ruleset generally contains a metadata field called performance_impact, if the signature is set to Significant that means that it will generally have more performance impact. Not all signatures have this, but ET does try to identify those that do. Many of these are disabled by default e.g.

   1. #alert tcp $HOME_NET any -> $EXTERNAL_NET !$HTTP_PORTS (msg:"ET MALWARE [PTsecurity] pkt checker 2"; flow:established, to_server; dsize:50<>101; stream_size:server, <,35; stream_size:client, <,610; stream_size:server, >,0; stream_size:client, >,30; flowbits:noalert; flowbits:isset, FB180732_1; flowbits:unset,FB180732_1; flowbits:set,FB180732_2; classtype:trojan-activity; sid:2024696; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, created_at 2017_09_11, deployment Perimeter, former_category TROJAN, malware_family Remcos, performance_impact Significant, signature_severity Major, updated_at 2017_10_02;)

5. Metadata fields do not impact the performance of the rules

Ruleset Noise Tuning:

You have full control over the ruleset that is enabled in your Vectra Match environment. There are a few suggestions when it comes to tuning your ruleset.

1. Consider excluding high volume categories. Vectra has performed this task for the Curated ruleset, but this is general purpose tuning and you may elect to do further tuning or modify existing tuned rules.

2. If you do not want to eliminate entire categories, then review what signatures are triggering overall to identify if any of those individual signatures can be eliminated or further tuned.

3. Consider adding or adjusting thresholds to rules to tighten up the detection probability. For instance, SCAN rules are typically set with a best case value from ET, but those might not be applicable in your environment, so you may need to tune them to better meet your environments expected performance.

4. Consider restricting which networks can be triggered in IP ranges of the ruleset. This can be done to either include or eliminate networks from alerts. While you cannot set your own variable values, you can just put the networks into the signatures directly in place of the variables.

Rule Writing Considerations:

While the ETOpen, ETPro, and Vectra Match Curated Ruleset rulesets are extensively QA'd to validate noise and performance impact, if you are writing your own rules, you should validate them in a local environment before pushing to Vectra Match. This can be done by leveraging the Rule Profiling feature in Suricata: https://suricata.readthedocs.io/en/suricata-7.0.0/performance/rule-profiling.html. This feature enables you to run Suricata on a local environment, either listening on a network card or consuming a packet capture with the ruleset your have provided to measure the performance on a rule by rule basis. As rule performance is a function of both the Engine, the Ruleset, and the Traffic inspected, the performance of a ruleset may vary from environment to environment. The Rule Profiling feature enables you to see exactly which rules are consuming the most resources for further consideration.

In general expensive rules include the following:

1. Rules that run on all packets: Ideally you can constrain rules to run on specific protocols, ports, and buffers (contexts) rather than running across all traffic as this means the rule will be invoked continuously impacting performance.

2. Rules that leverage PCRE, but don't have good fast patterns

3. Rules that run on expensive buffers like http-data. These can be expensive in circumstances where all portions of the buffer must be inspected

Bypassing Traffic in Suricata:

Suricata provides you with capabilities to skip traffic from inspection (thus improving performance.). The most popular way is by using the Bypass keyword. This allows you to specify a traffic pattern that you would like to match (e.g. Youtube) and anything in the remaining flow will be skipped. For instance the following would skip any HTTP traffic to Youtube.com

alert http any any -> any any (content:"www.youtube.com";http_host; bypass; sid:1; rev:1;)

Similar signatures can be written for the TLS equivalents by matching on the TLS.SNI field.

How can I resize a virtual Sensor to allow for more Match throughput?

If your virtual Sensor does not have the resources to run Match in addition to its normal duties producing metadata for your Vectra platform, it can be resized to a larger configuration that supports more throughput. Alternatively, you can also redeploy the vSensor in a larger supported configuration. For details per supported platform, please see the guidance in the Resizing Virtual Sensors and Brains .

Are your rules making use of HOME_NET, EXTERNAL_NET, PROXY_IPs, and EXCLUDE_NET variables?

• Please see the Vectra Match FAQ for details on how these variables are set and the impact they will have on rules.

• Check the following headings for details once on the above FAQ:

  • How does Vectra populate the HOME_NET variable?

  • Does Vectra support setting other variables besides HOME_NET?