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.

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.

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 the 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.

You first want to ensure that your enterprise policy is being adequately met in terms of the features that the firewall vendor provides. The footprint should be your next immediate consideration and not the other way around.

Some vendors may have optimized their solutions for particular operating systems or specific devices. Make sure the solution you choose fits what your people are using. Identify the top two to three smartphones in your enterprise and run the “footprint” test against all of them. You don’t want to be lulled into a false sense of security by a device-specific solution, only to be rudely surprised later. Be sure to do your homework thoroughly.

Efficient battery usage

Battery usage applies to every single application that runs on the smartphone, but it has a special significance to the on-device firewall: It must run as efficiently as possible and consume the least possible battery power.

For users, convenience is a priority; they’ll turn off applications that they think are draining the battery too much. You don’t want the firewall to be one of the offending programs that gets identified as a power-hog. You can run a device-based monitoring agent to alert you if the firewall is deactivated, but frankly, that should not be a frequent occurrence. Your firewall should be efficient enough to keep it off the list of things-to-turn-off; otherwise you’ll age rapidly in your day job.

Battery life — or the lack of it — is a constant nightmare for your user community. Therefore, it’s in everybody’s best interests that you choose an efficient firewall to put on your smartphone. It’s akin to checking the footprint when you’re evaluating operating systems and devices: Does the product use only the storage and memory that it needs — and no more? The same holds true for battery life: the firewall should do its job with minimal power drain.

You need to learn from the experience of others when it comes to battery usage of firewall vendors because there is no easy way to glean this beforehand by yourself. Actively scour the Internet and trade magazines to look for actual user experiences and reviews before making a decision.

Dynamic adaptation to changing usage

Keeping your security response flexible is uniquely important to the mobile environment. That’s partly because most current smartphones make multitasking available. Your users could be videochatting with one application while simultaneously texting, make a voice call, turn on location-based services to find the nearest gas station, and download corporate e-mail — all at the same time. Any firewall that claims to protect the device has be able to watch constantly for the specific applications, interfaces, and protocols the user is using at any given moment and provide complete protection against attack for all of these.

The heavy-hammer approach is tempting: You could turn on protection for all interfaces, applications, and protocols at all times but then the firewall falls afoul of the “efficient battery usage” tenet. You don’t want the firewall to suck the life out of the battery while trying to protect everything constantly, regardless of what’s actually in use. Clearly, an effective firewall has to be more intelligent, adapting constantly to the usage pattern and turning protection on and off as necessary.

In terms of the types of interfaces a firewall needs to protect, it comes down to what types of wireless connectivity your mobile devices provide. Typically, a mobile device has at least a wireless LAN or Wi-Fi interface that allows the user to connect to the wireless network. In addition, for smartphones, the device has an interface (like a 3G or 4G interface) to connect to the service provider’s network. Most firewalls provide protection against these two primary interfaces, and you should make sure beforehand that they do. In addition, you need to consider other interfaces your mobile device may have, including a Bluetooth interface. A Bluetooth interface is particularly vulnerable because not many firewall vendors protect this interface, and as you are well aware, it is one of the most widely used interfaces for accessories like a headset, Bluetooth stereo devices, and so on. See the nearby sidebar for an in-depth look at the Bluetooth security issues.

Protecting Against Viruses

With the widespread use of applications that download attachments to the mobile device — including the most widely used app of them all, e-mail — the need for virus-based protection is becoming critical. Keep in mind, however, that other mobile-specific attack surfaces (exposed areas that are vulnerable to attack by hackers) allow for other ways to infect the mobile. For instance one of the earliest mobile viruses was the Commwarrior that would propagate itself by using MMS message attachments and Bluetooth. Once the virus infected the device, it would start searching for nearby Bluetooth phones to infect.

These attacks use features found specifically on mobile phones — MMS, Bluetooth, and the contacts database — to compromise the device and propagate the attack. Figure 10-3 shows three fundamental ways such an attack can be launched to propagate a virus to a smartphone.

