# FAQ

## General

**Do I need to run Vectra Match on all Sensors?**

* No, you can enable Vectra Match on a Sensor by Sensor basis.

**Will enabling or disabling Match on Sensor cause any downtime for the Sensor?**

* Yes, when a Sensor changes state (disabled to enabled, or enabled to disabled), the Sensor must reboot as part of its configuration process.
  * During this this time no traffic will be processed by the Sensor you are changing the state on.
  * This means metadata will not be passed to the Brain for further processing (Detect for Network, Recall, Stream, etc).
* Sensor reboots generally take from 1 to 10 minutes depending on the Sensor model.
* Match processes outside of the reboot can also take 5 to 10 minutes to complete when changing state.
  * These other configuration related processes will not impact the non-Match related duties 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.
* You should plan enablement or disablement of Match on a Sensor for times where being unable to process traffic will have the least impact.

**Does Vectra Match support IPv6?**

* Yes Suricata supports IPv6 detections.

**Does Vectra Match support Datacenter deployments?**

* Yes, Vectra Match can be deployed in both internal and external (DMZ) datacenters to provide detection.

**Does Vectra Match support air gap deployments?**

* Yes, Vectra Match can be deployed in air gap environments when used with Quadrant UX deployment. In Airgap deployments you may download the Vectra Match Curated rulesets from the Support portal, automatic ruleset downloads are not possible in Airgap deployments due to no connectivity.
* Respond UX cannot be delivered in air gap environments, though this is a factor of Respond UX itself.

**Do detections from Vectra Match show up in the Vectra UI?**

