5.1. In the Beginning, There Were SSL VPNs

SSL VPNs have been around long enough to have their own overall product category. In many ways, SSL VPNs were the very first NAC products available.

Historically, organizations used SSL VPN to protect their Wi-Fi (wireless fidelity) deployments and their remote access deployments. When users wanted to access the wireless network, they needed a valid SSL VPN session, in addition to possessing wireless credentials (such as a WEP key). Because SSL VPNs provided this functionality, organizations could layer role-based access control onto their wireless networks and up the ante for wireless security.

SSL VPNs are primarily a remote-access–oriented technology that acts as a gatekeeper between the end user and network resources and applications. Access control decisions are based on user identity/role and endpoint integrity, among other things.

Sounds a lot like NAC, doesn't it?

5.1.1. User identity with SSL VPN

User identity validation (authentication and authorization of users) with SSL VPN is very similar to an NAC solution. For the most part, these products are architected to integrate seamlessly with the organization's existing authentication infrastructure.

The similarities between user identity with NAC and user identity with SSL VPNs is a bonus for many organizations. They can leverage a single authentication and authorization infrastructure for both local and remote users.

5.1.1.1. User authentication

From an authentication perspective, most leading SSL VPN offerings provide integration with a mix of standards-based and proprietary authentication servers, such as the options discussed in the following sections.

5.1.1.1.1. Local authentication

Local authentication is an on-board database for authentication of users. The entire user account management and record storage is done on the SSL VPN appliance.

Most SSL VPN vendors offer this type of authentication, though it's used primarily for administrator authentication or for smaller organizations. Most large organizations invest in (or plan to invest in) an external user authentication solution.

5.1.1.1.2. Lightweight Directory Access Protocol (LDAP)

LDAP is a standard protocol for querying a directory database and for making updates to database records. As one of the more commonly used interfaces in SSL VPN deployments, LDAP acts as the protocol of choice for querying many types of databases, including Active Directory.

5.1.1.1.3. Active Directory (AD)

Active Directory is one of the leading directory servers, and most organizations deploy it, to some extent. Many SSL VPN servers offer a native Active Directory authentication server interface, but AD deployments can also leverage LDAP/LDAPS (LDAP over SSL) for queries and updates.

5.1.1.1.4. RADIUS authentication and one-time password systems

Multiple-factor authentication, such as one-time passwords (OTPs) and digital certificates (see the following section), have become very popular for remote access use, replacing static user names and passwords in many organizations. Like with digital certificates, a number of technologies have evolved that make it far easier and less expensive to deploy and manage one-time password solutions, and organizations have adopted these technologies as a result of those developments.

Most SSL VPN systems provide a standard way to interface with these OTP systems through the RADIUS protocol. Remote Authentication Dial-In User Service (RADIUS) provides authentication, authorization, and accounting services, and most OTP systems available on the market today support RADIUS. Some SSL VPNs also provide native support for proprietary OTP systems, but you don't need this special native integration for most deployments because the RADIUS interface can provide the same functionality.

5.1.1.1.5. X.509 certificate authentication

In recent years, X.509 digital certificates have gotten more popular as an authentication method. X.509 certificates are issued by several trusted certificate authorities to organizations and to end users. These trusted certificate authorities (CAs) hold the power to revoke these certificates at any time. Because they are based on secure digital certificates, this form of user or machine credential is impossible to spoof or steal without acquiring the private key, which is kept protected and never exchanged. The U.S. Federal Government has been a huge driver for adoption of X.509 certificates, due to mandates requiring their use not only by government agencies, but also by government contractors and other private sector organizations. As a result, both software and hardware support has improved significantly over recent years, making deployment and ongoing administration much simpler.

When an SSL VPN appliance supports X.509 digital certificates, that appliance must perform validation of a certificate to ensure that the certificate hasn't been revoked. The SSL VPN validates the certificate with either

• CRLs (certificate revocation lists): CRLs are essentially lists of revoked certificates that are distributed by the certificate issuer.

