In this section, we explore what policies might make sense if you’re required to comply with strict requirements controlling the data and applications on your corporate-owned mobile devices.
Here are the various types of contents on smartphones that are liable to being controlled for compliance purposes:
SMS messages
Contacts
Photos
Videos
List of apps installed
Controlling these types of data involves sending copies of the data to the central management console. From that console, an administrator can analyze the types of messages being received on devices that are used within the corporate network, or the photos that are being taken on them, or the applications that are installed on them.
You can restrict the apps installed on smartphones within the work environment to a list of corporate-approved apps. For example, your company may decide that the Facebook app should not be installed on any smartphone that is used for work-related purposes, such as checking e-mail.
For compliance purposes, any of the previous types of data could provide forensic information, if it were needed to analyze the causes of a data breach. But again, it might not be required (or even legal!) in your company, depending upon the industry type, geographic location, and federal or local laws.
In addition, the nuances of personal and corporate-owned devices may provide a distinction between the types of content that are allowed to be inspected. For example, in many companies in the U.S., employees would balk at their employer inspecting and controlling their photos, videos, and contacts. This is an example of a compliance policy that may differ in nature, depending on the type of employer, industry, or location of the company.
Table 6-9 summarizes the monitoring and control policies for smartphone compliance in a corporate environment.
Case Study: AcmeGizmo Compliance Requirements
On a typical day, any number of employees will have purchased new, personally-owned devices and want to get access to AcmeGizmo corporate data and applications from those devices. Consider a scenario where Fred from the Finance department has recently purchased a new Samsung Galaxy S II Android smartphone and wants to access his e-mail and a few select applications from that device. Follow along as Ivan the IT manager determines whether he can approve this device and user for network access.
Operating system compliance
Ivan’s first step is to determine whether this new device is in compliance with the company’s list of approved devices and operating systems. The policy states that all Android devices must run version 2.2 or newer. Because Fred’s device is running Android OS version 2.3, Ivan is satisfied that it meets AcmeGizmo’s policy.
Password compliance
Ivan also needs to ensure that this device has an appropriate password policy. Rather than checking the device configuration, Ivan deploys a policy to the device via AcmeGizmo’s mobile device management solution.
Fred receives an e-mail with instructions to browse to a site and perform some registration-related tasks, and then the device management profile is deployed to his new device. This profile configures the password policy restrictions on Fred’s device, ensuring that he sets a lock password that meets with AcmeGizmo’s corporate security policy.
Encryption compliance
Ivan must also check to ensure that the device has encryption enabled. This particular device, the Samsung Galaxy S II, has been targeted toward the prosumer (professional consumer) and corporate markets, and it has native encryption functionality (even though the base Android 2.3 operating system doesn’t).
Ivan simply uses the same mobile device management profile deployed to adjust the password settings to ensure that the encryption on this device is enabled. In fact, the encryption and password settings are applied to all devices accessing the AcmeGizmo network, so no additional work is required for Ivan to accomplish this.
VPN and endpoint security compliance
A few additional tasks are required before the device is in compliance. Because Ivan has selected Junos Pulse as AcmeGizmo’s device management and security solution, Fred downloads the Junos Pulse application from the Android Market. This solution protects the device through antivirus and other device security features while simultaneously providing the VPN component and configuration, which allows Fred’s smartphone to securely access the AcmeGizmo network.
This client also leverages the multifactor authentication solution that AcmeGizmo has put into place, ensuring that Fred authenticates to the network properly, using a one-time password solution rather than a simple username and password. This increases security by ensuring that a stolen password and device don’t allow a malicious entity to gain access to sensitive corporate data.
Loss and theft protection
Ivan’s last step is to ensure that Fred’s device is appropriately protected from loss and theft. Because Ivan has already deployed the Junos Pulse device security solution onto Fred’s device, this protection exists. If Fred loses his new smartphone or if it is stolen at any time, he simply reports the loss to AcmeGizmo IT, and all sensitive data can quickly and easily be removed from the device.
Part III
Securing Smart Device Access
In this part . . .
Other parts of the book help you develop and implement policy, but this part moves on to the real world — which eventually means your network. How do you build the system of seeing, accepting or rejecting, or limiting access to the hordes of devices entering your main branch and remote offices each and every hour?
Chapters 7 and 8 contain all sorts of old friends to help you in your tasks: friends like IPSec and SSL VPNs, Wi-Fi, user authentication, and application access control.
And just to make sure you and your old friends are ready to party, our book’s model company, AcmeGizmo, has a case study to put you in the mood.
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 d
oesn’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.
Mobile Device Security For Dummies Page 17