Chapter 7

Securing Data in Transit with VPNs

In This Chapter

Understanding the differences between IPSec and SSL VPNs

Identifying and authorizing users

Determining access privileges by device profile

Knowing what applications users want to access

Limiting access to required data and applications

If your organization is like countless others that we’ve worked with, you’ve spent a great deal of time and money over the past several years developing policies and implementing solutions to allow for secure remote access. The ability to work remotely while retaining access to corporate applications has changed when and where people work, resulting in untold productivity gains for everyone from traveling employees (such as executives and salespeople) to folks looking to squeeze a bit more work from their day in the evenings and weekends.

As time has progressed, you’ve no doubt built the infrastructure that allows these levels of productivity, without sacrificing security. The cornerstone of most remote access policies involves use of a virtual private network (VPN) — typically either an SSL (Secure Sockets Layer) VPN or an IPsec VPN — though there are usually other technologies, such as endpoint security solutions and strong authentication technologies, involved as well.

Your VPN purchase decision was probably driven by the need for employees to access the work network from their corporate-owned and -managed Microsoft Windows computers. At most, you might allow them to also access some amount of corporate data via their own PCs or kiosk machines when traveling. Flash forward to today, where you are no doubt hearing overwhelming demand to access these same systems from a range of new mobile devices. Unfortunately, most remote access solutions on the market today do not support mobile devices. If you’re lucky enough to have chosen a VPN solution that fully supports a range of mobile device platforms, you have a step up on some of your peers in the IT world, though possibly there’s still much work to be done to establish best practices and policies for mobile device access inside your organization. If your VPN solution doesn’t support mobile device platforms, fear not; plenty of vendors are building products for exactly this purpose, and their salespeople are no doubt already beating down your door asking you to take out your checkbook.

This chapter focuses on remote access technologies that you can use to secure mobile device access to the corporate network. It explores user identity and machine compliance and their role in developing a secure remote access strategy for mobile devices in your network.

Comparing IPSec VPNs and SSL VPNs

Two types of VPNs represent the majority of global remote access use cases: IPsec and SSL. Depending on what your vendor provides, and your company’s policy requirements, either type might work as you extend remote access to smartphones.

To understand the similarities and differences between IPsec and SSL VPNs, you need to understand VPNs in general. VPNs allow ways to transmit sensitive data across shared networks without it being intercepted or stolen. VPNs were initially designed to service site-to-site networks. Before the availability of VPN solutions, organizations relied on expensive, leased point-to-point data circuits, such as T-1 lines leased from the major telecommunications providers, or shared but still relatively expensive technologies such as Frame Relay. By using a VPN, organizations can enjoy the benefits of shared networks, without the security concerns that are typically associated with transmitting data over the Internet. A VPN provides encryption for traffic as it traverses the Internet, ensuring that this traffic is just as secure as if that traffic were to traverse a separate point-to-point connection.

Site-to-site VPNs are responsible for authentication (identifying users or machines attempting to establish a VPN connection), encryption (to ensure that any intercepted traffic can’t be read), and integrity mechanisms (to ensure that traffic isn’t tampered with while in transit).

Over time, VPNs were adapted to be used by remote workers. When applying VPN to remote-worker use, many of the concepts and protocols from site-to-site VPN connections remain the same: authentication, encryption, and integrity mechanisms.

IPsec and SSL VPNs make up the majority of today’s enterprise remote access deployments. Here is how the security protocols work for each type of VPN:

IPsec VPNs provide a secure, network-layer (Layer 3) connection to the corporate network. As data traverses the Internet from the mobile device to the VPN gateway, it is encapsulated and encrypted. After the traffic passes through the VPN gateway and onto the LAN, it is no different from traffic coming directly from end users on the LAN. The result is access that is very similar to access that a user would get when physically connected in their own office: full connectivity to all resources and applications. Of course, this level of access isn’t without its disadvantages.

For example, your organization might not want to allow a user on a mobile device access to all enterprise applications if all that user really needs is the ability to check her e-mail from her mobile device. By limiting access to specific applications, you can control the potential risks associated with providing more complete access from a compromised or insecure machine.

SSL VPNs, the type of VPN most commonly deployed for new enterprise remote access deployments, can almost always provide the same Layer 3 VPN capabilities that are provided with IPsec VPNs, while also providing the additional control necessary to restrict access for users or groups of users. As an example, a user attempting to access the corporate network from a company-owned Microsoft Windows laptop, with all the required security fixes and patches, might be an ideal candidate for full Layer 3 access to the corporate network. That same user attempting to access from his personally owned Apple iPhone, on the other hand, might be subject to stricter controls that allow him access to only a few selected web-based applications and e-mail. An SSL VPN allows for this additional control and enables you to prohibit more permissive access, should you deem it necessary.

