Follow

Optimizing Cognito for use with VPN clients

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

Cognito 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. Note that 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.

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; and (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 Cognito 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, Cognito sensors must observe the traffic from the IPs in the VPN IP Pool allocated from the addresses inside the organization’s network. Cognito 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 IP Addresses (CIDR)” under Settings→ General in the Cognito UI
  • Under “Network stats → Devices”, search for the VPN subnet to confirm that a Cognito sensor is observing the traffic from the VPN IP pool subnets
  • Navigate to the Network Traffic Validation tool ([yourvectrabrain]/tools/ntv_stats) and look for your VPN IP pool subnets in the list.

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 Cognito 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 Cognito 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, Cognito 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 Cognito 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 the Network Traffic Validation tool ([yourvectrabrain]/tools/ntv_stats) and look for your VPN IP pool subnets in the list. A sample from the Vectra demo system is shown below. HostID coverage is shown in the 3rd column.

mceclip0.png

HostID coverage is shown in the 3rd column. The meaning of each indicator is shown below.

  • Coverage
    % of active IPs (host sessions) that have a stable HostID anchor. Measured from the period of time since the last time the stats were reset. If you make changes, please Reset Network Statistics to delete the old statistics and immediately see the effect of the changes you made.
    Maximum coverage for your environment may be different, but 80%+ is considered good coverage for Windows-heavy environments.
  • DHCP
    Indicates the presence and quality of DHCP traffic. Typically this will not be present (and thus marked as an X) in VPN pools since the IP is generally assigned by the VPN concentrator rather than being managed by your DHCP server.
  • Kerberos
    Indicates the presence and quality of Kerberos machine authentication traffic. This should have a green check mark indicating that hosts on these IPs are observed doing Kerberos machine authentication to the domain controller – all machines which are members of a domain perform this authentication upon getting “dial tone” on the network.
  • DNS
    Indicates the presence and quality of DNS traffic. Usually, this will be a yellow checkmark, meaning that IPs in the subnet are sourcing DNS requests (but no servers that are sinking them are). DNS traffic will be extremely important for visibility in split-tunnel VPN deployments but is less important for HostID. rDNS will be the key enabler for HostID, but that is not tracked in this metric.

Improving HostID Coverage in your VPN pool

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 Cognito 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 Cognito 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 Settings → External Connections → 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.

Currently, supported integrations are available for CrowdStrike Falcon, CarbonBlack CbResponse, and Microsoft Defender.  Multiple integrations may be enabled simultaneously. Navigate to Settings → External Connectors to enable.

For other EDR solutions, contact your Vectra Regional Sales Manager or Customer Success Manager.

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.

Was this article helpful?
0 out of 0 found this helpful

Download PDF

Have more questions? Submit a request

0 Comments

Article is closed for comments.