search

Initial configuration

Guidance for configuring settings in the "Configuration" menu in the Vectra UI after the initial deployment is complete for Respond UX and your data sources are connected.

hashtag
Introduction

This section of the RUX deployment guide provides guidance for configuring settings in the Configuration menu in the Vectra UI after initial deployment. It is arranged by areas shown in your UI and has guidance and links for deeper guidance when required.

hashtag
Configuration → COVERAGE

Contains configuration options related to specific data sources, threat feeds, and Vectra Match.

Data Sources

Add coverage for new or existing network, cloud, and identity data sources to your Vectra deployment. For non-network data sources, each data source selected will present a welcome page with links to documentation.

Threat Feeds

Allows configuration of 3rd party threat intelligence feeds in STIX format. For details, please see linked documentation at: Threat Intel Integration Setup

Vectra Threat Intelligence is a set of threat intelligence feeds that is managed and curated by Vectra. It is available as an included part of your Vectra NDR (Detect for Network) license. See the linked documentation for details.

Vectra Match

Vectra Match utilizes the open source Suricataarrow-up-right IDS engine. Vectra’s Sensors (network data sources) are extremely high performance and adept at producing the proprietary metadata required to supply the AI-based behavioral models utilized by Vectra NDR. Match enables these same Sensors to also run a Suricata engine that is fed by the same capture buffers that feed the existing data processing pipeline.

For details, please see the Vectra Match Deployment Guide

hashtag
Data Sources → Network → Brain Setup

This area contains settings that are specific to your Vectra Brain appliance. The full path for items in this section is Configuration → COVERAGE → Data Sources → Network → Brain Setup.

Brain

This area of the GUI displays various Brain specific settings and information, and also has Restart and Shut Down links.

  • DNS Name

    • FQDN (Fully Qualified Domain Name) that can be used to pair Sensors and/or Stream to this Brain.

    • To use this value for pairing, change the pairing setting under Configuration → COVERAGE → Data Sources → Network → Sensors → Sensor Configuration → Sensor Pairing and Registration to DNS Name.

      • Additional guidance for pairing via IP or DNS is covered later in this document.

    • In general, it is recommended to configure your DNS with a proper hostname for the Brain.

  • Alias

    • The label for this Brain within various areas of the Vectra AI platform.

  • For linking in alerts/notifications (except AWS SecurityHub):

    • Choose either DNS Name or Management IP Address.

    • This will determine the format of links in alerts/notifications.

CLI Access Controls

This settings area becomes visible and replaces the CLI Password (Brain) setting if you have the feature flag for the new SSH Login to CLI feature enabled in your deployment. This feature is currently in private preview and is planned to become generally available in a future release.

This area controls the password for the vectra user and allows you to disable this user entirely if desired. You can also control the SSH token (OTP) timeout value that non vectra users are subject to when they log in to the CLI of Vectra appliances. As linked article, users must have the SSH Login to CLI permission mapped to their assigned role to be able to login to any appliance CLI.

CLI Password (Brain)

This setting is replaced by CLI Access Controls when the feature flag for SSH Login to CLI is enabled in your Brain. This feature is currently in private preview and is planned to become generally available in a future release.

This setting allows you to set the password for the vectra user used to access the CLI of the Brain via SSH.

  • Please note that accessing the CLI of a Brain deployed in an IaaS cloud requires authentication of SSH using the private key corresponding to the public key that was provided during deployment.

  • Physical appliances and virtual Brains can authenticate using password.

DNS Entries

These DNS settings apply to the Brain only. Sensor DNS is set individually at the CLI or via a configuration string when deploying vSensors using the command line from the Brain.

  • If you have not already configured DNS for the Brain at the CLI, please do so in this section of the UI.

  • It is also highly recommended to enable Reverse DNS Lookup to improve host identification and context.

    • This is done by checking the checkbox in this area.

IP Address Classification

For proper algorithm operation and recognition of traffic directionality within Stream or Investigate metadata it is mandatory to accurately identify internal vs external IP space. By default, all RFC-1918 IP space is considered internal.

Additionally, Vectra NDR AI detection models do not analyze connections that originate from external IP space. Return traffic for connections that originated internally to external entities is analyzed. Metadata is still produced for Stream and Investigate functionality, and Match still processes externally originated connections through the underlying Suricata engine.