Of course, whether you have an IPsec VPN or an SSL VPN, platform support is a key requirement. Not every vendor supports every mobile platform available, so it’s a good idea to work with the vendor of your VPN gateway to determine whether the existing product supports the types of mobile devices that you plan to provide access to. In many cases, the vendor needs to build and support a client application on the endpoint device; this challenge really adds up across several popular platforms, so the vendor might not support everything out there.

Validating User Identity for VPN Access

Before you allow access to the corporate network from any device, you should first identify the user attempting to access the corporate network. Organizations typically view user identity validation as two distinct pieces: user authentication and user authorization.

Here is a description of user authentication and user authorization:

User authentication involves validating that a user truly is who she says she is. In other words, user authentication proves that the person attempting to log in to the VPN as SueB really is Sue Berks, and not Joe Hacker.

User authorization is another important part of the user identity process. User authorization typically involves determining a user’s role or job function in the organization, for the purpose of granting him access to a particular set of data and applications.

In the sections that follow, we take a closer look at both of these areas of user identity validation.

Authenticating VPN users

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

As with many security technologies, a range of security strengths are offered through these various solutions. Organizations that are very security conscious typically use a strong authentication solution such as a one-time password system or X.509 digital certificates. The use of strong authentication has become very popular in recent years; we recommend it as a best practice for all organizations. Less security-conscious organizations stick with static username and password systems for remote user authentication.

If you deploy systems using static credentials, we strongly recommend the use of password policies and user training that minimizes the risk of stolen or easily guessed passwords. Password policies include enforcing a minimum password length and a certain number of numeric or special characters. We also advocate implementing technologies that prohibit the use of common words or names in passwords, force user password changes on a periodic basis, and limit reuse of prior passwords.

All the fancy technology in the world will do no good if your end users routinely place sticky notes with their passwords written on them under their computers, so constantly remind and train your end users on the risks associated with bad practices and poor passwords. Or better yet, stick with our recommendations and implement a strong authentication system.

Local authentication

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

Most 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.

Lightweight Directory Access Protocol (LDAP)

LDAP (Lightweight Directory Access Protocol) is a standard protocol for querying a directory database and updating database records. As one of the more commonly used interfaces in VPN deployments, LDAP acts as the protocol of choice for querying many types of databases, including Active Directory.

Active Directory (AD)

Active Directory is one of the leading directory servers, and most organizations deploy it, to some extent. Many 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.

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, replacing static usernames and passwords in many organizations. Like with digital certificates, a number of technologies have evolved that make it far easier and less expensive to activate and manage one-time password solutions, and organizations have adopted these technologies as a result of those developments.

Most 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 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.

X.509 certificate authentication

In recent years, X.509 digital certificates have become more popular as an authentication method. They’re issued by several trusted certificate authorities (CAs) to organizations and end users. These CAs hold the power to revoke these certificates at any time. Because they’re 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 deployments within the U.S. Government have 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 have improved significantly in recent years, making deployment and ongoing administration much simpler.

When a 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 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 VPN might also retrieve user attributes from the certificate so that the VPN access control system can compare those attributes to attributes in a directory, for example, or map users to specific roles in the VPN implementation. Most VPNs also allow the administrator to specify which certificate authorities (CAs) will result in a successful authentication.

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 who are already logged in to other systems the ability to seamlessly log in to the SSL VPN system as needed. SAML authentication solutions aren’t usually associated with IPsec VPNs because they are primarily a web-based authentication system leveraging Internet browsers, not an area typically associated with IPsec VPNs.

You can find a variety of identity and access-management platforms available that support SAML. In most SSL VPN deployments that use SAML, the primary use case is SSO to SSL VPN–protected resources and applications, not signing in to the SSL VPN itself. So not many enterprises have used this authentication method, in our experience.

Determining a user’s role

User authentication is only one piece of the puzzle in identifying and providing appropriate access to users. Another piece is authorization. Authorization maps information about a user to the credentials provided at login.

In some cases, the relevant information is stored in the authentication request. For example, an X.509 digital certificate or a SAML assertion might contain information that allows the VPN to do the appropriate role mapping. In other cases, however, the 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 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.

Discriminating by Device Profile

Over time, many organizations have built policies that allow them to discriminate between various device types and device security posture levels in order to set an appropriate level of access for a particular session. For example, a user attempting to access the network from an appropriately protected and registered mobile device might be granted full network access, whereas a user attempting to connect from an unknown mobile device might have her data and application access severely restricted. Or that user might not be able to access the network at all until she follows the appropriate steps to make the device compliant.

In order to discriminate between devices with varying security posture levels, it is crucial to validate the endpoint machine prior to allowing the user to connect to the network in a remote-access setting.

