If you need to enforce certificate authentication on mobile devices, you need to look for management solutions that can deploy certificates to devices at scale. Look for such capabilities in the management systems you already have in place for deploying certificates to Windows PCs, for example. Several existing management solutions have recently added mobile features to manage certificate deployments on all types of devices.
Authorizing users to see only the data they are allowed to see
Once users authenticate successfully from mobile devices, allow them to access only the data or applications that you want them to. You may not want all users to be able to access any or all types of applications by default. Many mobile device users want access to only corporate e-mail, whereas others use these devices to check the intranet web pages. Yet another type of users, power users, want to log in to their remote desktops and remotely operate their desktop applications from their mobile devices.
Here is a broad categorization of application types that you may want to restrict access from or allow access to, depending on the group that a user belongs to:
Web-based applications: Users can access intranet pages from mobile device browsers.
E-mail: Users can send and receive e-mail and schedule meetings on the calendar.
Full network access: Users can access not only web-based apps and e-mail but also any other corporate client apps on the mobile device downloaded from an app store.
You can allow mobile users to access web-based applications and e-mail without letting those devices into the corporate network, such as by assigning them an IP address within the network. Web-based applications can be accessed by most sophisticated mobile browsers supporting SSL encryption. E-mail access can be enabled via Microsoft Exchange or ActiveSync, which also does not need the mobile device to have an IP address within the network. Full network access, on the other hand, needs the device to be within the corporate network. This type of access allows the user to access pretty much any application within the network, just as if they were in the office. Accordingly, your security policies need to be at their strictest for granting full network access.
Integrating with existing VPN policy infrastructure
If you allow your users VPN access to the corporate network, you likely already have a policy in place that describes what types of users are allowed access, including the applications that are allowed to be accessed remotely. VPN policies are typically enforced on a VPN gateway device at the perimeter of the network, with access for external users.
While shopping for VPN solutions for mobile devices, look for the following:
Wide range of supported mobile platforms for corporate access, such as these:
• Apple iOS
• Google Android
• Windows Mobile and Windows Phone 7
• Nokia Symbian
• BlackBerry OS
• Others such as HP Web OS
Wide range of supported authentication methods:
• Username and password–based
• Certificate-based
• Multifactor authentication (for example, cascading username and password-based authentication followed by certificate-based authentication, or vice versa)
• VPN on demand (setting up a VPN tunnel automatically when the user attempts to access a corporate resource)
Ability to assign role-based access to users, depending on their role within the enterprise
Ability to assign granular access to any or all of the following types of applications:
• Web-based intranet content
• E-mail
Full network access
VPN gateways are typically either dedicated VPN appliances that enable IPsec or SSL VPN access, or firewall devices that include VPN functionality in addition to a host of other security features. In either case, most VPN solutions should have a well-defined policy infrastructure to define role-based access to corporate data and applications.
Depending upon your corporate policy and need for application control, you should choose between an IPsec VPN solution or an SSL VPN solution. Here is some information that can help you choose between the two:
IPsec VPN solutions: Enable full network access to remote users. That means users who connect over traditional IPsec VPN tunnels are granted full network access to the corporate network, including getting an IP address within the network.
SSL VPN solutions: Usually allow more granular access control, enabling you to control application access to any of all of the various application types: web-based, e-mail, or full network access.
Choose a solution that allows you to manage mobile access control policies on this kind of a centralized VPN system that already manages remote access policies. It would be counterproductive (and very costly!) to manage duplicate or redundant policy systems, one for traditional remote access from home PCs and another for mobile devices.
To integrate your existing VPN policies with mobile access control, here are the key decision areas you need to consider:
Your mobile security solution: Depending upon what security features you need on your users’ mobile devices, choose a solution that spans a broad range of mobile platforms. As discussed earlier, you may choose any or all of the security features to enforce on mobile devices, including protection against viruses, malware, Trojans, and spam.
Your endpoint security posture (level of risk): You may already have an endpoint security solution on your VPN gateway allowing network access only to devices that have a sufficient security posture. This policy may include checking for installed antivirus or antimalware software, or verifying that the device is a corporate-assigned computer before granting VPN access. You may want to extend this policy to mobile devices, allowing VPN access only to those mobile devices that are secured by the security software of your choice.
Your access control policies: The access control policies enforced on the VPN appliance should follow the user, meaning that no matter where the user logs in, the policies applicable to that user must be enforced. Choose a VPN solution that can enforce a single set of access control policies, irrespective of where users connect from, or what devices they use to connect. Having a single set of policies that span across device and application types will make your life simpler.
Integration of mobile security functionality with your existing VPN solution has several advantages, such as the following:
Easy enforcement of mobile device security as an endpoint posture assessment check, prior to granting VPN access to users
Easy enforcement of access control policies that are already defined on the VPN gateway
Easy integration into the management capabilities of the VPN solution, thereby offering insights into the mobile device inventory and assets within the enterprise
Part II
Implementing Enterprise Mobile Security
In this part . . .
You’ve just finished taking down all those No Mobiles Permitted on Site signs, not because you secretly don’t agree but because no one was paying attention to them.
But luckily, Part II helps you put together a plan for mobile device security. Chapter 4 gets you on the road to recovery by helping you create policies, those glowing rock star plans that architect your security structure. Chapter 5 continues the euphoria by outlining how to manage and monitor the policies you implement. It’s not rocket science, and chances are you’ve already implemented many of them — but who knows. Maybe we are actually rocket scientists, minus the rocket scientist paycheck.
Chapter 6 is the real trick: making sure your plans conform to existing corporate compliance policies so there’s a united voice to the user about future compliance.
And as a mobile security bonus, each chapter in this part has a case study at the end, explaining how our book’s model company, AcmeGizmo, implements the concepts discussed in that chapter.
Chapter 4
Creating Mobile Device Security Policies
; In This Chapter
Understanding the importance of mobile device security policies
Creating effective device policies
Managing devices through provisioning policies
Implementing monitoring policies
Using application policies to protect against malware
This chapter delves into the universe of security policies for mobile devices — the why, how, what, and where. Clearly the danger wrought by these new age devices should be apparent by now. In this chapter, we shift the focus to how you can combat this danger with consistent, transparent, and comprehensive policies that both protect the enterprise and educate your users.
Recognizing the Importance of Enforceable Security Policies
Before we get into the nitty-gritty of the various components of security policies, it is important to understand the need for them. If every one of your users were an intelligent, security-savvy, self-regulated, and enterprise law-abiding citizen, you could do away with enforcing the policies altogether. The only aspect of the policies that you would need to worry about would be the creation and education pieces. However as you know, life is not cut-and-dry, and your users are typically very innovative when it comes to skirting the rules, not prone to reading policy documents or understanding the impact of noncompliance, frequently try to circumvent the policies that exist, and constantly excel in their ability to figure out loopholes.
Therefore, your security policies need to include the following:
Unambiguous terms and definitions that are universally understood
Language that enables enterprise IT — you — to codify the rules of engagement so that both you and your users can adhere to an unambiguous set of documents
In the event of a breach of policy, the ability to take remedial action with the primary aim of protecting the enterprise and, in the event of violation due to nefarious intent, to follow prescribed guidelines against the errant individual
The ability to adjust the policies based on user feedback and deployment-related learning
Figure 4-1 depicts the five stages that an IT policy lifecycle passes through, and this is applicable to a mobile device security policy as well. Here is a brief description of the five phases shown in the figure:
Define the policy. This stage stipulates the policy in clear and concise terms.
Educate the users. In this stage, it’s critical that you clearly communicate the policy to the users. Make sure you get your message across.
Implement the policy. This stage sets into motion the actual policy itself.
Audit the policy. This is the data collection and feedback stage to assess how the policy is performing versus its stated objectives.
Modify the policy. This is a crucial but often overlooked step: to be able to adjust the policy based on the results of the audit and the feedback gathered.
Figure 4-1: The IT policy lifecycle.
Understanding Device Policies
Device policies can be split into two categories: policies for approved devices and policies for other devices, as shown in Figure 4-2.
Figure 4-2: Device policies.
Here is a rundown of the two categories of device policies that you need to communicate to users:
Policy for approved devices: This policy applies to all enterprise-issued mobile devices. Because these are enterprise assets, you are at liberty to set a strict usage policy as well as establish stringent penalties for misuse.
Policy for unapproved devices: An unapproved device in this case is a device that the enterprise neither endorses nor supports. This does not mean that you can summarily deny all connectivity to enterprise assets, but you can impose restrictions on what, how, and when these devices connect to enterprise resources.
Obviously, your policies will be largely applicable to the approved-devices list, because this is what will typically be the exposure that your employees are subject to.
There is going to be a rapid transition of devices from the unapproved list to the approved list based on user adoption of evolving mobile devices, so expect the list of approved devices to continue to grow. For instance, when the first iPhone was introduced in 2008, there was very little enterprise IT support for it. Fast-forward to today, and a large number of enterprises (a number that is ever increasing) support this device.
The unapproved devices policy will simply be one of two options, as shown in Figure 4-3:
Access denied: No access to the enterprise network altogether
Access restricted: A highly constrained set of privileges available to the user
The following are the key elements to consider when creating policies for approved devices. Note that there is further categorization in the approved device category: employee owned and corporate issued, as shown in Figure 4-4. For each of the policies that follow, these will be called where appropriate:
Policies for physical device protection
Policies for device backup and restore
Policies for device provisioning
We examine each of these policies in turn in the sections that follow.
Figure 4-3: Unapproved device policy screens.
Figure 4-4: Sub-classification of approved mobile devices.
Policies for physical device protection
The policies for physical device protection are mostly common sense — and yes, how uncommon is that? Yet these concepts bear repeating because your users take a lot of this for granted, and laying out the do’s and don’ts drives home the point.
Here the key tenets of physical device security (outlined in Figure 4-5) that you would convey to mobile device users at your company:
Figure 4-5: Physical security policies.
Ensure that your device is within your control at all times.
Ensure that removable media usage is avoided altogether and, if that isn’t possible, ensure that the data on the media is encrypted.
Refrain from lending your device to third parties.
Use a sticker (it’s low tech, but it works) that contains your name and contact information and stick it on your device so that in the event the device is lost, there is an opportunity for a Good Samaritan to contact you.
[Create these stickers beforehand and hand them out to your users during the training process.]
In the event of theft of your device, immediately contact the appropriate party. If it is a corporate-issued device, IT can initiate remote recovery and remedial operations.
If it is your personal device and you have remote recovery services from your provider or device manufacturer, follow that procedure right away. In the event that you don’t have any such recovery mechanisms, contact your service provider so that at the very least they can immobilize use of the device itself.
Remote recover and remedial operations
Remote recovery and remedial operations are essential functions provided by most device manufacturers and mobile operating systems vendors as well as third parties. Under the cate-gory of mobile device management, remote recovery entails locating the device, initiating remote wipe operations, and locking down the device to immobilize it to prevent unauthorized usage. Remedial operations entail locating a substitute device, restoring the state of the original device onto the replacement, and issuing the replacement to the user.
Policies for device backup and restore
As mobile devices become an integral part of the digital communication toolbox for accessing enterprise assets, and with the growing storage capacities on these devices, there is going to be an ever-increasing propensity for enterprise data or intellectual property to reside on these devices. Couple this trend with the storage of business contact information and images and videos that are captured by the mobile devices, and the need to be able to back up these devices becomes paramount. Needless to say (but we will, anyway), the other side of the equation is to be able to quickly restore these devices to an operational state using previous backups. Both these critical tasks of backup and restor
e are your responsibility. To make this process as painless and automatic as possible for both you and your users, you need to establish a set of policies that should be adhered to religiously.
You should look at backup and restore policies from these two viewpoints, as shown in Figure 4-6:
Recommended policies for user-owned devices for backup and restore
Mandated policies for enterprise-issued devices for backup and restore
Figure 4-6: Categorizing backup and restore policies.
This distinction is critical to the success and scalability of the backup and restore plan you put in place. You are obviously keenly aware of the proliferation of the variety of mobile devices in the enterprise and the need for you to support all of them, and therefore, the need for recommended backup and restore policies for your employees when they bring their own devices into the enterprise.
Here are the key tenets to pass on to mobile device users in your enterprise for employee-owned device backup and restore:
Mobile Device Security For Dummies Page 10