Please see the below for details on how each of the IP address classification settings will affect the system.

  • RFC-1918 (Address Allocation for Private Internets) IP space

    • This is just a reminder about the networks that are reserved for internal use in RFC1918

    • https://tools.ietf.org/html/rfc1918arrow-up-right

      • 10.0.0.0 - 10.255.255.255 (10/8 prefix)

      • 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)

      • 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

      • fd00::/8 (IPv6)

  • Internal IP Addresses (CIDR)

    • IP addresses or CIDR blocks entered here will be considered internal to your network.

    • Everything else will be considered external.

  • Exclude a Subset of Internal IP Addresses (CIDR)

    • Use this area if you have a subset of internal IP addresses listed above that you want to be considered as external to your network.

    • For example, if you were going to simulate Command and Control behavior from an internal lab, you should configure the lab IP space as external (by adding it to this section). This allows Detect models properly identify the behavior.

  • Drop IP Addresses (CIDR)

    • IP addresses or CIDR blocks entered here will be ignored.

    • Any traffic to or from these addresses will not be analyzed by NDR AI models by your system.

    • Ignoring traffic by VLAN is supported at the CLI using the set capture-vlan command.

  • Drop and Exclude Subnet Scenario Examples

    • 10.10.0.0/16 set as Exclude, 10.10.50.0/24 and 10.10.70.0/23 set as Internal, Exclude setting will take precedence and both smaller subnets will be considered as Exclude.

    • Similarly, if 10.10.0.0/16 was set as Drop and the others external, the result would be Drop for all.

  • CLI Options for Setting Internal, Exclude, Drop

    • After logging into the CLI of your Brain, include, exclude, and drop networks/vlans can be configured by the below CLI commands.

    • The commands also have help that can be shown with the --help argument.

  • Internal VPN IP Addresses (CIDR)

    • Enter any IP ranges allocated to your VPN servers for remote end-user connections.

    • This will improve identification and detection model coverage for hosts connecting in via VPN by altering some characteristics of underlying models.

    • For more details on optimizing your system for use with VPN clients, please follow the link.

  • Static IP Addresses (CIDR)

    • In many customer environments, Vectra’s automated Host Identification (Host ID) is all that is required for customers to have all the pertinent hosts in their environment named and tracked. Generic hosts (IP-x.x.x.x) will inevitably be observed when a host first comes into the environment, but not enough artifacts have been observed to create a stable named host object or attribute its traffic to a previously created host. This can commonly happen when a user plugs in a laptop for the day, but the host is not recognized immediately. Vectra manages this on its own and will attribute traffic for this generic host to the named real host object once it is recognized.

    • Many customers also have statically assigned hosts and may not have hostnames in customer DNS. Additionally, Vectra may not directly observe enough artifacts of other types to name the host. If a stable host object never gets created, learning for several models cannot be anchored to generic hosts. This means that some Detections cannot fire and features such as the Host Role cannot function on these generic hosts.

    • Enter IP addresses or CIDR blocks representing the statically assigned hosts in your environment in this area.

    • Hosts on these IPs or ranges will show as STATIC-x.x.x.x in the Vectra UI and will no longer be generic hosts.

    • These hosts will have full support for learning and all Detections and features.

    • Statically defined hosts will not change name based on observed artifacts - they will remain static until they are no longer configured as such.

    • You are free to rename statically assigned hosts as you wish.

NTP Entries

Vectra provides defaults but please set your preferred time synchronization sources (up to 5) here.

PCAP Generation

PCAPs provide great value to analysts in a number of scenarios. PCAPs are assembled from the Sensor’s rolling capture buffer upon request from the Brain during the publishing of Detection alerts. In some circumstances, customers may not want to have PCAPs generated at all, or from certain Sensors that may be deployed in areas with stricter privacy controls that don’t allow for PCAP.

  • Edit in this area to turn off PCAP generation entirely.

  • To turn off PCAP generation on an individual Sensor go to Configuration → Data Sources → Network → Sensors → Network Sensors, select the Sensor you wish to edit, click the edit pencil, and then deselect the Capture PCAPs for this Sensor checkbox and Save your setting.

Proxy & Status

Edit this area to add or change proxy settings if required for your environment to be able to connect to endpoints needed in the firewall requirements. Also shows the status of connections.

  • Please note that if you see green checkmarks for both the Statistics Destination and the Updater Destination, even if a warning stating No proxy configured is displayed, you do not need to setup a proxy for your platform.

  • Proxy settings can also be viewed and configured at the CLI using the show proxy and set proxy commands at the CLI of your Brain appliance.

  • For details on how Vectra works with proxies in your environment from a traffic capture/analysis standpoint as it relates to detections, please see proxy handling in Vectra.

    • You can manage the northside proxy list under Configuration → SETUP → Proxies.

