Optimizing Vectra for use with VPN clients

How to optimize Vectra observability for VPN clients by using Sensor placement, SASE/SSE integration, EDR integration, Windows Event Log Ingestion, and rDNS.

Introduction

Remote workers connecting on VPN en masse present increased security risks to the organization:

• Split-tunnel and sometimes-connected systems have less preventive security coverage and a higher chance of compromise

• Increased authorized VPN usage makes it harder to identify malicious activity coming through the VPN

Vectra NDR (Detect) can help by providing full coverage for Recon and Lateral (E-W) activity originating from users connected via VPN, indicative of attackers attempting to move into the data center, cloud, or IoT for persistent access to the enterprise environment.

Please Note:

When split tunneling is used on VPN connections, C2 and Exfil (N-S) legs of the attack will not be covered, as the endpoint communicates directly with outside IPs without sending that traffic through the VPN. See Remote Users (SASE /SSE) for integration details with SASE / SSE vendors and how Vectra NDR can still be fed network traffic from these solutions.

The key to ensuring full detection coverage and efficacy is:

1. Ensure that all traffic which originates or is destined to the pool of IPs allocated to the VPN service is covered.

2. Getting good HostID coverage for this pool of IPs.

With these two conditions met, the systems connecting in on VPN will look the same to Vectra as if they were physically present in the network, including learnings, detection attribution, and host scoring.

The impact of not meeting these two conditions is serious. Lack of traffic visibility will, of course, leave you blind to activity originating from VPN-connected hosts. Poor HostID also has a significant impact, causing potential false positives and misattribution of true positive detections—with ripple effects on host scoring—and loss of coverage for the subset of the detections which have host-based learnings.

Traffic coverage over VPN

Lack of traffic visibility will leave you blind to activity originating from VPN-connected hosts. This section describes how to:

1. Validate coverage

2. Resolve any lack of coverage

Validating VPN traffic coverage

In order to have the proper coverage, Vectra Sensors must observe the traffic from the IPs in the VPN IP Pool allocated from the addresses inside the organization’s network. Sensors do not need to observe the traffic leg from the end-users to the VPN concentrator (since that will be encapsulated in the VPN protocol anyway).

In order to check whether you have coverage for VPN subnets, you can do any one of these:

• Ensure that the VPN IP pool subnets are covered by Internal VPN IP Addresses (CIDR) under Configuration → COVERAGE → Data Sources → Network → Brain Setup in the Vectra UI.

• Under Network Stats → Observed IPs, search for the VPN subnet to confirm that a Sensor is observing the traffic from the VPN IP pool subnets

Resolving VPN traffic coverage gaps

If you don’t observe coverage for the VPN subnets, check if the VPN traffic from the VPN concentrator inside the network is on a different VLAN and if that VLAN has been spanned to a Sensor. If it hasn’t been spanned, see if a change of SPAN configuration can add the traffic to an existing Sensor. If that is not possible due to the proximity of capacity issues, additional Sensors can be deployed to capture this critical VPN traffic.

Measuring and Optimizing HostID Coverage for your VPN pool

Good HostID for systems in your VPN pool range is important in enabling full security coverage for VPN users. This section explains the impacts of poor HostID coverage, how to measure current coverage and steps to take to improve coverage.

Impact of low HostID coverage

If neither of the steps above works to give you strong HostID, you will still have partial coverage from Cognito. However, there are meaningful impacts to be aware of: (1) loss of coverage from a subset of detections; and (2) misattribution of detections and metadata.

Loss of coverage

Vectra's attacker behavior models use a variety of approaches, some of which consider baselines of machines over long periods of time, even when the hosts’ IP addresses change. These baselines are made possible by using HostID as a stable anchor for individual hosts (and their learnings.

When HostID is not present, there is an impact on some detections:

• Suspicious Remote Desktop and Suspicious Remote Execution Provide a subset of coverage based on network-wide learnings. Expect decreased coverage, but no increase in FPs.