Here’s how each mobile virus propagation technique works:

Bluetooth: This technology has come of age with the widespread use of hands-free devices as well as close-range device-to-device communication. The standard operating configuration for most users is to place the device in discoverable mode (so it can be seen by other Bluetooth-enabled devices nearby) or connected mode (which allows the device to be discovered and connected to). Viruses can be delivered to the device in either of these modes.

Note that this potential risk can be overcome by completely turning Bluetooth off so you eliminate the Bluetooth attack surface. However your users are not likely to do so because it’s not user-friendly. They’re much likelier to keep their phones both “discoverable” and “connected,” which makes them sitting ducks for virus attacks.

Messaging: Malware attachments can be appended to messaging services such as e-mail, MMS, or Instant Messaging. Typically the default configuration does not allow these attachments to unpack and run automatically; the user has to accept the attachment and open it and become infected. But you probably know the dazed look in your users’ faces when they see those deadpan warnings; expect some of them to ignore the warning and fall victim.

Downloads: This is probably the most widely used way to disguise and deliver malware. All the device needs is an Internet connection; the incoming malware-infected file can show up disguised as (say) a game, security patch, software upgrade, utility, shareware program, video, picture, you name it. Even worse, an infected server from a reputable vendor can cause even the most cautious users to become unsuspecting victims to file-based viruses.

Antivirus technology has been available for decades, and many of your users would never consider operating a computer without some antivirus solution running on it. Antivirus protection is necessary — okay, they get it. But they only think of it as needed for their desktop computers.

A lot of us don’t seem to notice that most of our mobile devices, which are all derivatives of computers in one way or another, have no antivirus protection whatsoever. What’s even more surprising is that your users attribute more importance and personal attachment to the smartphone than to the computer while still failing to protect that phone.

You have to take a stand on this issue and ensure that you’re providing adequate mobile antivirus coverage to your users on their both their desktop and mobile devices. Fortunately, the range of mobile antivirus solutions is ever-increasing. As with traditional antivirus solutions, you should be looking not only at the upfront costs, per-seat license renewals, and automatic signature updates, but also at mobile-specific features such as battery-life recognition, memory requirements, and the broadest possible coverage of mobile operating systems.

The following sections cover the types of antivirus solutions that are at your disposal. We also clarify the difference between the firewall (discussed earlier) and the antivirus solution and why you need both in your toolbox. As noted in Chapter 9, one common on-device antivirus solution uses the client-server model: An on-device agent program leaves the heavier processing to the server in the cloud. In the following sections, we revert to a more traditional on-device antivirus solution where all the processing happens on the device itself.

Firewalls and virus-based attacks

The previous section, “Keeping Devices Safe with On-device Firewalls,” considers the device-based firewall as protection against attacks directed at the device itself. These attacks take various forms; two typical ones are

Port scanning: The attacker looks for exposed ports that could be used to connect and compromise the device.

Brute-force ping floods: The attacker barrages the device with pings to overwhelm its capabilities.

Most of these attacks try to exploit poor security postures of particular devices and applications. The perpetrator usually doesn’t pay much attention to the smartphone’s operating system.

Virus-based attacks, on the other hand, are more general. They’re essentially file-based; they ride in on a file that must be downloaded (either overtly or covertly) before the attack can be launched. That’s where an obvious operating-system concern enters the equation and becomes extremely relevant: Any device with the targeted operating system, mobile or not, can be vulnerable. Some of these viruses also target browsers, taking into account the browser and operating-system vulnerabilities.

A bevy of device-based antivirus solutions has popped up, and more come to market by the hour. The traditional desktop and notebook vendors (Symantec, Trend-Micro, Kaspersky, and the like) have morphed their offerings to support the newer smartphones. On the other side are the new kids on the block — vendors of smartphone security such as Lookout, F-Secure, and such — who provide highly customized smartphone antivirus products.

Which vendor(s) you choose depends on what’s most important for you to protect as you explore this new dimension of your network — the smartphone. For example . . .

