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.

Introduction

This section of the QUX 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.

Configuration → COVERAGE

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

Custom Models

Custom Models enables you to create your own detections within the Vectra platform. They are built upon Vectra Recall saved searches. You must have a Vectra Recall subscription to use custom models. For more details please see:

• Recall custom models - how to create detections (QUX)

• Recall deployment guide

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 Suricata 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

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/rfc1918

    • 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.

set capture-network [ networks ] < ( internal | external | drop ) >
set capture-vlan < vlan > drop
show capture-networks
show capture-vlans

• 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 platform will be displayed in this area. Editing the settings in this area allows you to set a preferred update window for automatic updates from Vectra. Automatic updates require a connection to updates2.vectranetworks.com. This area will have additional functionality if you have been enabled for offline updates. Please note the following for air gap scenarios:

• Offline updates must be enabled for your deployment by contacting your Vectra account team or Vectra Support.

• Once enabled for offline updates a Manually update link will appear in this area.

• For additional information about performing manual (offline) updates, please see offline updates.

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.

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).

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:

• Microsoft Defender ATP (Endpoint)

• Carbon Black Response

• Carbon Black Cloud

• FireEye Endpoint Security (HX)

• SentinelOne

• Cybereason

• Crowdstrike

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

Recall

This settings area allows you to see the state of a Vectra Recall license, turn on or off forwarding to Recall, recall collector and Kibana endpoints, and the health status of Recall.

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

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:

• AWS Brain Deployment Guide

• AWS vSensor Deployment Guide

• AWS HostID integration

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:

• Azure Brain Deployment Guide

• Azure vSensor Deployment Guide

• Azure HostID integration

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:

• GCP Brain Deployment Guide

• GCP vSensor Deployment Guide

• GCP HostID integration

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:

• VMware Brain Deployment Guide

• VMware vSensor Deployment Guide

• How to configure vCenter Integration on Vectra Detect Appliances

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.

Configuration → SETUP → General Settings

Account Lockout (Local Users)

This setting allows you to enable and disable account lockout for local users. The maximum login failures allowed and lockout duration can also be configured.

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.

In-App Support

This setting allows you disable or enable In-App Support. In-App Support provides connected content to customers such as guided tours, links to articles, etc. It also provides anonymized usability data back to Vectra to help inform our development efforts for new features or gauge the success or usability of existing features.

Inactive User Logout

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

Login Caption

This setting allows you to configure a login caption that displays below the login box.

Share Metadata with Vectra

Metadata Sharing Improves Threat Detection

• By contributing anonymized metadata sourced from your Brain appliance, you are contributing directly to the efficacy and accuracy of the Vectra software and the security of your network.

• Access to Detection metadata improves Vectra’s threat detection algorithms, enabling the Vectra software you use to be more effective in a constantly evolving threat landscape.

• For more details, please see Why is metadata sharing important.

Timezone

This setting allows you to configure the time zone used in your Quadrant UX deployment.

Instance Name

This allows. you to configure an instance name for your QUX deployment that you may see in various parts of the UI.

User Password Policy

This setting allows you to configure the minimum required password length and whether or not passwords will expire.

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

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).

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.

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

Notifications

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

AWS CloudWatch

In this area you can configure AWS CloudWatch for publishing of health and audit logs to Amazon CloudWatch. Please see the AWS Brain deployment guide for details.

AWS Security Hub

In this area you can configure AWS Security Hub integration for publishing of hosts scores involving AWS workloads in AWS Security Findings Format (ASFF) to the AWS Security Hub service. Please see the AWS Brain Deployment Guide for details.

You can also configure alert and digest emails. Finally, you can configure syslog or Kafka output for log data.

SMTP

This area enables you to configure the settings for an SMTP connector to send alerts from your Vectra platform deployment. This must be setup before you are able to configure Alert or Digest Emails. Full details are available in the following KB:

• How do I configure SMTP on a Brain? (Quadrant UX)

Once you have saved your STMP settings, a “Test” link will appear under the edit button. Click this to see if the settings work and also check your email folder. If you do not get an error on the Vectra side and still do not receive your email, check you spam folder and adjust your spam filter settings to allow the message.

Email Alerts

Alert emails can be sent to email addresses or aliases. Enter the desired recipients in the top box. Alert types:

• Send campaign alerts

  • Attack Campaigns are formed when there is at least one active advanced command & control Detection, and several other hosts are observed to be communicating with the same domain or IP address.

  • These alerts are sent when a Campaign is created or closed.

• Send host alerts

  • These alerts are sent when a host crosses the scoring threshold that is configured.

  • Alerts are also sent when there is a Detection on a Host that is marked as a “Key Asset”. This alert does not rely on a threshold, only that the host is a “Key Asset” and has a new Detection.

  • The Threat and Certainty thresholds are configurable.

  • You may also choose to require that thresholds both be crossed or either crossed by clicking on blue pill between the thresholds thus selecting the “and” or “or” option.

• Send account alerts

  • These alerts are sent when an account crosses the scoring threshold that is configured.

  • Alerts are also sent when there is a Detection on an account that involves a Host that is marked as a “Key Asset”. This alert does not rely on a threshold, only that a host in the Detection details of the Account based Detection is a “Key Asset” and has a new Detection.

  • The Threat and Certainty thresholds are configurable.

  • You may also choose to require that thresholds both be crossed or either crossed by clicking on blue pill between the thresholds thus selecting the “and” or “or” option.

• Send detection alerts

  • These alerts are sent when any selected Detection scores above the configured certainty threshold.

  • For many customers, Host or Account scoring will drive prioritization for investigation by analysts.

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

• Send 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.

• Send 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)

Digest Emails

This setting may be deprecated in a future release. It allows you to enable or disable a daily digest of detection counts (by category) in the last 24 hours.

Kafka

This setting allows you to configured sending syslog to Kafka. What is sent is ssentially the same as for Syslog below but the transport and topic details can be configured for Kafka. For details please see the following articles:

• Syslog sending to Kafka

• Syslog and Kafka message size limits

Syslog

Administrators can configure their QUX deployment to send host and Account scoring information, detection details, campaign details, and audit logs over syslog to external collectors for storage and analysis.

• Syslog guide (QUX)

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:

• Active Directory (AD) Groups

• Dynamic Groups FAQ

AI Triage

AI-Triage can be enabled and disable here. AI-Triage automatically triages some detections and enhances signal to noise ratio for analysts. It is a best practice to leave this enabled. For details please see AI-Triage in detail.

Configuration → ACCESS

API Clients

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

Please see API (QUX) for all guides (including older API versions) related to the REST API for QUX. v2.5 guides are linked here:

• v2.5 Postman quick start guide using OAuth2

• v2.5 Postman quick start guide using token auth

• v2.5 API guide (QUX)

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:

• SAML with any IdP (QUX)

• SAML for ADFS (QUX)

• SAML for Entra ID (Azure AD) (QUX)

• SAML for Okta (QUX)

• SAML for Ping Identity (QUX)

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.