Azure HostID integration
Introduction
To enable efficient investigation of cloud hosts, the Vectra NDR can be configured to periodically query the API offered by the Azure Resource Manager to gather additional information about hosts running in Azure. This information contributes to Vectra’s automated Host identification (Host ID) and adds information to the Host entity details screen.
It is a best practice is to enable this integration. Vectra NDR attributes detections to a Host or an Account. For some algorithms that support learning, detections must be attributable to a Host (including statically defined hosts), rather than a generic Host container (denoted by IP-x.x.x.x in the Vectra UI). Enabling this integration can help contribute to more complete detection as a result.
Please see this example screenshot (Quadrant UX) below of a host in Azure where additional context was pulled through API calls:
As you can see, the integration provided the following (viewable by drilling down to the Host and then the Details tab):
Host ID artifacts including a unique identifier and hostname
Resource group, Admin, NICs, and Last Seen date/time
Summary information on the left-hand side including OS, Host Name, and Location
Requirements
Creating an Azure AD application and service principal that can read Azure management APIs is required. At minimum, read access to the following endpoints of the Azure resource manager will be required:
https://management.azure.com/subscriptions
https://management.azure.com/subscriptions/SUBSCRIPTION/providers/Microsoft.Network/networkInterfaces
https://management.azure.com/subscriptions/SUBSCRIPTION/providers/Microsoft.Compute/virtualMachines
https://management.azure.com/subscriptions/SUBSCRIPTION/providers/Microsoft.Compute/virtualMachineScaleSets
An alternative is to provide the Vectra Brain permissions to query the following APIs (this is a wider scope):
Microsoft.Network//readMicrosoft.Compute//read
The simplest way to accomplish this is to apply the built-in Azure Reader role to the application. This will allow your Vectra Brain to view all resources but does not allow it to make any changes.
Once created, you will then enter the Application (client) ID, Directory (tenant) ID, and Application Secret value into the Vectra UI to enable the integration. Multiple credential sets can be added if required.
Configuration Example
Resources
Full instructions for creating Azure AD application and service principal are available from Microsoft here:
Details regarding Azure built-in roles are available from Microsoft here:
Azure Steps
To enable this functionality, the following steps need to be completed for every Azure subscription where there are Sensors deployed. In this example we will apply the “Reader” role at the Azure Subscription level.
After signing in to the Azure AD portal, navigate to Azure Active Directory > App registrations and select New registration.
Give the application a Name of your choosing and choose a supported account type.
A Redirect URI is not required.
Click Register and then copy the Application (client) ID and Directory (tenant) ID for later use:
Now we will assign an Azure role to the application.
In the Azure portal select Subscriptions and select which subscription to apply the role to by clicking on it.
Select Access control (IAM), then click + Add, and then click Add role assignment.
Select Reader under Role.
Leave Assign access to unchanged (it should say User, group, or service principal)
Search for your application and select it.
Click Save.
Next we will create a new application secret.
In the Azure AD portal, navigate to App registrations and select your application.
Select Certificates & secrets, click + New client secret, enter a Description and select and when you want this to expire:
Click Add.
Once created, you must copy the Value before navigating away from this screen as you cannot retrieve it later.
Vectra Steps
To complete the integration, in the Vectra UI, browse to Configuration > SETUP > External Connectors.
Click on the pencil or Edit link for Azure.
Toggle the integration to On and fill in the Application (client) ID, Directory (tenant) ID, and Application secret values that you created above:
Click Save. Multiple sets of credentials can be configured if required for different subscriptions.
The connection will best tested and if successful, you will see a green checkmark showing that Azure Resource Manager integration has been completed.
Viewing and Modifying Virtual Networks Considered by the Connector
The connector will only look at virtual machines or virtual machine scale sets that belong to some virtual networks, not necessarily all virtual networks that the credentials have access to. Specifically, by default, the connector will only look for virtual machines with network interfaces in the virtual networks where a Vectra Azure vSensor traffic/capture interface is deployed into, and all the virtual networks with a "double peering" to it (if the Sensor traffic interface lives in virtual network A, and virtual network A is peered with virtual network B and C, but only virtual network B is peered with virtual network A, then the connector will look for virtual machines in virtual networks A and B only). If a virtual machine has multiple network interfaces, the connector will provide host identification only for the IP addresses belonging to interfaces on monitored virtual networks.
Vectra limits the scope of the connector to only virtual networks that can reach an Azure vSensor for the following reasons:
Vectra wants to avoid an excessive number of connections to the Azure resource manager.
To improve performance, Vectra wants to avoid storing unnecessary information in the platform for resources that we are not monitoring.
In the cloud it is possible that you may have some isolated virtual networks that are not monitored by Vectra Sensors but have overlapping IP space with some other networks that are monitored. Duplicate IPs are not supported by Vectra. To avoid Host ID issues, we only consider virtual machines on the networks that appear reachable by our Sensors.
If you want to add or remove some virtual networks from the set of virtual networks that Vectra monitors, you can do so through the CLI (ssh to the Brain as the “vectra” user). This functionality is not available in the Vectra UI. The use case for adding or removing virtual networks could be the following:
If you have some tunneling or forwarding enabled and Vectra Azure vSensors see traffic from virtual networks that are NOT directly connected to our vSensor:
You will want to add the networks to the monitored networks list to extend Host ID coverage to the tunneled/forwarded traffic’s associated Hosts.
If you do NOT have any Azure vSensors deployed, but mirror Azure traffic into your data center where you have Vectra physical or virtual Sensor coverage:
You will want to add the networks to the monitored networks list to extend Host ID coverage to the mirrored traffic.
If you do have some overlapping IP space on a network that appears reachable by our vSensor, but that it is not monitored by our vSensor:
You will want to remove the overlapping networks from the monitored networks to avoid any Host ID issues.
If you have a lot of peered networks but only some are monitored by the vSensor:
You will want to remove the non-monitored networks from the monitored networks list to increase performance and reduce load on the Azure resource manager.
The command to add or remove virtual network from the Vectra CLI is "set azure vnets". The command has a very helpful help message illustrating its use:
The command show azure vnets will show the virtual networks configuration, including the whitelist (networks to ADD), the blacklist (networks to REMOVE), the Sensors network, and finally the overall monitored networks, which is simply computed as ((Sensors networks + peered) + whitelist) - blacklist. It may take up to 10 minutes for the summarized monitored networks to update in the show azure vnets command output. Example of usage:
Last updated
Was this helpful?