• OCSP (Online Certificate Status Protocol): OCSP was introduced as a way to bypass some of the limitations of CRL checking (such as the size of the lists), and it specifies a way to verify certificate status in real-time.

In addition to certificate status validation, the SSL VPN might also retrieve user attributes from the certificate so that the SSL VPN access control system can compare those attributes to attributes in a directory, for example, or map users to specific roles in the SSL VPN implementation. Most SSL VPNs also allow the administrator to specify which certificate authorities (CAs) result in a successful authentication.

5.1.1.1.6. Security Assertion Markup Language

Security Assertion Markup Language (SAML) is a standard for authenticating and authorizing users across different systems. Essentially, it's a Single Sign-On (SSO) technology. Some SSL VPN appliances provide support for SAML, allowing users that are already logged in to other systems the ability to be seamlessly logged in to the SSL VPN system, as needed.

5.1.1.2. User authorization

User authentication (discussed in the preceding sections) is only one piece of the puzzle in identifying and providing appropriate access to users. Another piece is authorization.

In some cases, the relevant information is stored in the authentication request itself. For example, an X.509 digital certificate or an SAML assertion might contain information that allows the SSL VPN to do the appropriate role mapping. In other cases, however, the SSL VPN appliance needs to query the directory.

Many organizations have stored information, such as group membership or other attributes related to each user, in Active Directory or some other LDAP database. Upon login, the SSL VPN queries the database to get these details and uses that information to assign the user to a specific role. For example, an LDAP query for John Doe might return information indicating that John is an employee in the Engineering group. As a result, John gains access to the intranet, corporate e-mail, and various engineering-specific resources.

5.1.2. Endpoint security with SSL VPN

When you compare SSL VPNs and purpose-built NAC systems, endpoint security (or endpoint integrity verification) for each is almost identical.

For the most part, organizations want to ensure an appropriate machine posture prior to allowing a user access to the network. In addition, most organizations see more variance in the types of machines from which end users want to gain access to corporate resources when those users access the resources remotely, versus when they access them locally. For example, end users might need to access their e-mail from their home PCs, or they might want to download a PowerPoint presentation from a kiosk in a hotel lobby.

For these kinds of reasons, it becomes crucial to validate the endpoint machine prior to allowing the user to come on the network in a remote-access setting.

Figure 5-1 shows users accessing the SSL VPN from three different locations. In this case, the SSL VPN policy dictates that a different level of access is granted to the end user based on whether the user's machine is in compliance with the policy. Figure 5-1 is similar to typical policies used in active SSL VPN deployments:

• Home PC: This machine doesn't have an antivirus application installed, so the user is prompted to remediate the device. The user downloads and installs the appropriate antivirus software, and then is allowed access.

• Kiosk: The user is accessing the SSL VPN from a public machine. Obviously, the user doesn't have privileges on the machine, so the user can't install additional software. Because the user can't remediate the machine, the SSL VPN fails the policies, but the administrator has set up a policy to grant the user minimal access in this type of situation.

• Managed PC: The user is accessing the network from an appropriately patched and compliant managed laptop, so the user is granted full access to the SSL VPN.

Although Figure 5-1 may be too simple for you and your network needs, it shows a small piece of the flexibility available with SSL VPN systems. Other types of policies are available with SSL VPNs for endpoint integrity verification, too.

5.1.2.1. Endpoint security applications

One of the most commonly used and easiest to configure types of endpoint security policies are those that verify the presence, operation, and up-to-date nature of third-party endpoint security applications. These types of policies ensure that endpoints connected to your network have the appropriate self-protection mechanisms in place.

Most SSL VPN products available have a list of predefined policies, though the level of comprehensiveness varies from one implementation to the next.

Look for these common policy types provided by NAC vendors:

