How to Monitor VPN Split Tunneling and Remote Endpoints with Existing Infrastructure
By Scott Pope Using AnyConnect for VPN? Got Splunk? If so, you have what you need to secure, monitor and gain detailed endpoint visibility to:
Implement VPN split tunneling to alleviate VPN capacity constraints without sacrificing security
Monitor and further optimize traffic you put over your existing split tunnel deployment
Analyze security behavior of remote endpoints, users and VPN “top talkers”. This is particularly useful for remote work endpoints that were rapidly deployed with less stringent that normal security compliance testing.
AnyConnect and Splunk are the infrastructure for Cisco Endpoint Security Analytics (CESA), which provides the monitoring and security analytics to address the scenarios above. With many IT orgs resistant to deploying any new infrastructure, CESA allows IT to use what they already have deployed to gain the VPN, zero-trust and remote work endpoint visibility they seek.
Let’s take a closer look at each of these scenarios.
————————————————————————————————————
Need increased remote work & VPN monitoring? Use CESA Splunk free for 90 days for licenses initiated before July 1. Contact your Cisco account team or channel partner for details.
————————————————————————————————————
Scenario 1: Want to deploy split tunneling, but lack detailed traffic visibility to implement it
Many networks would benefit from offloading as much remote worker traffic off their VPN infrastructure as possible. VPN throughput, and the network performance it enables for users, is at a premium. As such, offloading specific types of traffic like Office365, WebEx and other SaaS applications to a VPN “split tunnel” that directs traffic directly to its destination (instead of bringing it through the VPN concentrator) makes a lot of sense. But with split tunneling comes a lack of visibility into traffic traversing it, since that traffic is no longer coming back to the security stack at the “headquarters”. Furthermore, networks may need to offload more traffic than the obvious SaaS services to maintain acceptable end-user performance. But deciding what is “safe” to move to a split-tunnel is a challenge without detailed visibility into what types of traffic the VPN endpoints are generating. This is where CESA comes in.
CESA collects highly detailed traffic telemetry from AnyConnect VPN clients. This flow data provides detailed insight to applications generating/receiving traffic on the endpoint, as well as who the user is, domains they are communicating with (whether the user knows it or not) and all source/destinations. CESA can then see which of all that traffic–down to user/device/application/software-process/domain/port/source/destination level–is going over the VPN tunnel. With this visibility, IT orgs can then identify what traffic is “safe” to put into a split VPN tunnel to optimize VPN throughput capacity. Furthermore, AnyConnect enables “Dynamic Split Tunneling”, which makes it easy to direct split tunnel traffic by domain name (e.g. put all “*webex*.cisco.com” into the split tunnel). Dynamic Split Tunneling analytics is also supported in CESA.
Scenario 2: Already have split tunneling, but need better security monitoring & traffic optimization
For networks that have already implemented split tunneling, many are looking to: a) make sure there isn’t sensitive traffic in the split tunnel that shouldn’t be; b) see what other traffic they can safely offload into the split tunnel.
Similar to the initial split tunneling deployment scenario outlined above, CESA provides the VPN traffic insight needed to keep tabs on what traffic is going over the split tunnel and also identify the traffic that should be moved back into the corporate tunnel. And there reverse is also true. CESA can monitor the corporate tunnel to identify traffic that could be safely moved to the split tunnel. Furthermore, CESA tracks the volume of traffic by application, protocol, port, software process, domain, source/destination, etc. This enables IT orgs to identify high volume applications and data sources and move them to the split tunnel first to make the largest impact on VPN performance with the least amount of effort and configuration.
Scenario 3: Need more security monitoring for all these new remote users
In emergency situations, IT orgs are often put in the position of rolling out a high volume of remote workers in a very short time. Depending on the situation, normal validation of security oversights for these users might be overlooked to expedite getting business running again. This might mean the user endpoints aren’t on standard IT builds. Or they don’t have the usual endpoint security used for remote workers. Whatever the situation, rapidly deployed remote working often entails less than perfect remote user/endpoint security and visibility.
Given the foundation of CESA is the telemetry it gets from AnyConnect, it is a natural solution for enhancing remote endpoint security. CESA picks up endpoint security where endpoint protection platforms (EPP) and endpoint detection and remediation (EDR) solutions end. EPP/EDR solutions focus on malware by detecting known bad file hashes and then removing them from endpoints. CESA takes the next step by focusing on behavioral-based threats like malicious insiders and malware droppers and activity not detectible via file hash detection. And CESA can be configured to monitor endpoints both when they are off the network and when they are on it, giving complete visibility into all endpoint activity. If you are concerned about user privacy, you can set the AnyConnect telemetry collection parameters to only collect flow data when the VPN is active.
In a hastily deployed remote work environment, it can be difficult to be sure all the endpoint security “i’s” got dotted and “t’s” got crossed. CESA helps with that by looking for “all the weird stuff” that is only detectable via endpoint and user behavioral analytics. And when your employees come back to the office, you will have these same monitoring capabilities, such as detecting when users are on the corporate Wi-Fi and divert data through a non-corporate network interface like a Wi-Fi dongle.
Next Steps
As mentioned, if you already have Splunk Enterprise and AnyConnect deployed, CESA is essentially just a feature license that enables you to bring AnyConnect telemetry into Splunk cost-effectively and with a predictable fixed budget. CESA is priced per endpoint, so unlike a typical Splunk license, you don’t need to figure out how much data you’re bringing into Splunk; you just need to know the number of AnyConnect endpoints you want to monitor. And until July 1, 2020, CESA trial licenses are offered for 90 days free of charge to help IT orgs any surges of remote working they may be encountering. Contact your Cisco account team or channel partner for more details.
Deploying CESA for existing AnyConnect and Splunk customers involves 3 steps:
Configure AnyConnect clients to generate Network Visibility Module (NVM) telemetry. This is just a configuration parameter for AnyConnect 4.2 later and does not require “touching” the endpoint or deploying any new software of any sort.
Configure Splunk to receive and analyze AnyConnect NVM telemetry. To do this, install the AnyConnect NVM Splunk App for CESA and the AnyConnect NVM Technical Add-On for Splunk.
Check your Splunk storage capacity. Each AnyConnect client generates 6-10MB of telemetry per day, or less depending on what NVM fields are enabled or filtered out.
What if I don’t have AnyConnect or Splunk already?
You can still deploy CESA for these scenarios, but you’ll need to install Splunk Enterprise on a server or as a hosted VM. All necessary Splunk Enterprise software comes with the CESA license. Or if you are not using AnyConnect for VPN and still want to monitor endpoints on other VPN solutions, a standalone Cisco NVM module that generates all the telemetry discussed above can be installed on endpoints.
View a CiscoTV event with live Q&A explaining use-cases and capabilities of CESA. Register or view here.
The post How to Monitor VPN Split Tunneling and Remote Endpoints with Existing Infrastructure appeared first on Cisco Blogs.
Source:: Cisco Security Notice