Note that at the time of this writing, very few VPN products offer a solution to the challenges outlined in this section, but it is anticipated that additional vendors will attempt to solve these challenges for their customers in the near future. Additionally, commercially available IPsec VPN products don’t provide any feature sets for device security posture profiling, so commercially available solutions are restricted only to SSL VPN products.

Figure 7-1 shows a typical scenario where access controls are applied based on the device and the device security posture. 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, as detailed in the following list:

Corporate-managed or patched mobile device: In this case, the user is attempting to access the network from an Android OS device that is registered and has been provided by the organization. Antivirus and personal firewall software is installed on the device, and the organization can remotely wipe and track the device should it become lost or stolen.

Based on this device information, and on the user’s authentication with a one-time password, the managed role applies for this particular session. Because the user is coming from what appears to be a managed device that meets all the security requirements, the user is granted full, Layer 3 network access. Along with that access comes the ability to reach all applications, an experience not unlike the experience that users receive when they are in their offices accessing the network from their managed laptops.

Personal mobile device: In this example, the user is attempting to access the network from an Android OS device, but this time, it is the user’s own personal device that she brought from home. In this case, no endpoint security software is installed, and the device hasn’t been registered, so the organization doesn’t have the capability to remotely wipe the device or track it if it’s lost or stolen.

Based on this device information, and on the user’s authentication, the unmanaged role applies for this particular session. In this case, the user has access to far fewer applications and resources than she had when accessing the network from the corporate-managed device. Here, she can access only a select few web-based applications, she has no ability to access corporate file shares, and only a very short network inactivity timeout is employed to help guard against loss or theft because the IT admin can’t provide these protections on this particular device.

In actuality, you will likely have several different policies for different device types, so Figure 7-1 is a more simplistic picture than what you will end up with. But it does illustrate what you can do with currently available technology.

Profiling devices and applying policies

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 the mobile devices that you are allowing access to the corporate network have a security posture and device identity that allow you to feel comfortable allowing the device onto the network.

In many cases, your VPN vendor has already done much of the legwork for you and has created a list of predefined security policies that you can easily implement to scan for this assurance. Note that as of press time, only a few VPN vendors, all of them SSL VPN vendors, provide assurance that these types of solutions are in place. Likely, more will add such capabilities over time as smartphone adoption in the enterprise continues to increase in popularity.

Look for these common policy types provided by VPN vendors:

Device type: Device type scans allow you to identify what type of device is connecting, or attempting to connect, to the VPN. In some cases, you simply want to restrict access to certain types of phones. For example, you might have standardized Google Android as your smartphone operating system platform, so you want to ensure that only Google Android devices connect to your corporate network. In other cases, you might want to scan for a particular version of an operating system or device type. For example, you might know that version X.2 of a vendor’s operating system has some critical vulnerabilities, so you want to ensure that no device running that particular version of the operating system connects to the network.

Device type scans also help you determine any additional scans that you might want to run against a particular device. For example, you might have chosen a different antivirus/antimalware application for Android devices than for Symbian devices. Knowing the device type up front allows you to scan for the appropriate antivirus application when the device attempts to connect to the network.

Antivirus: As discussed throughout this book, viruses, malware, and other types of exploits against smartphones are on the rise. Industry best practices for mobile device access are quickly settling on antivirus as a required application for the smartphone. Therefore, the ability to scan to ensure that an antivirus application is not only installed on the device, but also running and up to date, is becoming a key feature for many VPNs that provide endpoint integrity scanning.

Most SSL VPN vendors offer a solution that checks not only whether the machine has an antivirus application installed but also whether it’s 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.)

Personal firewall: This type of scan is fairly self-explanatory. Simply put, it determines whether a personal firewall is installed and running on the endpoint device. As firewalls increase in popularity for mobile devices, additional VPN vendors will begin to offer the capability to check for these important pieces of security software.

Disk encryption: This functionality helps you determine whether encryption is enabled on the endpoint device. If you’re familiar with encryption on traditional laptop and desktop machines, note that in the case of mobile devices, many of the device vendors have provided native encryption capabilities on the devices themselves, alleviating the need for third-party encryption products. In most cases, these encryption policies allow you to scan for whether encryption is enabled both on the embedded device disk and on removable media, such as SIM cards.

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

Bluetooth: Because a number of device exploits take advantage of Bluetooth capabilities on mobile devices (see Chapter 2), the ability to determine whether Bluetooth is enabled is important for some organizations.

Device lock: This type of scan allows you to determine whether the appropriate idle timeout and lock policies are enabled on the device.

SIM policies: You enable this type of policy to check whether the SIM card is PIN protected, and whether it is locked to the phone itself, helping to guard against theft.