• Operating system: These scans allow you to verify the operating system, and potentially the service pack, of the incoming endpoint device, which is especially important in an SSL VPN deployment in which you have no advance idea the type of device from which the user is trying to gain access.

  Operating system policies can help you to verify which type(s) of additional endpoint security mechanisms to put into place. You might have a different endpoint security policy for a Windows XP SP2 device than for a Windows CE or Macintosh OS device. Even within something like the Windows OS, you might have some differentiation — for example, your corporate standard personal firewall might be different on Windows XP machines versus Windows Vista machines. This information also helps the SSL VPN system itself to appropriately display login pages, home pages, and application interfaces to end users. For example, the login page on a Macintosh might look quite a bit different on a Windows Mobile Smartphone.

• Antivirus: Scanning for antivirus applications is one of the most common types of endpoint integrity policies implemented with SSL VPNs. Organizations want to ensure that machines connecting to their networks have an appropriate level of protection, and an antivirus application is pretty much a standard requirement for verifying endpoint integrity.

  NOTE

  You can't simply scan the machine to ensure that it has an antivirus application installed — scanning for particular files or registry settings, for example, doesn't necessarily guarantee that the antivirus application is actively protecting the machine itself. Also, you may find looking at processes running in memory troublesome, even if you're verifying an MD5 checksum of the process, because modern antivirus applications may have several processes running at any given time. Without an in-depth knowledge of what each process does, endpoint integrity agents can have difficulty determining the processes that must be running to verify normal operation of the antivirus application. Throughout normal operation, some processes might start at different times, making this a very difficult task.

  Most NAC vendors offer a solution that checks not only whether the machine has an antivirus application installed, but whether it's also running and up to date. Some of the available policies on the market include

  • Verifying installation of a particular version or vendor of antivirus solution(s).

  • Verifying that real-time protection is actively enabled on the system.

  • Verifying that virus signatures are fully up to date or that they've been updated at some point in the recent past, depending on your policy.

  • Ensuring that a successful full system scan has been completed in the last few days. (The number of days depends on your antivirus vendor's update schedule, and your organization's willingness to allow machines with slightly outdated antivirus policies to join the network.)

  Depending on your organization's security policy, you might want to verify one or more of those attributes related to antivirus.

  Your verification might vary, based on the user and machine in question. For instance, you might want to be very specific in your scan when an employee comes onto the network by using a company-owned and -managed machine, but when that same employee tries to access the network from his or her home machine, you might allow some level of restricted access only if his or her machine is running an up-to-date antivirus application from any vendor supported by your SSL VPN appliance.

  
  

• Personal firewall: Checking to ensure that a machine has a personal firewall installed and enabled is a common endpoint security measure. This scan ensures that the endpoint device has active protection enabled. Like with antivirus scans, make sure that you're verifying the personal firewall is actually running, not just installed.

• Disk encryption: With the number of data loss incidents in the news — not to mention the thousands of laptops lost or stolen in airports and other public areas every year — disk encryption is becoming more popular by the day. These scans allow you to ensure that the sensitive data on a mobile device or laptop hard disk is secured and encrypted.

• Antispyware: You want to ensure that the antispyware application is running and actively protecting the system, not only installed on the machine.

• Peer-to-peer applications: Many organizations fear peer-to-peer applications because a user can inadvertently download viruses or malware, and the application could potentially allow an intruder to gain access to a machine. SSL VPN products are increasingly beginning to scan for these types of applications so that you can verify their presence and, if necessary, shut them down before allowing the user to have full access onto the network. If you have users accessing the SSL VPN from their home machines, you probably want to shut down their teenagers' BitTorrent or other file sharing applications before allowing those users to view sensitive corporate data.

  NOTE

  The Windows operating systems has a much more comprehensive list of policies than any non-Windows OS — Macintosh, Linux distributions, and mobile platforms. Windows is the most heavily targeted operating system with the most known vulnerabilities, so you find the largest selection of endpoint protection suites for Windows. While other platforms gain or lose market share, you'll see an expansion or contraction in terms of the number of offerings for these devices. For example, the number of antivirus and personal firewall applications for Windows Mobile and Macintosh machines has increased significantly, mostly as a result of increased popularity of these systems, which leads to an increased likelihood that hackers will target these machines.

