GCP HostID integration
This article goes over the GCP HostID integration available for Vectra NDR deployments that capture traffic from GCP VPCs.
GCP HostID Integration
You may have already created the GCP HostID service account required for this integration when preparing for the deployment of a GCP Brain or GCP vSensor.
If you already have the required service account(s) for you deployment, you can skip the service account creation part of this section.
To enable efficient investigation of cloud hosts, the Vectra Brain can be configured to periodically query GCP to gather additional information about hosts running in GCP. This information contributes to Vectra’s automated Host identification (Host ID) and adds information to the Host 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 Platform UI). Enabling this integration can help contribute to more complete Detection as a result.
Please see this example screenshot below of a Host in GCP 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 name
Project, link to GCP, IP, and Last Seen date/time
Summary information on the left-hand side including instance size, status, name, and zone
Configuration Example
Please Note:
If your organization is organized in a manner requiring more than one service account for your Vectra GCP deployment, multiple sets of credentials can be added to your Vectra configuration for the HostID integration.
For the HostID integration, if your monitoring needs span multiple projects, Vectra requires a service account per project. Existing service accounts can be re-used, or you may add new ones specific to this use case.
Resources
Basic Steps
After signing into the GCP console, navigate to IAM and Admin → Service Accounts and click + CREATE SERVICE ACCOUNT.
Give the account a name and optionally a description and then click CREATE AND CONTINUE.
In the below example, we are creating a service account for the HostID service account used by the Brain to retrieve artifacts that help with Vectra's automated HostID. When creating other service accounts, choose the appropriate role for the service account you are creating.
Choose a role that has read access to the compute v1 endpoints on GCP API to list zones, instances, and networks and click CONTINUE. The predefined Compute Viewer role provides the required permissions:
Optionally grant users access to the service account and then click DONE.
Now select your newly created service account and navigate to the KEYS tab, click on ADD KEY, and then Create new key.
Select JSON format and click CREATE.
This key will download to your computer when created.
Please note:
Save the key for later use.
On the DETAILS tab for your service account, also make note of the Unique ID for later use.
To complete the integration, in the Vectra UI, browse to Configuration → Settings → External Connectors.
Click on the pencil or Edit link for Google Cloud.
Toggle the integration to On and fill in the CREDENTIAL ID (the Unique ID you made note of in the last step) and upload your CREDENTIAL JSON file.
Click Save. Multiple sets of credentials can be configured if required for organization.
The connection will be tested and if successful, you will see a green checkmark showing that Google Cloud integration has been completed.
Viewing and Modifying Virtual Networks Considered by the Connector
The connector will only look at virtual machines that belong to some VPCs, not necessarily all VPCs that the credentials have access to. Specifically, by default, the connector will only look for virtual machines with network interfaces in the VPCs where a Vectra GCP Sensor traffic interface is deployed into, and all the VPCs peered to it. If a virtual machine has multiple network interfaces, the connector will provide host identification only for the IP addresses belonging to interfaces on monitored VPCs.
Vectra limits the scope of the connector to only virtual networks that can reach an GCP Sensor for the following reasons:
Vectra wants to avoid an excessive number of connections to the GCP 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 any of the following:
If you have some tunneling or forwarding enabled and Vectra GCP Sensors see traffic from VPCs that are NOT directly connected to our Sensor:
You will want to add the networks to the monitored networks list to extend HostID coverage to the tunneled/forwarded traffic’s associated Hosts.
If you do NOT have any GCP Sensors deployed, but mirror GCP 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 Sensor, but it is not monitored by our Sensor:
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 VPCs but only some are monitored by the Sensor:
You will want to remove the non-monitored networks from the monitored networks list to increase performance and reduce load on the GCP resource manager.
The command to add or remove virtual network from the Vectra CLI is set gcp vpcs . The command has a very helpful help message illustrating its use:
The command show gcp vpcs will show the VPC configuration, including the whitelist (VPCs to ADD), the blacklist (VPCs to REMOVE), the Sensor’s VPCs, 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 gcp vpcs command output. Example of usage:
This concludes the GCP vSensor deployment guide.
Last updated
Was this helpful?