Version

Information about the version of your Vectra cloud platform will be displayed in this area.

hashtag
Data Sources → Network → Sensors

The full path for items in this area is Configuration → COVERAGE → Data Sources → Network → Sensors. In this area you can pair and manage network sensors, configure a number of options related to Sensor pairing and registration, and change the password for paired devices (Sensors or Stream).

Network Sensors

Sensor management and pairing is accomplished in this area. For details on pairing, please see pairing appliances. Below is some detail that is also covered in more detail in the linked guide for pairing appliances.

Sensor Configuration → Sensor Pairing and Registration

Editing this area will allow you to alter the default way a Sensor will attempt to pair with a Vectra Brain and allow you to enable or disable Virtual Sensor Automatic Pairing. Additionally, this area provides a link to generate a new Sensor Registration Token

  • Pair using the Detect Brain

    • If you have a DNS name configured in Configuration → COVERAGE → Data Sources → Network → Brain Setup → Brain, then the Pair using the Detect brain area will provide a choice between the configured DNS name and the Management IP (MGT1).

    • If you do not have a DNS name configured, there will only be one option present using the configured IP.

      • It may take a few minutes after adding a DNS name in your Brain setup for the choice to appear in this area.

    • Pairing via the Brain DNS Name makes Brain replacement or IP Address change events easier to manage.

    • This setting only affects the default pairing mode for Sensors used in future pairing operations.

      • Any previously paired devices will remain paired regardless of how they were paired.

      • Regardless of setting, the set brain command available at the CLI of the Sensor will allow you to attempt pairing via hostname or IP.

    • Should you choose to change the pairing method for previously paired devices, you will need to unpair the previously paired devices and re-pair them.

  • Virtual Sensor Automatic Pairing

    • This setting allows you to choose if you want to automatically pair (auto pairing) with Sensors that have a valid Sensor Registration Token (SRT) configured.

      • Even though the setting name implies that this will only impact virtual Sensors, any Sensor, including physical appliances can auto pair if a valid SRT is configured when pairing is attempted.

    • It is recommended to allow auto pairing during initial setup or during large Sensor rollouts.

    • When you are done deploying vSensors, you may turn this off to enhance security posture.

  • Sensor Registration Token

    • This is used to validate devices attempting to register to this Brain and resets after 24 hours.

    • It is required in the Registration Token field in the Sensor deployment template for cloud Sensors.

    • While the Sensor Registration Token (SRT) is required for cloud Sensor deployment, it is optional for physical Sensors and virtual Sensors.

    • Use of the SRT will allow you to pair a Sensor with any Brain in your organization. This can be useful for disaster recovery scenarios where a device may have been paired to another Brain previously.

    • After a Sensor registers with this Brain, it will appear in the Sensor list in Configuration → COVERAGE → Data Sources → Network → Sensors where its pairing can be managed.

    • Stream devices will show paring status in Configuration → Setup → Stream → Pairing Status.

Sensor Configuration → CLI Password (Sensors)

In this area you can change the password for all paired Sensor or Stream appliances to easily keep passwords in sync.

  • If you require separate passwords for each Sensor or Stream appliance, the password for the vectra user may be changed individually using the set password command at the CLI of your Sensor.

  • Please see SSH login process for CLI for more details.

hashtag
Data Sources → Network → Remote Users

The full path for this is Configuration → COVERAGE → Data Sources → Network → Remote Users. In this area you can configure Vectra’s vendor specific SASE/SSE integrations and IP pools to be used for remapping of remote users IP addresses that might otherwise conflict with IP address ranges used in corporate networks observed directly by Vectra network sensors.

Please see the externally linked SASE/SSE Deployment Guide Links article for details and links to deployment guides for supported SASE/SSE vendors. Zscaler ZIA packet capture and Netskope Cloud Tap can be configured to provide network traffic to Vectra Sensors for remote user traffic that does not typically traverse other network Sensors deployed in your environment.

hashtag
Data Sources → Network → Network Identities

The full path for this is Configuration → COVERAGE → Data Sources → Network → Network Identities. In this area you can configure Windows Event Log Ingestion (WELI). WELI is an option available for Vectra NDR (Detect for Network) that helps with coverage by ingesting specific Kerberos messages in Windows event logs. Account and Host detections can fire as a result of this integration without having to have observed the actual network traffic associated with the Host or Account. Please see linked documentation at: Windows Event Log Ingestion (WELI).