5.1.2.2. Operating system and application patches

New application and operating system vulnerabilities are discovered on a daily — even hourly — basis. Hackers are increasingly motivated by profit, rather than by fun and glory, so exploitation of these vulnerabilities happens alarmingly fast. As a result, you absolutely must appropriately patch operating systems, middleware, and applications as often as possible.

In the datacenter, where servers and applications are tightly controlled, applying such patches is a relatively easy task. Virtualization and datacenter management technologies allow the administrator to easily take machines offline, patch them, and then bring them back online with minimal user disruption.

Outside the datacenter, especially with mobile users, the myriad devices connecting to the average corporate network changes frequently due to the frequency with which device vendors release handset and new operating system versions. Because most SSL VPN users are mobile users, their devices frequently connect to a dizzying array of 3G networks, Wi-Fi networks, and wired connections — and many of these networks are very insecure. These devices might be holding intellectual property, customer information, or sensitive financial data, so you need to both scan these machines when they come onto the network (to protect the network and network assets) and ensure, at least on a periodic basis, that the device can be patched to protect against known exploits, thereby protecting that data on the machine.

To help solve this problem, many SSL VPN solutions offer a mechanism to check the endpoint machine for required patches prior to allowing that machine onto the network. This mechanism helps to not only validate endpoint security, but also ensure that even fully remote machines can stay patched and up to date. Because patches change all the time, SSL VPN appliances implementing this type of scan typically include some sort of update mechanism that allows them to stay up to date and dynamically enforce policies that scan for new patches.

For example, Microsoft sticks to a monthly release schedule for their new patches on what is known as Patch Tuesday. After Microsoft releases these new patches, most vendors publish new patch scans as soon as possible. The SSL VPN appliances are updated dynamically, usually by the SSL VPN vendor, and after that update, the SSL VPN, through its endpoint integrity agent, enforces those new policies for new sessions or for policy reevaluations.

But what to scan for? A fully loaded system might have dozens, or even hundreds, of applications. Certainly, you don't need to ensure that every single application is fully patched and up to date.

Most patches are classified by severity, so you probably don't have to scan every single one. And when these patches are released, you might determine that the potential impact of some vulnerabilities is higher than others, so you want to make sure that you install the patches corresponding to the impactful vulnerabilities on all devices. For example, in the retail marketplace, your customer relationship management (CRM) software might have had a critical vulnerability that was recently patched. You'd find it more important and prudent to ensure that this patch is installed on the endpoint systems, as compared to ensuring that iTunes was patched on your endpoint machines.

5.1.2.3. Machine identity: Who's on first?

Most organizations trust the machines that they own and manage to access networks more than they do foreign devices. They can control the patch levels, software distribution, and (to some extent) who uses the device. As a result, they feel more comfortable providing access to sensitive corporate data from these machines.

If you find yourself in this boat, you might want a programmatic way to identify your own machines versus outsiders. You can make this identification easily enough when you can look at the PC and see your corporate asset tracking barcode or other physical identification, but identification isn't so easy when you must differentiate between two seemingly identical Windows XP SP2 machines that have nearly the same installed software, one of which is a corporate-managed laptop, with the other being some employee's untrusted personal use machine.

Over the years, we've seen customers use many different methods to trick this identification step, some of which are more secure than others.

Given the native, custom endpoint security scans that many SSL VPN appliances provide, some of the less secure and easily bypassed tricks have included

5.1.2.4. Get your certificate

Many companies have begun using a method of device identification more secure than MAC addresses or secret files to identify corporate assets. Many have turned to machine (or computer) certificates. These certificates can be somewhat expensive and difficult to deploy, but luckily, many SSL VPN appliances and many NAC solutions offer such capabilities, so you don't make the investment for only one piece of the network access control deployment. If you're looking for a secure way to identify corporate assets, machine certificates might be your best bet.