An example of the type of mobile device integrity policy that you might see enabled on an SSL VPN gateway in a typical enterprise network is shown in Table 7-1. Note that this is an example, not necessarily all-inclusive or representative of best practices across every area.

Providing access based on device profile

Over time, many organizations have built access policies for traditional laptop and desktop platforms based on whether devices are known and/or managed:

A known device is typically defined as a device that belongs to a particular user, and it is expected that when the user attempts to access the network, she will do so using the known device or devices associated with her profile.

A managed device is also a known device, but typically, being managed means that the organization has more control over the device, and usually, it is a device that is owned and provisioned by the organization.

In the PC world, machine certificates have arisen as a very popular way to determine that a device belongs to the organization or falls into the managed category. Unfortunately, machine certificates have not yet made their way to most mobile platforms. Today, most organizations that wish to differentiate between known versus unknown and managed versus unmanaged mobile devices attempt to do so by verifying the International Mobile Equipment Identity, or IMEI number.

IMEI numbers are typically used by mobile operators to track devices and prevent use of stolen devices on the network. The number is unique to each device, so it can be leveraged to ensure that a device falls into a particular category before allowing access.

Note that the IMEI number identifies only the device, not the user, so in order to make use of this method of device identification, you must first ask your users to register their devices for enterprise use. This process typically involves the provisioning of the device into a corporate directory database so that the IMEI information can be retrieved at login time and associated with the user’s profile to ensure a match.

Implementing custom policies

In some cases, organizations will have other things that they want to scan for on certain mobile devices, things that fall outside the capabilities provided by your VPN vendor. For example, you might want to scan to ensure that a particular application is installed on a device. Or you might want to ensure that an additional endpoint security application is installed and available. In the world of Microsoft Windows and Apple Mac laptops and desktops, this type of challenge is easily overcome. SSL VPN vendors offer a range of custom policies that allow you to search for files, processes, registry settings, and any number of additional attributes that allow you to identify these additional applications.

On smartphones, however, the challenge is much greater. A Microsoft Windows Mobile/Windows Phone smartphone is very similar to a normal Microsoft Windows machine from that perspective. Outside of that platform, however, your ability to check these various functions is difficult or even impossible. Many smartphones have implemented sandboxing functionality that severely restricts each application’s access to the file system and to other applications running on the device. This effectively renders these custom checks impossible without some level of vendor support. Our prediction is that it will be quite some time before these capabilities that you already enjoy on Windows, Mac, and Linux systems make their way to the myriad smartphone platforms available in the market.

Providing Application Access

Before launching into a discussion on how VPNs can provide for granular access control to corporate networks, it’s important to understand what you are providing access to. What are the types of applications that end users want or need to access on their smartphones? In our experience, many (though certainly not all) organizations have followed a similar curve in terms of application adoption for smartphones. Figure 7-2 illustrates how this works, and in this section, we discuss each of these types of applications and talk about their implications on security and VPN access.

Enabling access to e-mail

One of first things that many people do when they go out and buy that shiny new smartphone is try to figure out how to access their e-mail, calendar, and contacts. E-mail is a critical communications function in today’s corporate world, and it seems that any time the e-mail system goes down, productivity plummets. Correspondingly, it simply makes sense that e-mail and messaging functions rank high in smartphone users’ minds. If you can’t provide end users access to their e-mail, they aren’t likely to be very productive with their smartphones.

When today’s smartphone platforms first started to become enormously popular, led by the popularity of the Apple iPhone, organizations started to bypass their own security policies in order to provide access to corporate e-mail. The story usually goes something like, “We never provided remote access for these smartphones until the day our CEO bought an iPhone and demanded access. Two months later, we checked our logs and determined that 2,000 people were now accessing our e-mail systems via smartphones using the same mechanisms that we provided to the CEO.”

As smartphones have ushered in this era of end user choice, it’s common to hear stories like that one. Unfortunately, many organizations have provided access to critical information — corporate e-mail — without proper regard for how to do so securely. Due to a lack of vendor solutions for this problem, and in many cases a lack of funds, access has been provided in a haphazard fashion.

Many enterprises require use of a VPN, strong authentication (such as a one-time password or a digital certificate), and a properly patched device in order to provide access to a managed laptop such as a Windows machine. Those same organizations provide access via smartphones with no VPN (by allowing their mail servers to be accessed directly), no strong authentication (and sometimes from devices with no timeout or lock password!), and no idea whether the end device is secured. The same security policies that they’ve spent years developing and refining have been thrown out the window in order to provide access for smartphones.

At the end of this chapter, in the section “Securely accessing e-mail, calendar, and contacts,” we discuss some ways that you can provide this access, but do so securely using VPNs.

Providing Web application access