hashtag
Configuration → SETUP

This area contains configuration settings that typically need to be configured one time during initial deployment or when new integration points are added to your environment and you want to configure Vectra to work with them.

Account Association

When using CDR for M365 & IDR for Azure AD, this area will allow you to manually map network realms to cloud domains. We recommend using automatic mapping by linking your Active Directory instance to your Vectra Brain, as this will link more robustly and with a greater success rate than manual mapping.

EDR Integrations

Configuring EDR integrations is considered a best practice if you have a supported EDR. It will enable Host Lockdown and provide added context to analysts for hosts running the EDR along with links to the EDR .

Please see linked documentation for these EDR integrations for details:

Licensing

See license status and perform license activation operations when required in this area.

Metadata

This setting allows you to configure behavior for connection state logging. This impacts the detail level of the conn_state field shown in Advanced Investigation / Stream metadata. You can also control the volume of DNS metadata generated by logging or not logging DNS metadata only when a reply is observed in response to a request.

Proxies

Editing the configuration in this area allows you to manage automatically identified northside proxies in your environment. Identified southside proxies are not configurable but the list is viewable at the CLI of your Brain appliance. For details please see linked documentation at: Proxy handling in Vectra

Stream

Vectra Stream delivers security-enriched metadata to a data lake or SIEM of the customer’s choice. If licensed for Stream, you can configure Stream settings in this area. For details please see linked documentation at: Stream Deployment Guide

hashtag
Configuration → SETUP → External Connectors

External connectors add context enrichment to the Vectra AI Platform. For example, adding Active Directory as an external connector will:

  • Add host and account details retrieved from Active Directory to your host and account details pages.

  • Enable Active Directory Account Lockdown as a response option.

  • Enable Vectra to automatically map cloud domains to network realms so that Vectra can associate cloud and network accounts.

Active Directory

Linked documentation available at: Configuring Active Directory(AD) integration with Vectra NDR

AWS

This integration enables your Vectra deployment to add relevant context (host ID, OS, instance ID, tags, etc) about Amazon EC2 hosts when observed by Vectra. For configuration details please see either:

Azure

This integration enables your Vectra deployment to add relevant context (host ID, resource group, admin username, etc) about Azure VMs when observed by Vectra. For configuration details please see either:

Google Cloud

This integration enables your Vectra deployment to add relevant context (host ID, project, link to vm, etc) about GCP VMs when observed by Vectra. For configuration details please see either:

Reverse DNS Lookup

Configuring DNS servers for your Brain appliance is required and enabling reverse DNS lookup is a best practice. Reverse DNS lookup is especially helpful for HostID naming processes. For configuration details, please see linked documentation at: Configuring DNS servers on Vectra appliances

SIEM

Configuring here enables your Vectra Brain appliance to listen for events forwarded from SIEMs or other systems that can send DHCP log data in Infoblox and other ISC standard syslog formats. This is useful to help feed Vectra HostID (automated host naming). For configuration details, please see linked documentation at: Event Forwarding Reference Guide

vCenter

Configuring vCenter integration allows your Vectra deployment to query VMware vCenter and enable the _Network Stats → Virtual Infrastructure_view. It also feeds Vectra HostID with artifacts that help automated identification of hosts in your VMware environment. For details, please linked documentation at:

Zscaler Private Access (ZPA)

Configuring ZPA integration allows your Vectra deployment to map traffic seen by your Vectra network sensors between Zscaler App Connectors and endpoints in your internal environment to the original ZPA user/host. For details, please see linked documentation at: Zscaler Private Access (ZPA) Log Ingestion Configuration

hashtag
Configuration → SETUP → General Settings

Auto-Refresh Threat Dashboard

This setting determines if the Discover → Threat Surface → Threat Summary Dashboard auto-refreshes itself every 10 min. This might be useful in a SOC if a monitor is dedicated for displaying this dashboard.

Inactive User Timeout

Configure up to a 12-hour limit before externally authenticated users must re-authenticate to access UI.

Timezone

Configure the Timezone for your Vectra deployment.

New Close Workflow

Enabling the New Close Workflow should be enabled in all new deployments. The reason it is configurable is that some existing customers were older methods for closing assignments, and filtering or closing individual detections. For details, please see linked documentation at: New Close Workflow

hashtag
Configuration → RESPONSE

In this area you can response options such as Lockdown across a wide variety of options and configure notification settings such as email alerts and external app alerts (webhook notifications).

hashtag
Lockdown

The full path for items in this area is Configuration → RESPONSE → Lockdown.