Machine certificates are standard X.509 digital certificates, similar to what you might find on a Web server or in user identification such as a smart card or USB drive. The key distinction between machine certificates and user certificates, however, is that machine certificates are stored in the computer or machine on the endpoint device, so they're used to identify the machine, not the user. As a result, the user can't present these machine certificates to the browser as identification — another mechanism must exist to extract and validate the certificate.

Machine certificates have one advantage: They use private key infrastructure (PKI), which is designed to protect against spoofing, man-in-the-middle type attacks, and other security concerns associated with authenticating a previously unknown third party.

Many IT administrators don't feel comfortable with some of the PKI concepts, and many think that rolling out certificates will be difficult or costly. Luckily, many resources available online describe PKI, and certificate management tools have made huge advances in the past few years, making the process of creating, distributing, and managing certificates much easier than in the past.

5.1.2.5. Custom policies

You might find yourself wanting to scan endpoint devices for certain applications, patches, or other types of information that don't fall into the predefined list of applications provided by your vendor. Instead of scanning for a known personal firewall, for example, your organization might have implemented its own endpoint security application. Or you may want to scan for some endpoint security application that's available from an outside vendor, but for which your vendor hasn't yet provided a predefined policy. You don't have to stick with predefined parameters.

Almost every SSL VPN offers the ability to create your own custom endpoint integrity policies, which allow you to scan for such system attributes as

• Presence or absence of certain files on the file system

• Whether a particular process is running on the endpoint

• The MD5 checksum of that process

• Particular registry settings

These scans can provide you with a picture of whether a particular application is running on the system or other customized information that might be applicable to network access control for your organization, as set forth in the corporate security policy.

5.1.2.6. Cache cleaning, as opposed to money laundering

If your organization needs to enable access to corporate resources from unmanaged machines (whether those machines are partner-owned laptops, shared machines in kiosks or Internet cafes, or home PCs), you want to make sure that any evidence of an SSL VPN session, including the details of that session, be deleted from the machine before others begin using the device.

To respond to this requirement, many SSL VPN vendors have implemented cache cleaning, which clears temporary Internet directories, the browser history, cookies, and other remnants of the user session from the machine when that user logs off. You can also use cache cleaning to clear temp files from certain directories on the endpoint device.

Most cache cleaning implementations execute on an explicit timeout, if they encounter an abnormal termination, if the user session expires, or if a loss of connectivity with the server occurs — which means that, regardless of how an SSL VPN session ends, this temporary session data is securely removed from the machine. Most solutions also utilize a secure delete functionality to ensure that data cleanup is complete and comprehensive, protecting the device from malicious attempts to recover erased data from disks.

5.1.2.7. Stay out of my sandbox

Protected sandboxes (marketed under different names from various vendors) provide complete control over corporate information that's downloaded to a local machine during an SSL VPN session. These client applications create a secure, quarantined environment within which a secure SSL VPN session is completely contained on an end user's PC, limiting the use of downloaded data to only the current SSL VPN session.

The SSL VPN agent creates the sandbox within the user's real desktop after the endpoint integrity agent validates the host integrity of the end user's machine. The sandbox provides a secure environment within which only administrator-specified programs can run and where extremely strict control is enforced over user interactions with the data. In many implementations, the sandbox entirely controls the registry and I/O access of these programs, their network communications, and the interactions with the resources and programs running on the real desktop. Additionally, information stored on the disk or in the registries is encrypted during the session.

At the end of the SSL VPN session, the sandbox is destroyed, and all the information pertaining to the virtual environment is permanently deleted from the endpoint so that any user accessing data from a remote kiosk can be assured that no other user on the shared PC can access the data. The net result is that no data is saved locally, printing and clipboard operations are tightly controlled, and session specific information is securely deleted from the endpoint.

Organizations that have strict information security policies use protected workspaces in kiosk and shared-PC environments. Protected workspaces are typically dynamically downloaded from the SSL VPN gateway and installed on the endpoint when a user initiates a new session.

5.1.3. Remote access policy enforcement