As organizations get more comfortable with the idea of providing access for smartphones, they typically start to look for ways to increase their usefulness as productivity tools by providing access to a broader range of applications. The second major category of application that enterprises typically adopt and roll out is web-based applications. Today’s smartphones have very powerful Internet browsers and offer an experience not terribly different from that offered on traditional laptops and desktops. At the same time, many website and web application vendors have started to provide customized versions of their web applications that are better suited to smaller mobile device form factors.

So what are these applications that enterprise end users are accessing? The answer is that it varies widely, but fair game are any of those web applications you’ve deployed in your network that are considered critical for remote access. For some organizations, this means access to the intranet, or perhaps human resources and people-related applications related to expense reports and paychecks. For other organizations, this might mean access to mission-critical information such as web-based customer relationship management (CRM) tools and product or service information. Whatever the case, we describe how to provide access to these web-based applications in the section “Accessing web-based applications,” later in this chapter.

Accessing full client/server applications

At the end of the application adoption curve is access to full, installed applications on the smartphone. These differ from web-based applications in that these applications are not accessed directly from a web browser, but rather, they are installed directly on the phone itself. In some cases, these applications are retrieved directly from the operating system vendor’s application store, but as of this writing, these vendors are beginning to give enterprises tools that they can use to author and deploy their own applications from enterprise app stores.

Regardless of how the application is deployed to the device, these applications are important because they can currently provide a richer end-user experience than most web-based applications can provide. In addition, they are convenient. A simple button on the smartphone home page launches the application. As with web-based applications, the types of full applications leveraged by organizations run the gamut from fully installed CRM applications to applications that allow doctors to remotely view X-rays and patient medical records, for example. Across all of these types of applications, one commonality is that enterprises want to ensure that the data access through them is provided securely, and in the section “Allowing users to leverage client/server applications,” later in this chapter, we show you how to do exactly that.

Providing Users an Appropriate Level of Access

After you know what end users will want to access, it’s important to think about how the various levels of access can be provided. This section discusses e-mail access, web-application access, and full application access, and how the two most popular types of VPNs — IPsec and SSL — can help you meet those needs.

Securely accessing e-mail, calendar, and contacts

As discussed earlier, e-mail, calendar, and contacts are among the first applications that end users wish to access from their smartphones. Every major modern smartphone platform supports a set of protocols known as Exchange ActiveSync, a proprietary Microsoft protocol that allows for this same mail, calendar, and contact data to be transmitted between mobile device clients and a mail server. In many cases, that mail server happens to be a Microsoft Exchange server, but several other mail servers also support the Exchange ActiveSync protocol.

In order to provide access, many enterprises have simply deployed their mail servers so that they are externally reachable from the Internet, with the devices connecting directly to the server. There are advantages and disadvantages to using this approach. One major downside is that deploying the mail server on the DMZ exposes a very important asset — your corporate e-mail — as a target to the Internet. For this reason, we recommend, as a best practice, that organizations use a dedicated VPN for even basic e-mail access. On the other hand, there is no need to deploy any software on the mobile device in order to make this work because the major smartphone operating systems already support the ActiveSync protocols.

This section describes the use of a VPN as a proxy for Exchange ActiveSync traffic. If you have already decided to allow mobile devices to connect directly with the Exchange Server, however, check out the nearby sidebar, “Connecting directly to Exchange Server via ActiveSync.”

Some vendor SSL VPNs allow your organization to proxy ActiveSync traffic without deploying any software onto the endpoint device. From a feature and user-experience perspective, this approach is no different from an approach where the end user connects directly to the mail server. On the other hand, the following benefits are associated with taking this proxy approach:

A VPN gateway is purpose-built to be hardened and secured. These types of devices are specifically built and designed to be accessible from the Internet. As such, they have typically gone through numerous security audits, are regularly patched and updated, and have built-in protections against attacks that are generally faced by Internet-facing devices.

VPN gateways support strong authentication. If your organization operates like a lot of others, you want to use strong authentication, such as one-time passwords or X.509 digital certificates, to identify users connecting to your network. VPN gateways support this functionality natively, so there is no need to provide alternate authentication mechanisms for your mobile device deployment.

The VPN approach allows you to standardize on a single platform for all of your remote access needs. Because you are likely already using this type of gateway for access from traditional devices, you can ensure that all remote access into your network leverages a single termination point, simultaneously simplifying operations and reducing the number of devices you have exposed to the Internet.

Leveraging a VPN gateway today allows you to expand your scope as you support additional mobile device applications. Because these devices support the ability to provide access to several different types of applications — as your mobile device deployment grows in size and becomes more strategic — you can include additional applications with the initial VPN gateway without swapping out or providing additional termination points in the future.

Accessing web-based applications