Active Directory Account Lockdown

Account Lockdown enables analysts to temporarily disable network accounts during a security investigation. Please see linked documentation at: Active Directory Account Lockdown. Please note that at least one AD must be integrated at Configuration → SETUP → External Connectors → Active Directory for Active Directory Account Lockdown to function.

Azure AD (Entra ID) Account Lockdown

AAD Account Lockdown enables analysts to disable or revoke the session of malicious Azure AD and M365 accounts during a security investigation. Please see linked documentation at: Azure AD (Entra ID) Account Lockdown FAQ (Respond UX)

Host Lockdown

Host Lockdown enables analysts to temporarily disable network hosts during a security investigation. Host Lockdown is enforced through the use of an integrated EDR's host isolation capabilities. Please see linked documentation at: EDR Host Lockdown Information. Please note that at least one EDR must be integrated at Configuration → SETUP → EDR Integrations for Host Lockdown to function.

Traffic Lockdown

Traffic Lockdown is a network-level containment feature that enables Vectra to automatically add compromised host IP addresses to an external blocklist that your firewalls can subscribe to. When a host is added to Traffic Lockdown (manually or automatically), its IP address is published to a plain-text threat feed that integrated firewall devices poll and use to block traffic from that host. Please see linked documentation at: Traffic Lockdown

hashtag
Notifications

The full path for items in this area is Configuration → RESPONSE → Notifications.

Email Alerts

Alert emails can be sent to email addresses or aliases. Alert types:

  • Entity alerts

    • These alerts are sent when an entity (host or account) crosses the configured scoring threshold.

    • The Urgency Score Threshold is configurable and is set independently from the Prioritization Threshold that you may have set under Configuration → TUNING → Prioritization Threshold.

  • Detection alerts

    • These alerts are sent when any selected Detection occurs.

    • Some customers may want Detection alerts for specific Detections that they consider critical, such as Ransomware, regardless of the current Entity score.

  • System alerts

    • Alerts related to system operations are sent.

    • Examples are when there is a change in Sensor connectivity, capture interface health, or disk health.

  • vCenter alerts

    • Alert related to changes in vCenter, such as new physical hosts being spun up that do not have vSensor coverage.

    • This requires vCenter integration to be setup.

External App Alerts

External App Alerts enable Vectra to deliver real-time notifications to external collaboration tools when critical events occur — such as hosts or accounts crossing prioritization thresholds or system alerts being triggered. For details please see linked documentation at: External App Alerts (webhook notifications)

hashtag
Configuration → TUNING

Triage Filters

Triage enables teams to manage known, expected, or previously reviewed detection behaviors in a structured and auditable way. By creating targeted filters, security teams ensure the platform reflects what truly matters, improving the precision of scoring and prioritization without suppressing visibility or requiring manual alert review. For details, please see linked documentation at: Triage Best Practices

Groups

Consistent use of groups helps ease triage filter creation and maintenance. For example, rather than building a set of conditions for authorized domains in several triage filters, it is much easier to simply create a group that can be used as often as required. Also, when group membership changes, you only need to update the group and not every filter that would have used the same members as individual conditions. For additional details please see:

Prioritization Threshold

Editing the prioritization threshold allows customization of the minimum score required for a host or account to be considered prioritized. For additional details see linked documentation at: AI-driven Prioritization FAQ

hashtag
Configuration → ACCESS

API Clients

Add and see the status of API clients for accessing the REST API of your Vectra Respond UX deployment.

Users

Add new users, see their status, and edit or delete settings for local users in your deployment. SAML users can also be seen here but SAML users are not added using the Create New User process. SAML users are controlled by the IdP that is integrated with Vectra. Please see External Authentication below for links to SAML integration guides.

Roles

See and manage the permissions for roles that are assigned to both local and external (SAML) users for your deployment. Roles can be edited and the default permissions assigned to each role can be modified.

External Authentication

Allows configuration of external authentication options for login to Vectra. SAML is the only supported option today. For integration guides please see:

Remote Support

This is optional and allows Vectra Support access to the Brain command line shell for remote support, debugging, address potential performance problems, verify software updates, and perform troubleshooting.

  • Utilizes Open VPN on TCP:443 and UDP:9970.

  • Access to the shell is two factor secured, requires a support ticket to be logged, and is audited.

  • Please note that this can be toggled on and off as required if you would prefer to not leave it enabled.

For additional detail, please see Vectra Remote Support.

PreviousDeploymentNextConfiguring data sources

Last updated

Was this helpful?