If your predominant disposition is toward a common look and feel and consistency across all endpoints (desktops, laptops and smartphones), then you should look to one of the traditional vendors. As mentioned earlier (see the “Small footprint” section), familiar antivirus products that have a large footprint in the desktop environment have extended themselves by getting small enough to fit into a smartphone.

If your primary goal is to provide a customized and tailored smartphone-centric antivirus solution, then you would do your due diligence (and do yourself a favor) by checking out the new-age smartphone antivirus vendors and choosing a mobile-centric product to fit your environment.

Virtual device antivirus solutions

For the sake of completeness, here’s a look at virtual devices as antivirus solutions (as mentioned in Chapter 9). A “virtual” antivirus solution doesn’t run on the smartphone itself; instead, the main program runs elsewhere on the Internet, making its features available through a small software agent running on the smartphone.

Here’s how it works: The user downloads an antivirus agent to the device, and the bulk of the intensive antivirus processing takes place on a remote server (either locally hosted by you or by a hosted cloud service). The client collects information about the mobile device it resides on, and delivers a certificate of authority. In this model (shown in Figure 10-4), you maintain a clone of the actual phone in the enterprise as a virtual machine; the agent informs you of any changes to the end device — such as new applications installed, SMSs received, and so on — and then syncs with the virtual phone in the enterprise.

Any virus-based attack that is launched is actually targeted at the virtual smartphone, and the heavy burden of detection and cleansing is all performed in the virtual server. The smartphone itself, for all intents and purposes, is oblivious to the attack.

Note that you do need significant restrictions on the smartphone itself, such as not opening up any other interfaces (like the Bluetooth interface discussed earlier) because the only conduit from the smartphone needs to lead to the virtual smartphone and nowhere else. Opening up other interfaces on the smartphone could lead to directed attacks on the device, which renders such a “virtual” solution useless.

This is not real-time protection of the actual device, true, but it’s reasonably close. And it has the advantage of not dragging down the smartphone’s performance or draining battery at one gulp. In addition, because the capability is hosted on a server, you have a lot more processing power available for antivirus checking, as shown in Figure 10-4.

Reducing Spam

The threat of spam is as prevalent for mobile devices as it is for fixed devices such as laptops and desktops. This age-old form of malware continues to plague consumers and enterprises (you and me) alike. There are three primary places spam can come from when its target is a smartphone.

Here is a description of each of the vectors of mobile spam:

E-mail: The most common way to launch spam is via e-mail. Although this kind of attack is not limited to smartphones by any stretch, the increased adoption of smartphones — and the gradual shift toward using mobile devices for primary e-mail connectivity — makes spam-clogged Inboxes a real (and likelier) concern.

Instant Messaging: Attacks that use Instant Messaging — already a threat to traditional computer networks — are now more common on smartphones. Large communication providers and OS vendors offer not only the familiar form of Instant Messaging but also access to Twitter, Facebook, and other social media, which are also instant communication channels. As discussed in Chapter 9, social media spamming is one of the most dangerous threats to your users because social media resonate with them more closely than do other forms of communication, and their defenses against this type of spam are practically nonexistent.

The most important way to counter social media spam is the same way you counter other threats — with a three-pronged defense:

• Be vigilant

• Adopt a security-oriented posture

• Relentlessly educate your users

SMS and MMS: The mobile environment has its own unique form of spam based on mobile messaging, in particular SMS and MMS. As any employee who’s used a mobile phone abroad can attest, hordes of spam SMS messages can hound the user to a disturbing degree. What’s even more jarring is that in quite a few places, incoming SMSs are charged to the receiving party, so now the user not only gets an Inbox full of uninvited mobile spam but also has to pay for it.

While the threat vectors (ways to get spam to your device) can vary widely, the intent of the perpetrator(s) remains the same:

• Entice users to part with their money by making grandiose marketing claims.

• Phish for users’ data (or simply trash their devices) by getting them to open the message and click following links that load malware.