There are a number of ways to provide secure access to web-based applications, but for remote access to enterprise applications, one of the most common methods in use today is SSL, typically through an SSL VPN gateway.

Many web-based applications have built-in support for SSL termination and user authentication, but the problem that this chapter addresses is access to several applications, as in a typical enterprise intranet type of scenario. In this case, an organization could go through the expense of hardening and securing each application, providing authentication mechanisms and building an Internet-facing presence for each application, or the organization could use an SSL VPN to achieve this goal.

In fact, SSL VPNs were first brought to market for this very purpose, consolidating multiple web-based applications into a single Internet-facing portal. (They have since evolved to solve many different remote-access tasks within an organization, as described elsewhere in this chapter.) As an ever-increasing number of applications were moving to the web, the task of preparing each application for access from the Internet was increasing operational costs. SSL VPNs provided a way to simplify and consolidate. At the same time, they provided a way to provide access to third parties (partners and customers, primarily) without leveraging a full Layer 3 IPsec VPN connection onto the network.

This web-based mode of operation is sometimes referred to as a clientless VPN, acknowledging the fact that no client software needs to be installed on the endpoint device. Clientless SSL VPN functionality leverages only a web browser on the endpoint device, making it a ubiquitously available application, not only for traditional platforms, but also for a wide range of mobile devices. Clientless modes of operation on SSL VPNs remain a widely used deployment, largely due to these two key benefits:

No software is required on the endpoint device. This simple fact makes SSL VPNs a perfect choice for access from any device. An end user can use an SSL VPN to access corporate data from his home machine, a kiosk, a mobile device, or really any machine with a web browser that supports SSL. As an added benefit, vendors have recently begun adding a range of features that allow the SSL VPN to optimize web-based application access for the smaller screen sizes typically found on mobile devices. This doesn’t make access from these devices more secure, but the resized web applications and websites definitely improve the user experience.

Clientless SSL VPN solutions provide very granular control over end user access. Because many organizations are only just beginning to embrace the use of mobile devices, and because many of them have yet to roll out some of the security and protection mechanisms described throughout the rest of this book, providing tight control over what a user can access is an attractive value proposition.

In many clientless SSL VPN implementations, web-based application access can be controlled all the way down to the individual file or URL level. So if a remote user should have access to only one particular file or application, leveraging an SSL VPN can ensure that the remote user can’t see or access any other applications in the corporate network.

How does the clientless mode of operation work? It depends on the implementation, and most vendors have developed this key intellectual property over time. For the most part, clientless SSL VPNs use something called a rewriter, which actually intermediates every request and response that goes through the SSL VPN, and modifies embedded links so that, to the outside world, the content appears to be served directly from the SSL VPN.

This rewriting capability provides granular access control and, at the same time, allows organizations to mask the details of their internal application deployments from would-be hackers. If a hacker can easily get the IP address or URL of an application server that’s housed inside the network, he or she can begin to formulate a plan for attacking that server, a less-than-desirable outcome for your network.

One of the downsides of a clientless SSL VPN is that this type of access method does not allow users to access fully installed, client-server applications. They really can handle only web-based application traffic. For providing secure remote access to client-server applications, a client application that provides a tunnel into the corporate network is required. We show you those solutions in the next section.

Allowing users to leverage client/server applications

As described in the earlier section, “Accessing full client/server applications,” the number of organizations providing access to fully installed client-server applications from mobile devices is growing with every passing day. Despite predictions over the years that eventually all applications will be web-based applications, those days are still a long way out (if they ever arrive), so a solution is required to provide a secure tunneling mechanism for data from these applications destined for the corporate network.

In this section, we discuss three main types of VPN clients that accomplish this task of tunneling client-server applications. With many of these technologies, vendors have developed client-based technologies that frequently combine some of the advantages of clientless SSL VPNs with some of the access required for these types of applications. Here are the three main types of clients that we discuss:

IPsec VPN Layer 3 network-extension clients

SSL VPN Layer 3 network-extension clients

SSL VPN Port forwarding client applications

Although most SSL VPNs and some IPsec VPNs do offer dynamic delivery and installation of client software, there will be limitations on dynamic delivery depending on the smartphone platform. For example, as of Apple iOS 4.3 (currently shipping at press time), there is no way to dynamically provision software to an iPhone. As a result, the process requires that end users first visit the Apple App Store and download the VPN client. From there, they need to point the client to the appropriate VPN gateway, typically by inputting a URL or address. Users then provide their credentials, and the VPN connects. This isn’t a terrible end user experience, but it’s definitely a far cry from the dynamic deployment methodologies that many organizations have gotten used to leveraging over the past few years.

Using IPSec VPN clients to provide full Layer 3 connectivity

