An effective device deployment strategy involves providing a limited selection of devices from which your users can choose from (providing a large selection would entail a broader support burden that in most cases is unnecessary). Additionally, the strategy entails negotiating with carriers about bulk pricing (including pooling data, text, and voice across your user base) and shorter contract length to allow you sufficient flexibility to evaluate effectiveness and pricing periodically.
If, however, you’re tasked with deploying devices in the enterprise, you need to take the following factors into consideration:
Device selection(s): Opt for a limited set of devices to cater to a basic voice user as well as to the more advanced mobile device user. Device characteristics should reflect the enterprise policies we discuss earlier (device encryption, remote wipe capabilities, and so on).
Carrier selection(s): Depending on the size of your enterprise and whether or not roaming is needed, your carrier selection may vary. Typically going with a larger carrier provides better worldwide coverage, but if you require local roaming only, some of the tier 2 and tier 3 carriers have very good promotions and service.
Pricing terms: You need to negotiate bulk pricing that allows you to aggregate data, text, and voice across your users to give you better pricing based on consolidated usage and your users better flexibility by not having to carefully monitor their individual usage.
Contract lengths: You should negotiate contract lengths down to the smallest possible terms to allow you periodic evaluation of effectiveness and pricing from the carrier.
Warranty terms: Negotiate extended warranty terms for mobile device replacement as well as periodic upgrade terms because your users will expect reasonable upgrade cycles as technology and offerings advance.
Because the criteria used by similar-sized enterprises is about the same, you would be well on your way with device deployment by going ahead and copying, so to speak, from others. Look at competitors from your industry, and others as well with similar company sizes, to draw upon their device deployment choices.
Device discovery
Discovering mobile devices as they come into your network isn’t a difficult activity to perform. Depending on how the device connects to the enterprise, there are various techniques to authenticate the user and the device. For instance, if a smartphone is using Wi-Fi to connect to the enterprise network, user authentication is a good first step to identify the employee. To further qualify the device, the ISAPI filters or Network Access Control (NAC) techniques can be used to zero in on the device type itself.
If the user is using the carrier’s wireless network to connect to the enterprise, typically this is over a VPN connection like SSL, and the SSL appliance can be used to elicit the user and device information.
If the device isn’t recognized, you can choose whether to block all access to the enterprise or limit the user access to noncritical systems. This is dependent on the strictness of your enterprise policy that you choose to enforce.
Device provisioning
Provisioning devices involves delivering configuration data and policy settings to the mobile devices. (Chapter 4 covers these policies in detail.) The leader in this space is clearly Research In Motion, with its BlackBerry Enterprise Server that, with a few mouse movements, can remotely configure these devices. Other device and OS vendors are catching up to this crucial enterprise requirement. For instance, Apple’s configuration and security settings can be deployed wirelessly through a user self-enrollment portal. While not as transparent to your user community as the BlackBerry solution, it does provide similar levels of granular configuration and policy deployment to iPhones and iPads.
Note that provisioning may be a one-time activity, but keeping up with OS upgrades, security patches, and so on is always going to be needed on an ongoing basis. The good news is that with employee-owned devices, the upgrade itself is the onus of the employees, and the device and OS manufacturers have done a pretty good job at making this as painless as possible. But you need to be prepared for users still fighting these upgrades. You must be able to modify your policies to allow or disallow access to the enterprise, taking into consideration the revision level of the operating system and applications so that your risk level isn’t increased due to nonconforming devices coming into the network.
Device monitoring
Device monitoring is a constant activity that’s needed to ensure that the mobile device is in compliance with your enterprise policies at all times. Note that this is different from application control and monitoring, which have more to do with user behavior and being able to control what the end user is trying to accomplish. For more information on application control and monitoring, see the section “Controlling and Monitoring Applications,” earlier in this chapter.
The primary objective of device monitoring is to validate device compliance to enterprise policies at all times.
Typically, an enterprise agent is installed in the provisioning process (described in the preceding section), and it’s your eyes and ears for every enterprise mobile device. This agent has some unique characteristics — it needs to consume very little CPU and battery power, and it needs to be as unobtrusive as possible until a violation is detected.
The CPU and power budget consumed by this agent is critical because your users are going to revolt if this agent causes their smartphones to become unresponsive or drain significantly. Therefore, any vendor that you choose needs to demonstrate a lean and mean profile that can perform the tasks unobtrusively.
And unobtrusively means that when the device discovers a known enterprise wireless access point and connects to it, the device monitoring agent monitors this connection to ensure that all communication thereafter stays encrypted.
Compliance enforcement
The next step in the flow, once your device-monitoring agent detects a violation of your enterprise policy, is enforcement, which comes in these three flavors:
Your primary goal is protecting the enterprise from any security breach caused by the errant application. However, it is also important to ensure that your users have the most painless experience possible as you try to remediate the situation. To this end, the more transparent this reparation is to the end users, the more satisfied your users will be, and ultimately, you will breathe a whole lot easier as well.
Automated correction that’s transparent to the user
Automated correction (through redirection to a self-service portal) that requires user interaction
Manual remediation that requires your intervention (highly undesirable — see the following warning)
The last option of manual remediation should be your “have no other recourse, therefore I am going to resort to this” option. This is a highly intrusive, labor-intensive, and user-unfriendly option. But in certain situations, this may be the only option available to you, so we cover this as well in the subsequent sections.
Automated correction
As the name suggests, automated correction is the most painless of approaches, as it doesn’t require any intervention by you or the user, and the device automatically self-corrects. This intelligence is embedded in the monitoring application itself.
For instance, consider the previous example for device monitoring where the smartphone connects to an enterprise wireless access point and the monitoring agent’s job is to verify that all traffic is encrypted. When a device is found to be in violation, it could be easily self-corrected to enable encryption on the smartphone (IPSec or equivalent) without affecting the end user and still ensure that your enterprise policies are met at the same time!
Semi-automated correction
The semi-automated remediation capability requires the user to be involved. Typical violations are applications that are downloaded that violate enterprise policies. An example of this could be an application that provides cloud storage as an extension to local device storage. Clearly, for data that is stored locally, you would have policies s
uch as local encryption, but once this data extends to the cloud, there’s no way you can enforce such policies.
Your only resort at that point is to disable these classes of applications. However, since you can’t willy-nilly delete applications on your employees’ devices, your only resort is to redirect them to a remediation portal where they’re presented with the facts. Perhaps, a notice such as this would work:
“Your Foo app is in violation of enterprise storage policies. You will not be allowed access to the enterprise network until you disable or delete the Foo app from your device. Have a nice day.”
Be succinct yet comprehensive so the user is faced with the choice of either deleting the app or choosing to retain the application but not connecting to the enterprise any more.
In either case, there is active user involvement, and giving users a choice offloads the burden from you and your staff having to deal with these errant users!
Manual remediation
Manual remediation is the most intrusive as it involves you — the IT department — having to play a part in enforcing the enterprise policy. Typically, this happens if automated correction isn’t possible or there have been recurring violations that need active intervention on your part.
An example where automated or semi-automated correction isn’t possible is when a new vendor’s device is introduced to the network. As discussed earlier, you have a choice of blocking all access or limiting it to noncritical systems. But a third choice is to meet with the user to learn about the device and its capabilities — and maybe even add that to your catalog of supported devices and adapt your policies based on this device’s unique capabilities. This keeps you ahead of the game, and more importantly, you are viewed as a trusted and flexible partner who is constantly working with your user community to make them more productive!
There may be employees who are constantly looking for loopholes to violate enterprise policies. They experiment with jailbreaking, downloading rogue applications, compromising security on the network — the list goes on. Your options with these repeat offenders include temporarily suspending access to the enterprise network and, if that doesn’t get them to wake up and smell the coffee, escalating to your management and their management, when that’s the only recourse. It happens; so be prepared for it.
Chapter 10
Hacker Protection and Enforceable Encryption
In This Chapter
Knowing the components of on-device security components
Protecting devices with device-based firewall software
Fighting viruses with device-based antivirus applications
Warding off spam with device-based antispam
Guarding against device intrusion
Defending your communications with device-based encryption
This chapter covers each of the on-device Anti-X protection components, first covered in Chapter 9, in detail. The two important concepts that are the focus of this chapter are hacker protection and enforceable encryption. We discuss various on-device protection capabilities that can be effectively used to defend against hackers. Additionally, you find out the importance of enforceable encryption and discover the tools and techniques available to enable this critical piece of your mobile security arsenal.
Getting to Know the On-Device Security Components
On-device security components are firewall, antivirus, antispam, intrusion prevention, and enforceable encryption. We discuss the benefits of using each of these on-device security components in detail throughout this chapter. When you roll out on-device security components, you must prioritize: Which components do you implement first? (In this book, we call those the “do-these-first” components so they’re easy to spot.) Eventually you want to arrive at a complete security strategy that includes all the components in your security arsenal, but let’s get real: First things first. You need a horse in front of the cart to get things rolling.
In this chapter, we explore the following on-device security components at length (see Figure 10-1):
Device-based firewall: A native firewall running on the smartphone as a barrier against uninvited intruders.
Device-based antivirus: Antivirus technology installed on the smartphone.
Device-based antispam: Built-in filtering capability that protects your users from the unwanted barrage of incoming bulk e-mails.
Device-based intrusion prevention (including SMS): A sophisticated and application-aware firewall designed specifically to detect attempted hacks and protect the smartphone against intruders.
Device-based enforceable encryption: A feature that protects data communication on the smartphone by obfuscating the data resident on the device and encrypting data in transit as it originates from the device.
The threat vectors are many, and the forms of attack are varied. Any solution you adopt must be versatile enough to counter this multi-pronged frontal assault that users and their devices face day and night.
Your users’ biggest nightmare (at least the one that haunts their smartphones) is battery life — or lack of it. Turning on all the on-device security solutions at once may be tempting, but it hits battery life big-time. Therefore, you have to pick and choose a combination of on-device and provider-based models for a more practical deployment solution.
Figure 10-1: Device-based security components.
Keeping Devices Safe with On-device Firewalls
A device-based firewall is a form of protection that is physically resident on the device, as opposed to protection based in the cloud or hosted protection. A device-based firewall’s express purpose is to detect and thwart relatively straightforward brute-force attacks.
A firewall will typically thwart unauthorized external connections that attempt to communicate with the device. The firewall can even be configured to monitor (and block as necessary) internal applications on the device that attempt to communicate with the outside world.
The adoption of firewalls for smartphones is becoming more mainstream mainly because these phones look and feel increasingly like laptops and desktops, and everybody’s familiar with client-based protection that includes a firewall for laptop and desktop computers. So the argument in favor of extending similar types of protection to cover smartphones does pass the smell test — yes, it’s necessary — but it’s not sufficient. That’s partly because (also increasingly) these smartphones are becoming users’ primary means of connecting to the Internet. No wonder the exposure level continues to skyrocket for smartphone users as they spend ever-increasing amounts of time online, as shown in Figure 10-2.
Figure 10-2: Use of Mobile Internet across various types of handset users.
Later in this chapter, we cover device-based intrusion prevention (protection that watches out for more advanced and sophisticated threats). You can use the firewall and intrusion prevention in tandem to get the most comprehensive protection for your users. Be warned, however, that this approach increases battery drain: The more intensive the protection that intrusion prevention provides, the more processing power it requires. The recommendation here is to use on-device intrusion prevention solely as a backup option if you see that your users are getting attacked mercilessly and you need the heavy hammer to protect them.
The device-based firewall, on the other hand, provides basic protection against common attacks and therefore demands less power. So the question is: How much protection do your users need, and how much battery drain will they tolerate?
Although smartphones are similar to laptops and desktops in many ways, the differences are striking, and the security posture you adopt must take those differences into account. The following sections look at some of those crucial differences: the footprint of the device, battery usage, and adapting to changing usage patterns. Keep them in mind when you adopt a device-based firewall for your smartphone users.
Small footprint
It’s critical to choose a firewall with a small footprint — that is, a modest use of power, storage and memory — on t
he smartphone. Even as storage gets cheaper, your users’ smartphones become voracious animals gobbling mega- and gigabytes by the minute, and much of the available space is already taken. Therefore any business-critical application that you want to run — the firewall clearly fits that bill — must be small enough not to interfere with your users’ lives. It should go about its tasks as unobtrusively as possible.
The striking similarities between the smartphone and its laptop/desktop predecessors have not gone unnoticed by the traditional firewall vendors — TrendMicro, Symantec, and the like — so all of them offer versions of their products for the smartphone. When you choose a firewall, scrutinize each product to see where the vendor has drawn upon heritage solutions — where size was not the biggest concern — to deliver a smartphone version of the same product. The challenge was to get the footprint down; how well does each product succeed?
Determining the memory footprint of your firewall application for your mobile device is not a straightforward process. If you use a system monitoring application like the System Activity Monitor for the iPhone or System Monitor for the Android, you can see the current memory usage. Subsequently install the firewall application and run the same system monitoring application again and note the new memory usage. The difference between the two is the memory footprint of your firewall application.
Contrast this with some of the “mobile only” firewall vendors, such as Lookout and SMobile (now part of Juniper), who have had the luxury of designing their smartphone solutions from the ground up. Their products are optimized for Internet-connected use but may lack some advanced firewall features that the traditional players have had for years.
All in all, it’s a potpourri of vendors and solutions out there, and you have to balance the “small footprint” requirement against the “best features” and “most bang for the buck” criteria when you evaluate their offerings.
Mobile Device Security For Dummies Page 23