The biggest difference when comparing SSL VPNs to NAC products is policy enforcement. SSL VPN devices require all traffic to transit through the appliance itself, instead of distributing enforcement throughout the network and security infrastructure. Before directly comparing SSL VPN and NAC pros and cons, we discuss the policy enforcement tactics that you can apply with SSL VPNs in the following sections.

5.1.3.1. Clientless SSL VPNs

SSL VPNs were first introduced to the market as a way to consolidate extranet deployment. The value proposition stated that as more and more applications were externalized for outside access, it became more expensive to build up the secure, Internet-facing infrastructure for each Web application. Separate, Internet-facing deployments for each application would require hardening of servers, authentication and authorization on each server, appropriate security infrastructure, and more. SSL VPNs offered the first way to consolidate access to all these types of applications without providing people (such as partners and customers) a full Layer 3 IPSec VPN connection onto the network. Since that time, SSL VPNs have evolved to meet the needs of many more use cases, but the clientless mode of operation remains a primary deployment option, largely because of two key benefits:

• You don't have to install any client software on the endpoint device. So, an end user can access the SSL VPN from anywhere — home, kiosk, Internet cafe, and so on — and still be able to access relevant corporate information, provided that the machine has a Web browser that supports SSL. Platform and device independence is a huge gain over client-based technologies that require a special client installation on every machine.

• Organizations can have a very granular level of control over what the end user can access on the network. In many cases, the administrator can control, down to the individual file or URL level, what the end user can access. So, if a partner needs access to only a single Excel spreadsheet on a file server, SSL VPNs can provide that level of granular access control.