* This is possible for QUX deployments that are paired with Vectra Recall.
  * If a [Recall Custom Model](https://docs.vectra.ai/operations/analyst-guidance/recall-custom-models-how-to-create-detections-qux) is configured, a detection can be created in QUX.
* RUX deployments have Match metadata available in [Investigate](https://docs.vectra.ai/operations/analyst-guidance/investigate-quick-start-guide-prior-to-sql-search). This is not a detection and is not scored but the metadata is in RUX.
* Today, the Vectra Match detections are sent out via several different mechanisms.
  * For QUX, matches can be sent to your logging system via Syslog/Kafka. They are also available in Recall or Stream.
  * For RUX, matches can be output via [Stream](https://docs.vectra.ai/deployment/stream/deployment).

**What features of Suricata does Vectra Match not support?**

* Vectra Match supports the vast majority of Suricata features, and can fully load popular rulesets like ET Open or ETPro. There are a few exceptions of what Vectra Match does not support: Editing `Suricata.yaml`, `thresholds.conf`, `classification.config`, File Store, Lua, GeoIP, Datasets, logging metadata, pcap-log (aka rolling pcap).

**Is there a preferred protocol for sending Vectra Match Alerts?**

* For QUX deployments, Vectra Match supports both Syslog and Kafka protocols, including TCP and SSL for each. SSL is generally the preferred protocol because it is a reliable transport protocol and also provides encryption, confidentiality, and integrity.
  * Additionally, Vectra has observed that some detections can occur based on syslog alert traffic when sent over TCP if the provided signature is not well tuned. These can easily be tuned in the ruleset configuration, but leveraging SSL as the protocol avoids this possibility.
* Vectra Steam (QUX and RUX) and Recall (QUX only) are highly reliable options.

**Does Vectra add any proprietary data to Match log output in addition to what Suricata natively produces?**

* Yes, in addition to a Syslog producer header, as of Detect version 8.0, when the **Include enhanced detail** header is checked in your Syslog or Kafka configuration in Vectra, a new field called `vectra` in included that allows analysts to see HostID information and Sensor (device) information related to the Match that occurred.
* This will make it easier for analysts to understand which Sensor observed the traffic where the Match occurred and track the originating and responding host by its Vectra Host object.
* Vectra HostID is a proprietary process that takes into account network artifacts and other learned information to name hosts and track them more easily by this name rather than IP address which is often transient.
* Additional information included in the `vectra` field:
  * ```ckeditor_codeblock
    "vectra":{
        "orig_hostname": "Source Host",
        "orig_huid": "fakesrch",
        "orig_sluid": "fakesrcs",
        "resp_hostname": "Dest Host",
        "resp_huid": "fakedsth",
        "resp_sluid": "fakedsts",
        "sensor_uid": "sensory-",
        "sensor_name": "Cool Sensor"
        },
    ```

**Does Vectra have a Add-on and App for Splunk that supports Match log output?**

* For QUX see [Splunk SIEM / Vectra integration guide (start here for QUX)](https://docs.vectra.ai/configuration/response/siem/splunk-siem-vectra-integration-guide-start-here-for-qux) for more details.
  * The Technical Add-on and the App for Vectra Detect have been updated to support parsing Match log and provide a new dashboard for customers using Vectra Match with Splunk.
  * Please ensure you are using 1.3.0 or later of the Add-on and 1.4.0 or later of the Detect App.
* For RUX see [Splunk SIEM / Vectra integration guide (start here for RUX)](https://docs.vectra.ai/configuration/response/siem/splunk-siem-vectra-integration-guide-start-here-for-rux) for more details.

**How can I convert the Packet Data from the Alert log into PCAP format so I can view it in a tool like Wireshark?**

* Vectra Match will automatically record the packet payload associated with the detection in the Payload, Payload Printable, and Packet formats in the CEF/JSON based alerts. This information can be converted into PCAP using a tool like <https://idstools.readthedocs.io/en/latest/tools/eve2pcap.html> which will convert this information so it can be viewed in a tool like Wireshark.

## Role Permission Details

Two new permissions, each with **View** or **Edit** rights, have been created to support Vectra Match:

|                               |            |                                                                 |
| ----------------------------- | ---------- | --------------------------------------------------------------- |
| **Permission**                | **Rights** | **Allowed Capabilities**                                        |
| Manage – Vectra Match Ruleset | View       | Viewing ruleset assignments and information about ruleset files |
| Manage – Vectra Match Ruleset | Edit       | Uploading, assigning, or deleting rulesets                      |
| Settings – Vectra Match       | View       | Viewing enablement state of a Sensor, stats, and status         |
| Settings – Vectra Match       | Edit       | Enabling or disabling Match on a Sensor                         |

The below permissions and rights are the defaults included in your deployment:

|                                                                        |            |                                                                 |
| ---------------------------------------------------------------------- | ---------- | --------------------------------------------------------------- |
| **Predefined Roles**                                                   | **Rights** | **Permission**                                                  |
| admins, super\_admins, restricted\_admins, setting\_admins, read\_only | View       | <p>Manage – Vectra Match Ruleset<br>Settings – Vectra Match</p> |
| admins, super\_admins, restricted\_admins, setting\_admins             | Edit       | Manage – Vectra Match Ruleset                                   |
| admins, super\_admins, setting\_admins                                 | Edit       | Settings – Vectra Match                                         |

Customers who have created their own roles will need to make sure that the user associated with the API token they will use for Match is assigned to a role with the required permissions for the operations they want to perform.

## Licensing

**Do I need a license to run Vectra Match?**

* Yes, Vectra Match is a licensed feature. You need a license to be able to leverage it. Please contact your account team who can provide additional information.

**How is licensing enforced?**

* A valid license is required to:
  * Enable Match on a Sensor.
  * Download the Vectra Match Curated Ruleset
  * Upload ruleset files to the Brain.
  * Assign a ruleset file to a Sensor.

**What happens when the Vectra Match license expires?**

* Any enabled Sensors will continue to run Match with any existing ruleset that has been assigned to them.
* Match can be disabled on a device and ruleset assignments can also be deleted.

**How can I view the status of my license?**

* To check the status of your Vectra Match license, log in as the `vectra` user at the CLI of your Brain and issue the `show license` command. License status is also available in the Vectra UI at *Configuration > SETUP → Licensing*. Below is an example:

```ckeditor_codeblock
vscli > show license
License:
obfuscatedjogIjhFUG1ON1ZnNXNMOFVYajBDYUkzV1o3OEVKNlgxQkVvY3lleHZuTmRaZVN5WnNtcVA4ZldBUk5MQXZaRVF2TGU1Y29lWURtNnowVk1mRmlUQmZTZDVwRnZqT2QwWWUyQXMweEFMckpaTzVBNkVLcDRQbCs2a3FqMk9lR0FvQno3Tmp4MUhockdHTlRCODFoOE1ObkF4ck9FT0J5TkthTjlUQWtiN21sdCtGOEt3ZTF6RTBZQUZYdHJuQkM1c2RKMWpRY2tWekFTYTBITlVYYzobfuscatedajdlOVc2ai9GOVJwZFc3dFMwdkdmc1pCRnRWdkIzVk5NbjNHN2Q2Q3RsS0ErSUhFUVFEc1dRV0xzclRsSHFVNVNSR1hRMzZWbkI4VkJTdithbXpoSmpDSFJ3bFlEKzBMQzhmeDRIUnZEN2dzYmFOazdNeG5SUHAiLCAiYWVzX2tleSI6ICJiMUxiSXI1bWxGYmxWbjUxUVNGUXc2RUpNQVg2Uk1Jb0xPb1NvUkxaY21HWDZGNmZMUGY4a1dZcndncml0dGFCeU50ZzJ2Z0hYSG4robfuscatedttcWhpbnlQSnBRVGpXVVYrOXF3OTVuQldZWG82R3dTZC9sRDF3N0VNc05xWkpFaVB3cW00KzFOMWduRlppc0lZYnBwcVZ1Z1Jpb3ZZbyt2elh0RkJJYzhPSk1ic0JMcndBWllJSGkzUUE4Umd4ODNPaEgwZnJ2WG5VdUh3ZWlXK3grRDU2ZXI5YTRYbXc3R0tOamFWYStGSFlpWS9yQXlIOFREL2VuelhadGoxQlQ1SEIrdkM3Y0dET2JNSTlQbobfuscatedd2anZIbXpIV2dPcldCSC9SN0NwNXh6L0JXdmRGbHJuTWhMR0xNbHRNQ2RhdnM1VEdLWllGS0EvMkN6bU9uSy9pRGVsTVFSUXplQjJHTVVOTFg3Wjh2bllNMmQ4MzZEQnJnaDg4bThVMUMyVU0rY0NzM3lva1AxbFdzbkowNVZwb1pqSUk1T28ycmlmRHhqd2Z1VUZLQjVqMlJHMTZrbC8rNHJBM3RBNTROaTcvUUxJOGUrQ1ZmVllqVGVTeGRuR0tVeXRoSDobfuscatedM24rRHRLNmU0ZXhqbmVvYlpoT2ZmUTgzWFhvb0pXdWdDcWtJbGlxemEydk90UWFOdko2Vk1TVmt4VTg2a2RIQmVzUTEzQnlRZml0UkJJTDF3ZWVsRTdKNTR6UFJnbXhCobfuscatedd1c3blBUcmpHRDg5Q0g3LzNMVHRZOHAwbmIzcTlUYzlibzI2VFNYMzJqV3o1ekoyS25kRXhtUWQ4c0labjR6aG1zeTN3YkJ1U1pQcz0iLCAidGFnIjogInRUZVpraldUODFBWnRPQ3obfuscatedjZSI6ICJIUi9ZaERGobfuscated=:RktApxwRifPUBSwkn2ERc9uSSQY3t5wL8wnzmWgVdW16K+obfuscatedkGAgJ0itkVxP3RE/GiuUALyi/PGSIqoGHB6puJexc/PL70MLQCxd7f8igJQRdv95KQ9fkFNF+VGGEUM/eN4lj5dWtauVGNgKGrWwxdkXzTtAMzG6pU0lO548Tf28YYwwRKXfAqIu9aCvHotp/QbbuV3KD3g/C9CFYtLOuj/obfuscated==
Offline: False
Last Modified: 2023-03-09T02:42:37.989850
Detect:
    Valid: True,
    Valid Until: 9999-12-31T00:00:00+00:00
Match:
    Valid: True,
    Valid Until: 9999-12-31T00:00:00+00:00
Recall:
    Valid: True,
    Valid Until: 9999-12-31T00:00:00+00:00
Stream:
    Valid: True,
    Valid Until: 9999-12-31T00:00:00+00:00
```

* Once a license is 30 days from expiration, your Brain will being to send syslog messages in the **Audit logs** with a count down until expiration. Once the license expires a new syslog message is sent. Here are examples:

  ```ckeditor_codeblock
  "License Checker: Vectra Match License Expires in {days_until_expiration} days."
  "License Checker: Detected Invalid/Expired License, disabling services"
  ```

**How do I apply my license for new deployments or for license renewals?**

* Online systems (connected to the Vectra cloud)
  * License acquisition and renewal is an automated process that requires no user intervention.
* Offline systems (not connected to Vectra or air-gapped)
  * For details please see the [Vectra Match Deployment Guide's](https://docs.vectra.ai/deployment/match/deployment) Licensing and Deployment section.

## Suricata Configuration

**What version of Suricata does Vectra Match use?**

* Vectra Match uses the Suricata 7.0 release

**How does Vectra's Dropped IP Addresses (CIDR) list impact Vectra Match?**

* The Dropped IP Addresses (CIDR) setting that is available in your Brain UI at *Configuration → COVERAGE → Data Sources → Network → Brain Setup → IP Address Classification* does not impact Vectra Match. All traffic observed by your Sensor(s) will still be copied to Vectra Match.
* If you would like to ignore traffic in Vectra Match, you can use the **pass** or **bypass** Suricata rule features in your ruleset.

**What is the `Suricata.yaml` configuration that Vectra Match uses**

* Please see the [Vectra Match Suricata Configuration](https://docs.vectra.ai/deployment/match/suricata-configuration) article for details

**Can I modify the `Suricata.yaml`, `Thresholds.conf`, or `Classification.config` files?**

* Today, customers cannot modify these files, please contact your account team to share your use case.

**How does Vectra populate the HOME\_NET variable?**

* Vectra automatically populates the `HOME_NET` variable based on the configuration defined in the:
  * Internal IP Addresses (CIDR) - "Internal subnet"
    * Viewable in your Vectra UI at *Configuration → COVERAGE → Data Sources → Network → Brain Setup → IP Address Classification*&#x20;
  * Excluded Subnet of Internal IP Addresses (CIDR) - "Excluded subnet"
    * Viewable in your Vectra UI at *Configuration → COVERAGE → Data Sources → Network → Brain Setup → IP Address Classification*
  * Automatically discovered Southside Proxy IPs
    * Viewable at the CLI of your Brain with `show proxy --southside` command.
  * For Example:
    * If you have 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 as your Internal subnets
    * And 10.0.0.1, 10.0.0.2, 10.0.0.3 as Southside Proxy IP's,
    * And you've excluded 10.254.1.0/24 in the Excluded subnet,
    * The HOME\_NET variable would look like:
      * `[10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16,!PROXY_IPs,!EXCLUDE_NET]`
    * With `PROXY_IPs` being `[10.0.0.1, 10.0.0.2, 10.0.0.3]`
    * And `EXCLUDE_NET` would be `[10.254.1.0/24]`

**Does Vectra support setting other variables besides HOME\_NET?**

* In addition to the `HOME_NET` Variable, Vectra supports the following variables:
  * `EXTERNAL_NET` variable is `[!HOME_NET, PROXY_IPs, EXCLUDE_NET]`
  * `PROXY_IPs` is a list of IP's that are automatically added to the `PROXY_IPs` variable if detected by Vectra's Southside proxy detection.
    * Northside proxies are not factored in here.
    * This variable was introduced in 9.0 and enables users to automatically treat any traffic sent to Proxies as External even if they have an internal address.
    * You can view the list of Southside proxies on the Brain CLI using `show proxy --southside`
  * `EXCLUDE_NET`
    * The `EXCLUDE_NET` variable is automatically populated via the Excluded Subnet configuration under *Configuration → COVERAGE → Data Sources → Network → Brain Setup → IP Address Classification*
* Customers may use any of the supported Variables (`HOME_NET`, `PROXY_IPs`, `EXCLUDE_NET`, and `EXTERNAL_NET`) in your own rules.
* If you have further custom variables, you can always resolve them into the IP netblocks and use those in the rules instead, as this is all that Suricata does when a variable is in the `Suricata.yaml` file.

**What protocols can I use for sending Alerts to my SIEM/SOAR?**

* You can use TCP or SSL Syslog and Kafka. UDP is not supported due to the log size limitations
* For fomats, Vectra supports the standard syslog (Suricata Fast Log), CEF (Suricata EVE encoded into CEF format, and JSON (Suricata EVE).
* Vectra Match alerts can be sent by Stream, so all Stream protocols are also supported there including Elastic, Kafka, Raw JSON, and Syslog

**What protocols does Vectra Match support detection for?**

* L3/L4 Protocols: IPv4, IPv6, TCP, UDP, SCTP, ICMPv4, ICMPv6, GRE
* L7 Protocols: HTTP, HTTP/2, SSL, TLS, SMB, DCERPC, SMTP, FTP, SSH, DNS, Modbus, ENIP/CIP, DNP3, NFS, NTP, DHCP, KRB5, IKEv2, SIP, SNMP, RDP, RFB, MQTT

## Ruleset

**Where can I get a Suricata ruleset?**

* Starting in 8.5, Vectra is including a Vectra curated version of the Proofpoint ETPro ruleset. For more information please see [Vectra curated ruleset](https://docs.vectra.ai/deployment/match/vectra-curated-ruleset).

**How many rulesets can I assign to a single Sensor?**

* Multiple rulesets can be assigned per sensor, but Vectra recommends using only one at a time. You can assign different rule files to different Sensors. Please see the Vectra Match Deployment guide for additional ruleset management guidance.

**How can I manage my IDS ruleset?**

* Vectra supports managing rulesets and modifying rule thresholds natively in the UI. Vectra strongly recommends leveraging the UI to upload and manage rulesets.
  * Navigate to *Configuration → COVERAGE → Vectra Match* to manage rulesets within the UI.
  * Rule modifications made through the UI are automatically layered on top of the latest ruleset file so you no longer need to reapply them manually.
  * For additional details, please see [Managing Vectra Match Rulesets](https://docs.vectra.ai/deployment/match/managing-rulesets).
* For advanced use cases, customers can leverage tools like Suricata-Update, or tools and services like Lawmaker to manage their IDS ruleset. These files can then be uploaded to Vectra Match.
* For advanced use cases, Vectra has created a script that utilizes Match APIs to automate ruleset management.
  * The script is available here: <https://github.com/vectranetworks/vectra_match_workflow>
  * Feel free to use the script as is, or copy/fork it and make your own modifications.

**What ruleset IDs are supported in Match?**

* Rule IDs in a ruleset are required to be a positive 32-bit integer.
  * ET rules and the [Vectra Match Curated Ruleset](https://docs.vectra.ai/deployment/match/vectra-curated-ruleset) use IDs in the 1,000,000 to 2,999,999 range.
  * Rule IDs above 9,000,000 are reserved for Vectra use.
  * Customer IDs must be below 9,000,000.
  * Duplicate IDs should not be assigned to the same sensor, since the rule that will be loaded into Suricata will be arbitrarily chosen between the two.

**What file size limits exist for rule files?**

* You can upload up to a 200MB rule file, and a max of 25 different files can be applied to sensors.

**How can I tune the performance of my ruleset?**

* Please see the [Performance and Ruleset Optimization Guidance](https://docs.vectra.ai/deployment/match/performance-and-rulset-optimization) article for details.

**What happens if I upload an invalid signature?**

* Vectra Match will attempt to load the full ruleset file on the sensor. If there are any errors, Suricata will ignore the given signature but load the rest of the ruleset. The error for a given rule must be corrected before the given rule can be enabled.
  * You can see how many rules have been loaded and how many errors by using the Stats endpoint
    * `{{baseUrl}}/vectra-match/stats?device_serial={{device_serial}}`
  * ```ckeditor_codeblock
      "detect": {
                            "engines": [
                                {
                                    "id": 0,
                                    "last_reload": "2023-03-21T21:00:25.398717+0000",
                                    "rules_loaded": 31430,
                                    "rules_failed": 0
                                }
                            ],
    ```

**Can I run Suricata decoder event rules with Vectra Match?**

* Yes, you can run the decoder event rules which are part of Suricata (<https://github.com/OISF/suricata/blob/master/rules/decoder-events.rules>). You simply need to include them in your `.rules` file that you upload.

**Why do alerts forwarded and rate limited stats reset to 0?**

* In the Stats endpoint, certain stats are reset on system events like ruleset upload, enable/disable Vectra Match, or reboots; with the ruleset upload typically being the most frequent event.
  * ```ckeditor_codeblock
        "forwarder_stats": {
                    "events_processed": 1136,
                    "events_sent": 1136,
                    "alerts_dropped_for_rate_limit": 38,
                    "alerts_dropped_for_rate_limit_this_hour": 0
                },
    ```
  * In the above output the events are reset upon ruleset upload, enable/disable of Vectra Match and Reboots. `alerts_dropped_for_rate_limit_this_hour` is also reset hourly

If a rule file is pushed while a sensor is disconnected, will it get the rule file once it is reconnected?

* Yes, within 20 minutes of a system coming back online it should automatically receive the rules file which was pushed while it was offline. You can verify this by reviewing the `stats` endpoint for the last\_reload time.

## Performance

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

* If you 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](https://docs.vectra.ai/deployment/appliance-operations/resizing-virtual-appliances) .

**How does Vectra calculate the performance of Vectra Match**

* Please see the [Vectra Match Performance and Ruleset Optimization Guidance](https://docs.vectra.ai/deployment/match/performance-and-rulset-optimization) article for details.

**Does Vectra rate limit Suricata alerts?**

* Vectra does have reasonable limits to protect the Vectra platform from excessive alert rates to prevent downstream impacts of signatures that are not well optimized. When this occurs, you will receive an error message similar to the below via Syslog:
  * ```ckeditor_codeblock
    {"type": "match_health_checks", "source_ip": "127.0.0.1", "headend_addr": "192.168.52.151", "dvchost": "192.168.52.151", "version": "7.6", "result": "failure", "message": "Vectra Match is unhealthy on one or more paired devices", "vectra_timestamp": "1678809467"}
    ```
  * Please note that while this unhealthy status as a result of rate limiting is applied second by second, the unhealthy state is retained in a cache for 1 hour so that administrators who query the API will see that state and be aware of it. In versions prior to 7.8, this state was cached for 24 hours.
  * The unhealthy state will also be communicated via an alert email notification if **System** alerts are configured in *Configuration → RESPONSE* *→ Notifications*.
  * The unhealthy state will also be communicated via syslog or Kafka if **Vectra Match** logs are configured to be sent to your log receiver.
* Performing a GET against the status endpoint of the API for a device that is being rate limited would return as below:
  * ```ckeditor_codeblock
    GET {{baseUrl}}/vectra-match/status?device_serial=V421f68411bad268b6ead7c47f5ed4fed

    Example Response:

    {
        "status": [
            {
                "is_enabled": true,
                "process_health": "unhealthy",
                "device_serial": "V421f68411bad268b6ead7c47f5ed4fed",
                "timestamp": "2023-03-09T20:38:09.231989",
                "process_error_detail": "Excessive alerts rate limited in Vectra Match"
            }
        ]
    }
    ```
* The rate limits are performed on a second by second basis once the thresholds are exceeded. Check your logging system to see top hitting signatures to get a sense of which rules are triggering rapidly.
* The Status output from the API call above output can be cached, for the latest status, you can check the stats output at the bottom of the output to see if there are any rate limits or recent rate limits. Note that this does get reset upon rule uploads, enabling/disabling Vectra Match, or Sensor Reboots:
  * ```ckeditor_codeblock
      "forwarder_stats": {
                    "events_processed": 28,
                    "events_sent": 28,
                    "alerts_dropped_for_rate_limit": 0,
                    "alerts_dropped_for_rate_limit_this_hour": 0
                },
    ```
* Note that the **alerts suppressed** output of the Stats endpoint refers to alerts suppressed by the Suricata threshold/limit feature within rules, and not Vectra Match rate limiting. For instance if you use the Limit keyword: <https://suricata.readthedocs.io/en/suricata-6.0.0/rules/thresholding.html#type-limit> and alerts are limited by Suricata, then the `alerts suppressed` metric will increase, but not the `alerts_dropped_for_rate_limit` .

**Does Vectra Match inspect the full payloads or are any traffic skipped/bypassed?**

* Vectra Match processes the full payloads.

## Recall

**Does Recall support Vectra Match?**

* Starting in 7.9, Customers with Recall and Vectra Match enabled will automatically receive metadata from Vectra Match in the new metadata index `metadata-match`. For more information about the attributes in Vectra Match see [Vectra AI platform metadata](https://docs.vectra.ai/reference/metadata-attributes/vectra-ai-platform-network-metadata-attributes).

**Does the Recall data include the enhanced detail for Host and Sensor information that was added in v8.0?**

* Yes, Recall data in v8.0 and higher will automatically include the enhanced detail described in the **Does Vectra add any proprietary data to Match log output in addition to what Suricata natively produces?** entry from the [General](#General) section.

**Do I need to configure anything for Vectra Match alerts to show up in Recall?**

* Any metadata associated with Vectra match will automatically be published to Recall, there is no action required once Vectra Match is enabled with a valid license and ruleset.

**What Recall features are possible with Vectra Match?**

* Vectra Match in Recall will work just like any other metadata index including Discover searches, Dashboards, Saved Searches, Custom Models, Alerts, and Reports. Recall treats the Vectra Match as just another datasource.

**Are Recall Custom Models supported with Vectra Match? Are their any limitations or best practices?**

* Yes, [Recall Custom Models](https://docs.vectra.ai/operations/analyst-guidance/recall-custom-models-how-to-create-detections-qux) can be generated off of Vectra Match alerts. They are configured identically to any other Custom Model. Like traditional Custom Models, these are meant to be reserved for high value detections, and not for audit or informational behaviors.
* We recommend that customers are selective about which alerts qualify as a custom model to ensure that the volume does not trigger built in Custom Model rate limit protections on the platform.
* While any valid Recall query can be converted into a Custom Model, it is recommended that customers match on specific elements of alerts such as the Signature, Signature ID, or specific metadata fields of interest, rather than enabling detection on broad classes of signatures which may generate a high volume of custom models in a non-tuned ruleset.