• Suspicious Admin Falls back to IP-based learning. This may cause both coverage loss and increased noise in the VPN use case due to the transient nature of the IP address.

• Privileged Access Analytics suite Coverage lost for all VPN connections without HostID.

All other detections will continue to work as designed, even without HostID.

Misattribution of detections and metadata

Many detection models will work without HostID, however, in the VPN use case with partial or poor HostID coverage, there is a chance of misattribution of detections.

Assume the following sequence:

• Laptop A connects via the VPN and is assigned an IP of 192.168.10.10. HostID establishes that this is bobs_laptop via Kerberos machine authentication. After doing his work, Bob disconnects.

• Laptop B connects to the VPN 15 minutes later and gets the now-available IP of 192.168.10.10. This is a Mac and no HostID artifacts are seen.

In this scenario, Vectra does not deduce that the host has changed—there are no indicators and the inactivity window (15 minutes) is short—so any activity from Laptop B will continue to be associated with bobs_laptop. This would include both detections and metadata.

In this scenario, you would need to look at the VPN logs to determine the proper attribution of the detection.

Note that in the case of no HostID, all activity from the same VPN IP would be attributed to the same generic “IP-“ host. Again, this will require the perusal of VPN logs in order to determine the underlying attribution of activity and detections.

Measuring HostID coverage in your VPN pool

In the Vectra UI, hosts labeled starting with IP- are known as generic hosts and do not have a stable HostID. If you see many of these in your VPN pool range and they show recent times for the Last Seen date on the individual host pages, it is indicative of low HostID coverage.

The easiest way to get a definitive view of your current coverage is to use Network Traffic Validation tool and look for your VPN IP pool subnets.

Improving HostID Coverage in your VPN pool

By just setting the Internal VPN addresses, it will not automatically set the host name. We still rely on information gathered, but knowing that a host IP belongs to a VPN will improve this. If you are not seeing good HostID coverage already, there are two high-impact steps to take: spanning the VPN VLAN and enabling EDR integrations. Each is explained in more detail below.

Getting Kerberos machine auth traffic

In Windows environments with domain-joined (managed) devices connecting in, Kerberos machine authentication events will be the key to excellent HostID coverage in both local and VPN scenarios.

Kerberos machine auth events will flow from the VPN pool IP (usually in the private RFC1918 part of the address space) to the domain controller. Typically, spanning the VPN VLAN into a Sensor will give full visibility into Kerberos events – as well as general coverage for end-user traffic from the VPN pool.

If you have spanned the VPN VLAN and are still not seeing Kerberos traffic (per NTV) or have lower HostID coverage than you’d expect given the mix of domain-joined Windows systems, then the priority should be on determining where the Kerberos traffic is and how to get it to a Sensor. Windows Event Log Ingestion (WELI) can also be used to help gather Kerberos traffic that isn't observed by a Vectra Sensor.

Enabling reverse DNS lookups

Many systems that provide combined DHCP and DNS services will register the device ID or hostname sent from the requesting host to generate a reverse PTR record in DNS with a short TTL. If this is true in your environment, you are likely to see a substantial improvement in HostID coverage by enabling Reverse DNS Lookup, as the HostID system will use this information to accurately identify hosts.

Navigate to Configuration → SETUP → External Connectors → Reverse DNS Lookup to enable this option.

Enabling supported EDR integrations

Enabling one of the supported Endpoint Detection and Response (EDR) integrations will also improve HostID coverage. These integrations provide HostID artifacts out-of-band and these artifacts will properly identify the host to the Cognito brain.

Multiple integrations may be enabled simultaneously. Navigate to Configuration → SETUP → EDR Integrations to enable.

Enabling EDR integration is recommended in all environments where available. It will be especially critical if you have a Mac-heavy environment where the Macs are not joined to the domain and accurate rDNS is not available.

Note that there is currently a lag in the EDR HostID visibility due to caching implemented in Vectra to reduce the load on EDR API endpoints. This means that longer-lived VPN sessions (multiple hours) will be properly identified, but there may be a misattribution early in the host session if no Kerberos machine authentication is observed.