Service provider assistance

As mentioned in Chapter 9, the bulk of antispam solutions are provided by the hosting entity (e-mail, service provider, content provider, and so on), and the reason is simple: Identifying and stopping spam before it gets to the device is the most efficient way to counter this threat. In addition, you can identify spammers by utilizing a large aggregation of information — whether in the form of e-mail or messaging — at point-of-service provisioning. Then you can constantly update and hone this database to make the blacklist more effective. Real-time protection can only be achieved by service providers who have the data, computational resources, and means to adopt this approach.

Choosing an antispam solution

A plethora of device-based solutions abound that claim to stop spam in its tracks. While this claim may be more marketing-speak, it’s clear that to protect your users effectively against all the various spam threats, your solution needs a device-based component for spam protection. Although such a component should not be the only antispam solution used in your enterprise, it’s important to include in your tool chest.

As we’ve seen with on-device firewall and antivirus solutions, the choice of a particular antispam vendor is based on a number of factors, but be sure to keep these particular points in mind:

Which smartphones the product supports

Whether the product works with existing antispam solutions in your enterprise

Whether you can get enterprise-wide policy support for the solution

Whether a cloud-based antispam solution is available and works with the on-device component

Human nature being what it is, be prepared for a small portion of your users to fall prey constantly to spammers. If antispam protection is one of your responsibilities, have a well-thought-out remedial action ready to take and a well-articulated recovery procedure in place. It’s time well spent.

Global operator initiative to combat spam

