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.
Connecting directly to Exchange Server via ActiveSync
While we always recommend use of a VPN, here are a few tips to ensure that your deployment is as secure as possible when connecting directly to Exchange Server.
Remember: Always use SSL encryption (and authentication) for connections between the mail server and the mobile device. You should never allow sensitive corporate data to transit on the Internet unencrypted. If you do not encrypt the connection, your organization’s e-mail will transit the Internet in clear text. If that data is intercepted somehow, such as across an insecure Wi-Fi link that your user has connected to, it can easily be read by the intercepting person.
The Exchange ActiveSync protocols include a number of device security features that you can use to ensure that the data on each device is protected against loss and theft. All of these are best practices and should be implemented in accordance with your existing corporate security policies:
Password complexity policies can be set on the mobile device remotely when it connects to the mail server. For example, you can specify that a password have a minimum length and include a minimum number of alphanumeric characters.
You can set a device lock timer, meaning that once the device has been idle for a certain amount of time, the device will automatically lock, forcing the user to enter the password again in order to access it.
You can ensure that encryption on the device hard disk and removable media is enabled, ensuring that a phone that gets into the wrong hands does not contain easily readable data.
You can remotely wipe a device, either automatically, such as when there have been too many failed password attempts, or by administrative command if the device is lost or stolen.
Ensure that your Microsoft Exchange Server (or other e-mail server) is always properly patched and up to date.
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 o
f 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 v
ersion 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.
Mobile Device Security For Dummies Page 19