Although clientless SSL VPNs can't handle client-server applications, they generally provide access to a large range of Web-enabled content. Clientless access methods provide Web access to HTML, Javascript, Java applets, Flash, Terminal Services/Citrix, file shares, Outlook Web Access, SharePoint, Lotus iNotes, and much more. Most of today's Web-enabled enterprise applications (whether they're internally developed or commercially available) can work with clientless SSL VPN access methods.

5.1.3.2. Client-based SSL VPN access

Despite SSL VPN's beginnings (and reputation) as a clientless VPN technology, vendors and customers quickly realized the need that exists, and will exist for the foreseeable future, to support full client/server versions of applications. For example, few users rely only on Outlook Web Access and never use the full version of Outlook.

As a result of customer requests for support of full client-server applications, vendors developed client-based technologies that frequently combine some of the advantages of clientless SSL VPNs with some of the functionality provided by traditional IPSec VPNs. Vendors created two main types of SSL VPN clients:

• Layer 3 network-extension clients

• Port forwarding client applications

5.1.3.2.1. Layer 3 network extension clients

Layer 3 clients, offered by every SSL VPN on the market, are very similar to traditional IPSec VPNs in terms of the connectivity that they offer. When a user is granted access through one of these clients, he or she is assigned an IP address and has full network connectivity, short of any access control lists (ACLs) that the administrator puts in place to control that user's connectivity.

The SSL VPN version of a Layer 3 client offers some significant advantages over traditional IPSec VPNs, however. Among the key advantages is the much easier deployment of an SSL VPN client. Installing and configuring IPSec VPNs can be difficult, typically requiring manual intervention to set some of the configuration options. With SSL VPN, however, most offerings provide dynamic delivery of the client itself:

The SSL VPN appliance handles upgrades in a similar fashion — seamless to both the administrator and the end user.

Although most SSL VPNs do offer dynamic delivery and installation, the user typically needs administrator or root privileges on his or her machine to install the appropriate drivers. Many IT shops have locked-down managed endpoints so that end users don't have these types of privileges. Some SSL VPN vendors have responded by creating installer services, which temporarily elevate privileges on the client machine for the purpose of installing or upgrading SSL VPN agents. Administrators can install the installer service as part of the corporate image, allowing the users to upgrade freely without the need for elevated privileges on their accounts.

Many SSL VPNs offer the ability to package their clients into an install package that administrators can push out to endpoint devices via software distribution mechanisms. Make sure that you determine how you plan to resolve any potential challenges, such as lack of administrator privileges, when rolling out an SSL VPN deployment — regardless of whether you use it for

• Internal NAC access

• Its traditional purpose as a remote access control technology

When evaluating SSL VPN solutions (or any NAC offering), make sure to pay attention to cross-platform support. In recent years, many organizations have begun offering more choices to end users in terms of the types of devices that those end users can use to access corporate resources. You certainly don't want to make a large investment in an access control solution only to find out that it doesn't support the Macintosh that the CEO of your company recently purchased.

5.1.3.2.2. Port forwarding client apps

Not all SSL VPNs provide port forwarding technology, but you may see it. Like with the Layer 3 network extension, the port forwarder is a dynamically installed and delivered client application that provides access to full versions of client/server applications.

The primary difference between port forwarding applications and Layer 3 network extenders is that the port forwarder controls access at a more granular level, specifying exactly which resources can access the VPN. With these technologies

In some cases, the port forwarding application can also specify which processes on the client side are allowed to access the tunnel, not only the destination. In other words, you might have a policy that states that only outlook.exe can use the connection, and it can only pass traffic to certain ports on the exchange server. You get a much more granular level of control than a Layer 3 network extender can provide, and depending on your organizational needs, you might use port forwarding for some users and network extension for others. This is a policy choice, not a hard and fast rule:

• Some organizations will want to simplify their policies by providing only one option.

• Other organizations might have specific requirements for each user group, and would want to provide port forwarding for one group, and network extension for others.

For example, the authors have frequently seen organizations provide full network extension for employees, but port forwarding for only a defined set of applications for partners, specifically because their security policies prohibit partners from having full network access.

5.1.3.3. Dynamic access control

One of the advantages of SSL VPNs versus IPSec VPNs is their ability to provide access from any device — any time, anywhere. SSL VPNs simply vary the level of access that the user gets based on administrator-defined policies.

Figure 5-2 shows the ideal user's perspective — logging in from any device, in any location, to perform the same behavior: opening a Web browser and browsing to the URL of the corporate SSL VPN gateway.

• Managed laptop: The user is logging on from her corporate laptop, which is fully patched and up-to-date, and also includes a machine certificate that verifies the machine as a corporate-owned and -managed asset. The user then proceeds to authenticate with her digital certificate and is mapped to a role that the administrator has defined called Managed:

  • Because the user has passed all the pre-authentication endpoint integrity scans and used strong authentication, she's allowed full Layer 3 access via the network extension functionality.

  • Additionally, she has a relatively long timeout and access to corporate file shares.

  As a result, she can use all the client-server applications available on her machine, while also accessing Web applications.

• Home PC: No endpoint security applications are installed on the machine, remediation has failed, and the PC has no machine certificate. Because this machine doesn't have a smart-card reader, the user can't use certificate authentication and must authenticate with his static Active Directory username and password.

  As a result, even though he has performed nearly the same behavior as when using his managed laptop in an effort to log on to the system, the SSL VPN has assigned him to a much more restricted role:

  • He's quarantined inside a protected sandbox and has access to only Web-enabled applications, such as Outlook Web Access.

  • The policy has also determined that he might be coming from a shared machine, so the timeout on his session is very short (30 minutes).

• Mobile device: In this case, the SSL VPN doesn't conduct a host check, and the mobile has no available machine certificate. That said, the IT department has pre-installed a digital certificate on the user's mobile device, so she can authenticate herself by using strong authentication.

  Based on the credentials provided and the type of machine, she's allowed access through the SSL VPN port forwarding application, she can access files, and she can use a variety of client/server and Web-enabled applications.

Figure 5-2 and its access scenarios are indicative of the types of policies that many organizations have put into place for their remote access users by using SSL VPN, and very similar to a typical NAC policy:

• Verifying the user, role, and endpoint integrity status

• Varying the level of access that the user is allowed based on these verifications