IPsec VPN clients provide a full, Layer 3 connection to the corporate network. Up until the mid-2000s, IPsec VPNs were the primary method of remote access. Today, many mobile devices include an embedded IPsec VPN client, providing a bit of a renaissance for remote access IPsec VPNs. (They have remained popular for site-to-site VPNs since their inception.)

Regardless of whether the IPsec client is embedded or a third-party application is installed on the mobile device, IPsec VPNs provide the LAN-like connectivity required to support the broadest possible range of applications on a mobile device. From web-based applications to very advanced multimedia applications such as Voice over IP and video, IPsec VPNs provide a mechanism by which an organization can securely tunnel some or all of the data from a mobile device through the corporate network.

IPsec VPNs have become less popular for remote access because deployment of client software has historically been a challenge, and because IPsec VPNs provide only one type of access: full Layer 3 connectivity into the network. In many cases, this level of connectivity is simply overkill and exposes more information than is required to the end users. It is always a best practice to limit access only to that which is absolutely required for a given user or group of users.

Over the last couple of years, several IPsec VPN vendors have begun to add technology that allows for easier deployment of client software, using mechanisms traditionally employed with SSL VPNs. Additionally, as mentioned before, a number of modern smartphone platforms offer embedded IPsec VPN support, obviating the need for a client. It’s always a good idea to take a survey of both your short-term and long-term requirements and choose a VPN technology that meets all of those needs, across all the client platforms that you anticipate allowing into your network.

Leveraging SSL VPN 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, LAN-like network connectivity.

Connecting through a full Layer 3 SSL VPN client gives the user the same type of experience that he or she has when connecting through an IPsec VPN or attaching directly to the LAN itself.

The SSL VPN version of a Layer 3 client offers some significant advantages over traditional IPsec VPNs. 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. When the user first needs to log in to the SSL VPN appliance, he or she browses to the appropriate URL.

After the authentication and authorization process has been completed by the SSL VPN, if the policy states that the user should have full Layer 3 access, the client is dynamically delivered and installed on the user’s machine with no intervention required on the administrator’s part. The SSL VPN appliance handles upgrades in a similar fashion, seamless to both the administrator and the end user.

When evaluating mobile device VPN solutions, make sure to pay attention to platform support. Especially during the early days of your mobile device deployment, you might have opinions on certain platforms that will change over time. For example, you might think that you can restrict access to only Apple iPhone and Google Android platforms, so you select a VPN that provides VPN clients for these devices only. Then, along comes a new platform that rockets to the top in terms of popularity. If your vendor doesn’t respond to provide access to this platform, you’re going to be stuck deploying another VPN.

Ensure not only that your vendor provides adequate support for current-generation platforms, but also that the vendor is committed to staying ahead of the curve with new devices and platforms as they’re introduced to the market.

Using SSL VPN and port-forwarding client applications

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, the application believes that the client application is the destination application server. The client then intercepts this traffic and forwards it to the SSL VPN appliance over the secure connection, where it’s then forwarded to the final destination, the application server.

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 Mobile Outlook can use the connection, and it can only pass traffic to certain ports on the Microsoft Exchange messaging 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 rather than a hard-and-fast rule. For example, we frequently see 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.

Note that port-forwarding applications have yet to really take off in the mobile device market, so very few vendors provide this type of solution for smartphone platforms. It is likely that you might find this solution for one or two smartphone platforms, but not for all. A Layer 3 VPN — either SSL or IPsec VPN — will likely be the only choice that you have for access across the wide range of smartphones that your organization might want to allow onto the network.

Case Study: AcmeGizmo SSL VPN Rollout for Smartphones

Returning to our ongoing case study on AcmeGizmo, Ivan, the IT manager, is at the point where he wants to start exploring how to securely connect employee mobile devices to the corporate network and protect sensitive data as it transits the Internet.

Recall from Chapter 1 that AcmeGizmo currently offers three mechanisms for connecting into corporate from any device. Users on corporate-issued BlackBerry devices connect to the network via AcmeGizmo’s BlackBerry Enterprise Server. Users on corporate-issued Windows laptops connect to the network via an IPsec VPN solution from a company called Connect PC. Finally, Ivan recently began to allow a select group of mobile devices to connect directly to the corporate mail server, though he has discovered that the word has gotten around and, to his surprise, over 500 devices are now connecting via this mechanism. Figure 7-3 shows the current remote access strategy at AcmeGizmo.

While in the process of securing his mobile device remote access deployment, Ivan would like to consolidate remote access to fewer appliances in the corporate data center. His rationale is that this will help reduce management and administration overhead, while simultaneously lessening the probability that a misconfiguration or vulnerability will result in data theft.

