Mobile Device Security For Dummies

by Rich Campagna

  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:

  Figure 7-1: Accessing the corporate network from two different mobile devices.

  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 o
f 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.

  Figure 7-2: Enterprise smartphone application adoption.

  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.