Many companies have augmented or even replaced IPsec VPNs with secure remote access solutions based on SSL. Given that SSL VPNs can be used from unmanaged home or public PCs, it is critical to assess the remote endpoint's security when deciding whether to permit access to corporate resources. This tip explores why and how network access control functions are used to strengthen SSL VPNs, and their relationship to industry NAC initiatives.
Opportunity and risk
By using the Web browser as a client platform, SSL VPNs make it possible to deliver remote access to devices that lie far beyond IT control, from home PCs and Internet kiosks to business partner laptops and executive PDAs. This "anytime, anywhere" approach can extend access to many more workers while reducing the cost of providing it. By 2008, Gartner expects, SSL VPN will be the primary remote access method for two out of three teleworkers and more than 90% of employees requiring occasional remote access.
However, connecting unmanaged endpoint devices to corporate networks adds risk. If a teleworker's home PC is infected with a worm or trojan, its VPN tunnel can be exploited to relay those threats to corporate resources. If an Internet kiosk harbors a keystroke logger, the user's entire VPN session -- including login and password -- can be stolen. In both situations, users tend to leave sensitive data behind where others can find it, from cached passwords to temp files. Clearly, delivering secure anywhere access to unmanaged endpoints requires mitigating these risks.
Filling the void
Fortunately, SSL VPN vendors have been hard at work solving these challenges. Today's SSL VPN appliances offer a fairly mature set of network access control functions to combat these threats:
Identification: SSL VPNs support user authentication methods and directories, creating a foundation for identity-based access control. But a given user might connect from both managed and unmanaged endpoints. Decisions must therefore be based not only on user identity but also on device identity and type. Depending on product, SSL VPNs may recognize trusted endpoints using HostID, computer/domain name, device certificate, resident files, registry keys, or hardware tokens. The VPN may also identify the endpoint's operating system and browser and adapt its response accordingly.
Endpoint integrity: For years, VPNs simply assumed that managed devices were trustworthy. Unmanaged devices raised risk awareness, but it was never really safe to assume that endpoints were malware-free and policy-compliant. Today, most SSL VPNs check endpoint integrity, using administrator-defined profiles to detect missing patches; old virus signatures; inactive or corrupted antivirus, anti-spyware, and firewall programs; unusual processes or listening ports; and signs of malware. To simplify configuration, many products provide templates, checklists to choose from, or graphical rule builders. Some can even interact with the endpoint security programs on managed endpoints. And, while most SSL VPNs can perform pre-admission checks, some can also support post-admission integrity audits, making sure that the endpoint remains clean.
Authorization: By operating at a higher layer, SSL VPNs provide more granular authorization policies than IPsec. Instead of granting access to entire subnets, many SSL VPNs can narrow access to individual servers, applications, commands, URLs, folders, and other data objects. Combining these granular filters with user authentication, device identification, and endpoint integrity checks can be powerful. For example, a worker using a company laptop may be given broad application access while being restricted to remote terminal sessions from a kiosk PC. If endpoint integrity checks fail, the worker may end up connected to a self-help Web page to assist with remediation. Some SSL VPN products bind users and devices to groups and zones, simplifying administration and promoting consistency.
Enforcement: Security doesn't end when an SSL VPN tunnel is established. The VPN must enforce filters that determine which application messages the user can send, where they can go, and how they are protected in transit. Most SSL VPN products take enforcement further, to mitigate those unmanaged endpoint risks. During the session, the user may operate in a secure workspace -- a virtual environment that insulates activities and data from other endpoint processes. When the session ends (owing to explicit logout or inactivity timeout), SSL VPNs may delete all session data, including the Web cache, history, cookies, form-fills and passwords. Here again, measures can be based on policy -- for example, requiring a secure workspace on high-risk platforms while permitting files to be saved to disk on a malware-free, policy-compliant corporate laptop.
These network access control functions may or may not exist in your favorite SSL VPN product. Endpoint-specific limitations also apply -- integrity checks that cannot be performed with administrator rights, or virtual environments that can be established only on Win32 PCs. SSL VPN features have expanded considerably over the past few years, however, reflecting field experience and technology maturity. Take a fresh look at the network access control functions available to you -- you may be pleasantly surprised.
Relationship to NAC
Readers familiar with Cisco's Network Admission Control, Microsoft's Network Access Protection, or TCG's Trusted Network Connect may be thinking, "Wait a minute! These functions sound a lot like [ NAC | NAP | TNC ]." In fact, many of the concepts and techniques embodied by those industry initiatives emerged from the SSL VPN market, from endpoint integrity checks to browser-based dissolvable client software.
SSL VPNs are expected to play a big role in NAC adoption. Infonetics predicts that more than two-thirds of SSL VPN gateways will be used as part of an NAC deployment by 2008. In some cases, those SSL VPNs will be one part of a broader NAC strategy. All three infrastructure architectures view VPN gateways as one type of network enforcement device. Many SSL VPN vendors have either announced support for NAC architectures or participate in one or more NAC initiatives. For example, Cisco, Microsoft (Whale), and Juniper sell SSL VPN appliances that fit into NAC, NAP and TNC, respectively. Caymas Systems even has an SSL VPN appliance that supports both NAC and NAP.
When deployed as part of a broader NAC strategy, one obvious approach is to have the SSL VPN appliance focus on controlling network access by offsite remote users: travelers, teleworkers, day extenders, mobile professionals. However, some analysts believe that SSL VPNs could play a starring role in NAC. Specifically, as the network perimeter evaporates, more and more devices may be considered "remote" (external). Some enterprises may choose to run all network access -- onsite and offsite -- through an SSL VPN appliance. Doing so could leverage the SSL VPN industry's heritage of applying network access control to offer safer access from potentially risky endpoints.
About the Contributor: Lisa A. Phifer is vice president of Core Competence Inc. She has been involved in the design, implementation, and evaluation of data communications, internetworking, security, and network management products for over 20 years and has advised companies large and small regarding security needs, product assessment, and the use of emerging technologies and best practices.
NETWORK SECURITY SCHOOL MENU
Network Security School: Home
Lesson: Home
Lesson webcast
Lesson podcast