Three primary groups of employees (a general group, executives, and salespeople) need Ivan to provide them with mobile device access to the network. Each requested access to different sets of applications and data. Ivan’s challenge is to put into place a strategy that serves all of these employees across the different sets of devices that they wish to bring into the network.

Employee authentication

Ever since he found an employee’s password affixed via a sticky note to the bottom of an AcmeGizmo laptop, Ivan has been considering a stronger authentication solution than the standard username and password requirement that AcmeGizmo has been using for years. He has decided that he will employ a stronger authentication solution for all employees as he makes the transition to the new remote access strategy.

The new policy will be that all users accessing the AcmeGizmo corporate network from outside the local area network (LAN) must use the two-factor authentication solution that he has purchased. Based on preference, some employees will carry with them a hardware token that updates automatically every 60 seconds with the newest one-time password. Other employees will not need to carry a token, but instead will be sent a text message when they attempt to log in to the corporate network remotely. That text message includes the one-time password.

Each employee enters his username, personal identification number (PIN), and the current token in order to authenticate to the network from any device. When the employee is authenticated, the new remote access system also queries AcmeGizmo’s Active Directory (AD) server in order to determine which group(s) are assigned to that employee (Executives, Enterprise Sales, or the general Employees group). This helps the remote access system determine the level and type of access each specific user will get.

Accessing the network with SSL VPN

Ivan took a look at the various VPN offerings available and decided to purchase an SSL VPN from Juniper Networks since it integrates with the endpoint security solution for mobile devices that he is also looking at from the same company.

Ivan decided that all remote access users from Windows laptops and Apple iOS, Google Android, Nokia Symbian, and Windows Phone devices will access the corporate network through the SSL VPN. The only device type in the AcmeGizmo network that will not leverage the SSL VPN is the existing BlackBerry devices. Ivan recognizes that the BlackBerry Enterprise Server (BES) that’s already deployed in the network is a feature-rich and secure single-platform solution. Rather than remove the BES and migrate all the existing users, he has decided he will continue to leverage the deployment that is up and running. Ivan also has to ban any device types other than the aforementioned devices from the corporate network.

On the device itself, all employees will be asked to download the Junos Pulse client software. In some cases, this is deployed to the device via a text message sent to the device upon registration. In other cases, the employee downloads the software from the application store for their particular device. Regardless, this endpoint software is the single agent that Ivan needs to ensure resides on each device.

When attempting to connect to the network via Junos Pulse, each user is prompted for his username, PIN, and one-time password, as described previously. From there, the SSL VPN groups that user into one of three roles and assigns them the appropriate level of access.

General employee access

In the past, most employees were not provided with a corporate-issued BlackBerry, so they didn’t have access to their e-mail, calendar, and contacts when not in front of their laptops. Ivan’s boss, Steve, however, feels strongly that allowing this level of access could boost productivity across the company, so he has informed Ivan that he would like to figure out a strategy that will allow all employees to access their e-mail, calendar, and contacts, but restrict access to everything else from their mobile devices. These employees don’t need to download and install Junos Pulse on their devices. Instead, they leverage the native configuration in their smartphones to have them connect directly to the SSL VPN appliance via the ActiveSync proxy functionality, which will secure the connection and provide a very limited access for these employees.

Executive access

The executives within AcmeGizmo who wish to access corporate data require access to a wide range of applications. E-mail, calendar, and contacts are, of course, critical for each of them to have access to. Beyond that, they require access to several sites on the AcmeGizmo intranet, as well as access to several applications that have been purpose-built for smartphones, including the company’s customer relationship management (CRM) application.

As with the other groups of employees, each executive has Junos Pulse installed on his or her machine. When the executive logs into Junos Pulse, the software determines that the person in question is in the Executives group and provisions a full Layer 3 SSL VPN tunnel into the corporate network. This ensures that each executive has access to all aspects of the AcmeGizmo network. In fact, the full Layer 3 access provides an experience similar to the experience that the executive has when accessing the corporate network from his or her Windows laptop on the corporate LAN.

Enterprise Sales access

The Enterprise Sales team has only a very specific access need above and beyond what the general employee group requires. These employees require access to the intranet and the company’s CRM application, both of which are web-based applications based through the company intranet. As with the executives, these employees have Junos Pulse installed on their mobile devices. When they log in using their one-time passwords, the SSL VPN system identifies them as a Sales user, automatically provisioning access to their e-mail, calendar, and contacts; but it also provisions bookmarks in Junos Pulse, pointing them to both the intranet and the CRM site by leveraging the rewriter function in the SSL VPN.

Figure 7-4 shows the new AcmeGizmo remote access deployment. As you can see, in addition to making strong authentication a mandatory part of access into the AcmeGizmo network, Ivan has been able to consolidate the number of entry points into the network, and also remove the e-mail server from the demilitarized zone (DMZ).