With the widespread advent of mobile spam, the GSMA (GSM association) —the largest mobile consortium of its kind with nearly 800 members — has taken matters into its own hands. It has also kick-started an initiative called GSM spam reporting service whereby users who receive spam can forward those messages to a standardized number (it’s currently proposed as #7726, which spells SPAM on the handset). This is a great way to build a database of blacklists for the spam operators and eventually build an in-network spam-blocking solution. Information about spammers will also be shared among participating members, who will receive correlated reports with data on misuse and threat to their networks.

A successful trial of this service concluded in December 2010, and the service is now available to operators worldwide to join. Customers can report spam they encounter and help build a robust and growing database that can be used by all operators worldwide to stop the advent of this nuisance.

Preventing Intrusion

This section builds on the previous section, “Keeping Devices Safe with On-device Firewalls,” and delves into the dark and murky world of even more intrusive attacks and the armory you have to protect your unsuspecting users: on-device intrusion prevention. But before we delve in, keep in mind that intrusion prevention is computation-intensive. It takes processing power and (you guessed it) battery power.

The more intensive the protection that intrusion prevention software provides for your users, the greater the cost in processing power, which translates into the single biggest fear that mobile users have: battery drain.

In essence, you have to counter intrusive, high-tech attacks against smartphones with low-power-but-effective weapons.

There are three primary mechanisms that provide vehicles with which mobile devices get infected. These are

Installing malicious apps (or seemingly innocuous apps that are actually malware)

Connecting to “untrusted” networks, typically over wireless LAN

Getting infected with spyware using SMS

In the following sections, we examine each of these mechanisms in turn, explaining how an infection happens and how to prevent against it, or at the very least detect and remediate.

Installing malicious apps

From a hacker’s point of view, a smartphone presents a target far more fertile and wide-reaching than what a traditional desktop environment provides. Why? One primary reason — the app store. Thanks to Apple’s revolutionary, easy way to download free and cheap (and some not-so-cheap) apps to smartphones, apps proliferate for every type of smartphone out there. (See Figure 10-5.) With hundreds of thousands of applications available to your employees with a touch of a button (and sometimes a voice command, so not even touch is needed), it’s no wonder they constantly experiment with new applications.

“New” does not necessarily mean “good.” Some applications are written with the same rigor as traditional desktop applications, but most are written with the express intent of getting a quick return on investment. Bottom line: Their creators tend to circumvent good programming techniques, which makes them vulnerable to attack.

But wait, there’s more; these applications, vulnerabilities and all, could also have widespread access to your employees’ data stored on the smartphones, (contacts, messages, location, photos, and so on). An attacker could compromise those as well — and compound the trouble.

The familiar patterns of attack reassert themselves. One application that was sold as a simple wallpaper program also sent stored telephone numbers to a Chinese server; malicious Trojan Horses have turned up in gaming applications. One hack forced phones to make long-distance international calls, so the phone owner was then heavily charged for the “privilege” of being hacked.

When you’re responsible for a device in the enterprise, you have to include all the associated applications, data, and security posture that go along with the smartphone or device. The relevance of the application explosion to these concerns is that it’s also an explosion in potential smartphone vulnerability, and by extension, any associated data that a smartphone’s apps may have access to is also vulnerable.

So what can you do to prevent against this? The odds are stacked against you — users will experiment with new apps, and malware developers will flock to generate nefarious apps that threaten to expose data, become part of a botnet, or wreak havoc on other devices. Your best tools for prevention are education and communication. Constantly and consistently communicate about the need for users to employ good judgment when downloading apps. Users should follow these practices:

Avoid downloading apps created by unknown individuals.

Check the rating and feedback provided by other users on those apps before downloading any apps.

If the apparent value that an app touts sounds too good to be true, then it probably is. Avoid these apps at all costs.

After you pick your on-device firewall vendor, check with the vendor to see if it provides outbound monitoring solutions as well, which could point to anomalous behavior on the mobile device that could, in turn, provide insight into errant applications.

Connecting to unknown networks

As we have seen repeatedly, the mobile nature of the smartphone further exposes it to attacks that a fixed device may not be subject to. Here’s why:

A mobile device is always on the go.

Smartphones support a plethora of interfaces.

Bottom line: The likelihood is very high that any given smartphone is connected to one or more wireless networks almost all the time and could be anywhere.

This constantly nomadic existence and propensity for tethering means much greater exposure to unknown networks. Therefore, intrusions are far more likely on these devices than on a fixed desktop.

Typically, these intrusions are in the form of an infected machine in the network. Note that nomadic users connecting to ad hoc networks — sometimes with no encryption on the network — present a very tantalizing target for hackers. Hackers could be on that same network with an infected machine or could have infected a device that they’re controlling remotely from their console with the express purpose of attacking unsuspecting users as they attach to these networks.

So what can you do? Education, education, education. Your users need to follow these guidelines:

Check for the security posture of a wireless network you are connecting to. Is it encrypted (WEP, WPA, WPA2, and so on)? If not, understand that there are risks associated with connecting to this network.

Use the company-provided VPN client to ensure that all traffic is encrypted.

Run the antivirus/firewall client after you log off from the network to look for any potential breaches that may have occurred.

Your panacea is to periodically scan your enterprise-issued mobile devices using the antivirus, firewall, and newer forms of threat-detection solutions as they emerge, assuming your users will be constantly coming on and off public networks. For non-enterprise-issued devices, there is little you can do in terms of exercising control at the endpoint, so your posture should be more defensive, looking for threats emanating from the mobile that could attack the enterprise and using your network-based security solutions to prevent against this. Chapter 9 details enterprise security policies that you can adopt to mitigate this.

Getting infected with spyware via SMS

One of the most popular applications on the mobile device is SMS — and this popularity has not been lost on the hackers! As mentioned earlier — and it bears repeating — spyware is a real threat. One particular variety manipulates SMS messages and exposes them so they can be read by others in the near vicinity.

Given the ubiquity of SMS, it provides a compelling attack vector for hackers to exploit, and an innocuous-looking SMS can result in an inadvertent installation of spyware by the unsuspecting user. This spyware then scans through the contact database of the user and starts spamming the user’s contacts via any means possible, including SMS, e-mail, or even a call to the contact.

So what can you do? Again the same refrain — education, education, education. You users need to adopt these practices:

Be wary of any unsolicited SMS and don’t click any embedded links in the SMS.

A rapid drain in battery usage should serve as a warning that spurious applications may be at play. You need to get the device inspected by a technical expert. If it’s an enterprise-issued device, contact IT; if it’s a personal device, contact the service provider or other reputable third-party.

You need to be vigilant in keeping up with the variety of SMS-related threats prevalent in the mobile device ecosystem. At a minimum, work with the service provider for the enterprise-issued handsets to negotiate a service contract that includes a device replacement policy as well as a service for cleansing infected devices of spyware. The provider may also offer an SMS-related security service that you should consider seriously if there is an uptick in user complaints.

Using Enforceable Encryption

One way to counter spyware is with enforceable encryption — software that uses encryption to obfuscate critical data residing on the device. As noted in Chapter 9, extensible memory on the devices, including removable storage, makes the loss of the device quite dangerous if it contains any sensitive data. One way to mitigate this loss is to encrypt the data on those memory cards; then, if the device is lost or stolen, unauthorized users can’t use a card reader to access the memory card’s data. For the same reason, the use of strong authentication techniques should be mandatory for on-board memory as well. The following sections cover the various types of enforceable encryption you can use to secure your organization’s devices.

Encrypting all outbound and inbound communication

If your goal is to protect the whole data ecosystem, you need mandatory encryption of all outbound and inbound communication — that is, all messages to and from the device. On the face of it, this is no different from the policies that are imposed on the users of laptops and desktops that connect to your network via VPNs (virtual private networks).

There is, however, one important way that mobile device encryption must differ from typical laptop encryption: Your polices must address the ever-expanding set of customized applications that mobile device users constantly download and experiment with.

Although a majority of these applications have nothing to do with you — because they don’t access any enterprise content — they do pose a problem for a potential encrypt all policy. You’d have to transport all that non-enterprise application data, dragging it into the enterprise only to redirect it back to the Internet, as illustrated in Figure 10-6.

Encrypting only enterprise traffic

The obvious alternative to this approach is to discern enterprise applications from non-enterprise applications and intelligently encrypt only the traffic destined for the enterprise. That’s a win-win for everyone, right? Well, not exactly. The solution requires a smart agent to reside on the mobile device and make the decision of what traffic to encrypt and what to let fly, as shown in Figure 10-7.

You have to depend on the device manufacturer and the OS vendor to supply the supported encryption algorithms, but at least it’s a mature technology. Most of these new devices offer pretty comprehensive feature support, so it shouldn’t be a problem area.

Using carrier-provided voice encryption

Another type of encryption starting to become prevalent is carrier-provided voice encryption. Yes, I know what you are thinking: “Isn’t there some form of encryption already provided by the radio technologies in the network?” Good question — and the answer is yes. Although such embedded encryption has been robust for years, lately it’s starting to show signs of weakness. In fact, in 2009, Karsten Nohl cracked the famed A5/1 GSM encryption. But what took the cake was the modest level of technology it took to crack the encryption scheme — RF equipment, patience, and a $500 laptop!

To put this event in context, A5/1 is the most common encryption technology. It’s used by over 80 percent of subscribers worldwide.

This is the point at which the additional encryption provided by carriers starts to make sense, specifically for your most critical users (chief-level officers, sales heads, and so on). With sensitive data at stake, adopting voice encryption is not too outlandish.

The most common way to implement voice encryption is to use a carrier-provided two-factor encryption solution:

Each smartphone gets a hardened, self-contained crypto engine inserted into its microSD slot.

• The phone gets the strength of additional hardware authentication.

• Members of a defined group of trusted users can exchange encrypted calls.

• You can manage this capability over the air.

Users can easily place and receive encrypted calls by integrating with the mobile phone’s standard operation and address book.

• This security function is now on-demand.

• Mutual authentication and end-to-end encryption make a high-security call mode possible.

Case Study: AcmeGizmo Endpoint Security Deployment

Back at AcmeGizmo, Inc., Ivan the administrator has run into a serious issue. One of the executives downloaded some applications to his Android device, and as it turns out, one of those applications was a phishing application made to look like the Customer Relationship Management (CRM) application that AcmeGizmo uses. As a result, the bad guys who posted the app got their hands on the executive’s login credentials.

Luckily, Ivan and his team changed the password before anyone could log in with the stolen credentials and get access to the AcmeGizmo customer database, but this issue was a huge wake-up call that spotlighted the importance of endpoint security for mobile devices. The CEO of AcmeGizmo demanded that all mobile phones with access to corporate information be equipped with endpoint security software — immediately, and securely ever after.

Ivan started his search by re-evaluating the AcmeGizmo mobile device security policy. While developing this policy, Ivan had included a section on endpoint security. Sadly, he hadn’t yet gotten around to deploying a solution to actually secure those endpoint devices, which was a big mistake, given the amount of attention this recent incident got. After talking to IT admins at a few other enterprises and evaluating some vendor solutions, Ivan decided to equip AcmeGizmo mobile devices with these basic security features:

Antivirus

Personal Firewall

Antispam

Encryption

That finally got some good, solid, basic endpoint security to where it was needed. Ivan slept better afterward. But he still jumps a little when his smartphone rings.

Endpoint security

Several of these technologies are covered in the same solution that Ivan selected for AcmeGizmo’s VPN access: Junos Pulse. That solution provides the antivirus, personal firewall, and antispam capabilities that Ivan’s corporate security policy requires, making it easy for him to simply enable the functionality inside his network. And since the smartphones are already running Junos Pulse for VPN, there’s no need to distribute additional software or try to get the employees to download it. In addition, the tie-in to the SSL VPN allowed Ivan to implement policies that prohibit end users from connecting to the corporate network if endpoint security applications are not installed and running on their smartphones or tablet devices.

Had Ivan already installed and enabled this solution, the phishing application that found its way into the executive’s smartphone would have been neutralized and removed before the executive could even attempt to input the username and password that the hacker wanted to steal. This would have saved a lot of trouble.

Ivan decided to implement the antispam functionality (in addition to the personal firewall and antivirus functionality) primarily because he anticipates that voice and SMS/MMS spam will become a problem for AcmeGizmo employees in the future. He hasn’t yet heard overwhelming demand for such a solution, but he’s (understandably) vigilant: There have been a few complaints, and he’s been reading in trade journals that these types of spam are becoming more prevalent. The antispam functionality provides additional coverage, supplementing the antispam solution that protects AcmeGizmo’s Microsoft Exchange Server (which processes the corporate e-mail).

Device encryption

Ivan has also decided to implement encryption on AcmeGizmo mobile devices. (Smart guy, Ivan.) Since sensitive corporate data is stored not only on the primary smartphone disc but also on removable media such as SD cards, Ivan created a policy that covered both those hardware components.

He surveyed the various devices and operating systems in use across the company, and he quickly found that some of those devices had native or built-in encryption capabilities, while others required additional third-party software in order to encrypt.

On platforms where encryption was native, Ivan configured the AcmeGizmo Mobile Device Management (MDM) solution to ensure that each device complied with the encryption policy. On other platforms, Ivan had to purchase a third-party software solution to enable device encryption. As with the native devices, Ivan made sure that both the on-device disc and any removable media were protected by the encryption product.

Flash forward

Several weeks later, Alvin from Accounting downloaded a malicious application from a shady website to his smartphone. Fortunately, the antivirus solution detected that application, saving Alvin (and Ivan) from the embarrassment of another malware incident on one of the company smartphones. This was very fortunate because (as is the case with more smartphones all the time) the AcmeGizmo smartphones contained sensitive corporate data. Alvin’s device, for example, contained all the company financial data from the recent quarter, because he wanted to review some of it while on vacation with his family.

Not only is the device protected from malware, but the encryption — along with the capability to wipe the device remotely if Alvin were to lose it — also has Ivan sleeping much better at night. Especially when he can turn off his smartphone.