Suspect Protocol Activity detections (feature overview)
Introduction
Suspect Protocol Activity (SPA) detections are a feature of Vectra NDR and enhance the overall effectiveness of a Vectra NDR deployment. Vectra's existing AI models provide an incredible breadth of coverage for both known and unknown attack vectors because they examine attacker behavior. These AI models can take months to over a year to research, build, test, and deploy. SPA detections are signature based or are based on much simpler to develop algorithms and can be developed in much shorter timeframes. Some attack behaviors do not need a sophisticated AI model to find them and can be efficiently found using simpler techniques.
Today, some SPA detections require a Suricata engine running on your Vectra Sensors, while other SPA detections are algorithm-based and do NOT require Suricata. If you see SPA detections in your deployment, and have not enabled SPA at the CLI, it is because the detection you are seeing did not require Suricata and was available to all customers as a normal part of product updates. Please note the following as you read through this KB:
Suricata-based SPA detections - this refers to SPA detections that require the Suricata engine to be enabled.
SPA detections - These can be Suricata based if you have enabled Suricata-based SPA detections, or can be algorithm-based.
Algorithm-based SPA detections do NOT require Suricata-based SPA detections to be enabled.
Algorithm-based SPA detections will be available to all Vectra Detect customers and require no configuration.
There is no additional licensing cost incurred for SPA detections. SPA detections are available starting in version 8.7 of Vectra software. To enable Suricata-based SPA detections, SPA must be enabled by executing a command at the CLI of your Vectra Brain. Suricata-based SPA signatures are automatically provided to your Vectra deployment from Vectra's cloud. At this time, there is no ability to support air gap deployments for Suricata-based SPA detections.
When SPA detections originally became available, Suricata use was required.
Now that algorithm-based SPA detection are available:
The commands and output for enablement and management of Suricata-based SPA detections have not changed or been renamed.
They still use SPA or Suspect Protocol Activity language while they now relate only to Suricata-based SPA detections.
SPA Detections Explained
For details on what each SPA detection covers please see Suspect Protocol Activity Detections (Explained).
Suricata-based SPA Detections vs Vectra Match
While Suricata based SPA detections and Vectra Match both use the same underlying Suricata engine there are differences and things to keep in mind if you want to run both Match and Suricata-based SPA detections.
Expand for details
Rule IDs used in Vectra Match and Surciata-based SPA
Rule IDs in a ruleset for Vectra Match are required to be a positive 32-bit integer.
ET rules and the Vectra Match Curated Ruleset use IDs in the 1,000,000 to 2,999,999 range.
IDs 9,000,000 to 11,999,999 are reserved for Vectra use.
If duplicate rule IDs are assigned to a Sensor, any existing rule is kept and the new rule is ignored.
Signature Source
Suricata-based SPA detections
Signatures are delivered from the Vectra Cloud and applied automatically.
Air gap deployments are not supported for Suricata-based SPA detections today.
Rule IDs 9,000,000 to 11,999,999 are reserved for Vectra use and should NOT be used for
Vectra Match
Signatures can come from a variety of sources and are uploaded and assigned via API or the Vectra UI.
Customer provided
3rd party sources such as ET Open or ET Pro, Snort's Talos, or various ISAC's (Information Sharing and Analysis Centers).
Air gap deployments are possible.
Detection/Match Delivery
SPA detections
Created detections that are both visible in the Vectra UI and contribute to scoring of host entities (QUX and RUX).
Vectra Match
Matches can be output via Vectra Stream to a data lake or SIEM (RUX and QUX), output to Vectra Recall (QUX only), or output using Syslog or Kafka to a downstream receiver (QUX only).
Matches do NOT contribute to host entity scoring.
When running both Vectra Match and SPA detections, no metadata (Matches) for SPA detections will be output using configured Vectra Match settings.
SPA detections behave the same as other Vectra detections.
Sensor (Device) Enablement
Only Match customers can choose which Sensors to enable for Suricata-based SPA detections.
When a Sensor is enabled for Vectra Match and Suricata-based SPA detections are also enabled, only the Sensors enabled for Vectra Match will run Suricata-based SPA detections.
If your deployment only runs Suricata-based SPA detections, all Sensors will be enabled for Suricata-based SPA detections once it is enabled.
Vectra Match Deployment
If you are interested in running Vectra Match in addition to SPA detections, please see the following Vectra Match related resources:
The Enabling / Disabling Suricata-based SPA Detections section below will provide additional guidance when enabling Suricata-based SPA detections in addition to Vectra Match.
Performance / Throughput
There are additional resources required to run the Suricata engine in addition to Vectra's AI-models on any network Sensor. Because of these additional resource requirements, the overall performance throughput of a Sensor is 40 to 60 percent lower than when running without Suricata-based SPA enabled. Customers will need to ensure that their traffic engineering and overall capture strategy takes into account the additional resources required to run Suricata-based SPA detections
Expand for additional details
Below is some general guidance regarding throughput of SPA detections:
When running SPA detections in addition to Vectra Match, the performance is the same as when running only SPA detections or only Match.
Physical Sensors generally perform the most consistently and process around 60% of the traffic they were capable of processing before enabling SPA detections.
Virtual Sensors (both deployed in traditional hypervisor environments and in IaaS clouds) process around 50% of the traffic they were capable of processing before enabling SPA detections.
In some cases, larger configurations of vSensors or additional physical Sensors may be required to fully support the throughput required to run SPA detections in addition to Vectra NDR.
Please work with your Vectra account team to ensure your deployment is sized appropriately.
If you virtual Sensor does not have the resources to run SPA detections 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 KB article.
Sensor throughput running Vectra NDR and throughput with SPA detections/Vectra Match also enabled:
Appliance Model
Mode
Throughput
(NDR/Detect only)
SPA/Match Throughput
(NDR/Detect and SPA/Match)
S1
Sensor
1 Gbps
400 Mbps
S2
Sensor
1 Gbps
600 Mbps
S11
Sensor
2 Gbps
1.2 Gbps
S101 (v1 and v2)
Sensor
50 Gbps
33 Gbps
X3
Sensor
9 Gbps
3 Gbps
X3
Mixed
8 Gbps
1 Gbps
X29 (v1 and v2)
Sensor
15 Gbps
9 Gbps
X29 (v1 and v2)
Mixed
8 Gbps
4.6 Gbps
X47
Sensor
20 Gbps
13 Gbps
X47
Mixed
15 Gbps
6 Gbps
X80
Sensor
20 Gbps
11 Gbps
2 core vSensors (VMware, Hyper-V, KVM)
Sensor
500 Mbps
250 Mbps
4 core vSensors (VMware, Hyper-V, KVM)
Sensor
1 Gbps
500 Mbps
8 core vSensors (VMware, Hyper-V, KVM)
Sensor
2 Gbps
1 Gbps
16 core vSensors (VMware, Hyper-V, KVM)
Sensor
5 Gbps
2.5 Gbps
32 core vSensor (VMware)
Sensor
20 Gbps
10 Gbps
2 core vSensors (AWS, Azure, GCP)
Sensor
1 Gbps
500 Mbps
4 core vSensors (AWS, Azure, GCP)
Sensor
2 Gbps
1 Gbps
8 core vSensors (AWS)
Sensor
4 Gbps
2 Gbps
16 core vSensors (AWS)
Sensor
8 Gbps
4 Gbps
16 core vSensor (GCP)
Sensor
5 Gbps
2.5 Gbps
32 core vSensor (GCP)
Sensor
10 Gbps
5 Gbps
Enabling / Disabling Suricata-based SPA Detections
You will need access to the CLI of your Vectra Brain appliance to enable, disable, or check the status of Suricata-based SPA detections for your deployment. If you are not already familiar with how to access the CLI of your Brain as the "vectra" user please see the following KB:
Planning for Required Sensor Downtime
Sensors need to reboot when they change their enablement state for Suricata-based SPA detections. This means that when a Sensor is enabled (changes state from disabled to enabled) or disabled (changes state from enabled to disabled), as a normal part of configuration, the Sensor must reboot.
Please keep in mind the following:
During the reboot of the Sensor, no traffic will be processed by the Sensor that you are changing the state on.
This means that metadata will not be passed to the Brain for further processing (Vectra NDR, Recall, Stream, etc).
If the device rebooting is a mixed-mode Brain, no traffic captured by that appliance will be buffered during the reboot.
Sensor reboots generally take from 1 to 10 minutes depending on the Sensor model.
Virtual (including cloud) Sensors are normally the fastest.
Hardware Sensors take a bit more time to boot.
Suricata-based SPA detections processes outside of the reboot mentioned above, can also take 5 to 10 minutes to complete when changing state.
These processes will not impact the non-Suricata-based SPA detections related duties your performed by your Sensor..
There are no impacts to the Brain, Recall, Stream, or other Sensors (that are not having their enablement state changed).
This only impacts the Sensor that is changing enablement states.
!! If the Brain is mixed-mode, it will also enable and therefore reboot.
You should plan enablement state changes for Suricata-based SPA detections during times where being unable to process traffic and forward metadata on to the Brain will have the least impact.
Suricata-based SPA Specific Commands
Help Output for Each Command:
Examples and Guidance for Specific Situations
Please read all of the below headings to see which apply to your deployment.
Warning Given When Enabling Suricata-based SPA Detections With a Valid Match License
When you enable Suricata-based SPA detections when you already have a valid Match license, you can control which Sensors are enabled/disabled and the SPA ruleset will be applied automatically to every Match enabled Sensor(device).
Only Match customers can choose which Sensors are enabled for Suricata-based SPA detections and this will always be the same as which Sensors are enabled for Match.
Warning Given When Enabling Suricata-based SPA Detections With No Match License
There is no ability to control which Sensors are enabled for Suricata-based SPA detections unless you also are a Match customer as per the above warning.
Warning Given When Enabling Suricata-based SPA Detections on a Mixed-Mode Brain
Since a mixed-mode Brain is both a Sensor and a Brain, both the Brain and any paired Sensors need to reboot.
Warning Given When a Match Customer Disables Suricata-based SPA Detections
There are no reboots or performance changes because Match is still running.
Functionally, the only change is that the Suricata-based SPA detections specific ruleset is removed.
Match continues to function normally.
Warning Given When a Customer Not Running Match Disables Suricata-based SPA Detections
As per the Planning for Required Sensor Downtime above, the Sensor needs to reboot to disable Suricata-based SPA.
If the Brain is in mixed-mode, then this additional message is appended to the one above:
All paired devices, including the mixed-mode Brain need to reboot to disable Suricata-based SPA detections.
Suricata-based SPA Proxy Support:
Suricata-based SPA automatically has support for discovered network proxy and excluded addresses just like Vectra Match. The Proxies are automatically discovered by the system and can be viewed on the Brain CLI using the "show proxy --southside" command.
Suricata-based SPA Detections Customers Purchases Match License
If the following applies in your situation:
Suricata-based SPA detections are already enabled.
Match is then purchased.
You are now wanting to enable your first device (Sensor) for Match.
You will receive a warning from the Match API that contains this text:
"Suspect Protocol Activity Detections are enabled, in order to Enable Vectra Match, you must first disable Suspect Protocol Activity Detections, Enable Match, then Re-Enable Suspect Protocol Activity Detections. For more information please see: https://support.vectra.ai/s/article/KB-VS-1793"
You must disable Suricata-based SPA detections first, then enable the first Match device (Sensor), and then re-enable Suricata-based SPA detections.
Once this is done, any devices enabled for Match will also run Suricata-based SPA detections. Any Sensors not enabled for Match, will not run Suricata-based SPA detections.
Example Suricata-based SPA Enabling / Disabling and Status Checking Example
Last updated
Was this helpful?