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.
Understanding the vulnerability of Bluetooth
One particular area of vulnerability for the mobile device is the Bluetooth interface. Traditionally, Bluetooth has been an adjunct communication interface used for connecting to wireless headsets and keyboards, to the smartphone integration system in cars, and to other such accessories. More recently, Bluetooth has become a conduit for Internet connectivity using a technique called tethering that allows the mobile device to function like a “modem” through which your desktop or laptop can connect to the Internet. All in all, the hitherto-unsung Bluetooth interface is becoming more prominent for your users. Keep in mind, however, that most device-based firewalls typically cover all IP interfaces — WLAN, GPRS/EDGE, 3G, LTE, and the like — and they may not provide specific coverage for the Bluetooth interface. And if your users fire up Bluetooth, assuming coverage while blissfully unaware of the vulnerability, they may be lulled into a false sense of security. (“Hey, the firewall on my smartphone has me covered, right?” Well, no.)
The first recommendation you may want to make to your users is, “Turn off Bluetooth.” Reality check: That’s not practical, and even less likely to be followed. But even the National Institute of Standards and Technology (NIST) took up the refrain when it issued its “Guidelines on Cell Phone and PDA Security,” recommending that the user actually “curb wireless interfaces.” The idea was for users to turn off any interface they weren’t using until those interfaces were actually needed. Here’s another reality check: The majority of your users most likely favor the convenience of “always-on” interfaces. They’d rather not go through the trouble of turning those things on and off “as needed,” and that’s unlikely to change. Clearly you need a more pragmatic solution.
Optimistically, it’s only a matter of time until Bluetooth interface security shows up among the features that on-device firewalls offer. Until that happens, you can include a Bluetooth-specific firewall, in addition to the on-device firewall, as part of your recommendation. For instance, Fruit Mobile offers a firewall for Android devices that protects specifically against Bluetooth attacks, as shown here in the figure.
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.
Figure 10-3: Mobile virus propagation techniques.
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.
Falling victim on social media
A variant of the traditional Internet download is the social engineering–driven malware download. For instance, if your users see that their online friends are downloading a particular Facebook application, they feel compelled to do the same. They figure they can trust their friends to download “safe” applications (“Well, duh! They’d never do anything, like, unsafe or something, right?”), and they don’t want to miss out on all the fun and action their friends must be having. Using this kind of ingenious social engineering, malware authors can easily penetrate a social group and then watch the “fun” as users self-inflict injury, confusion, damage, and pain. One nasty and clever worm called “Koobface” (a play on the name “Facebook”) was written specifically to target Facebook using components like these:
Koobface downloader
Social network propagation components
Web server component
Ads pusher and rogue antivirus installer
CAPTCHA breaker
Data stealer
Web search hijackers
Rogue DNS changer
Looks like a list of features for a sophisticated product, doesn’t it? And that’s exactly what Koobface is, except this “product” is nefarious, written with the express purpose of infecting accounts, propagating, and stealing Facebook users’ information and identities.
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.
Figure 10-4: Virtual device antivirus solution.
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
Mobile Device Security For Dummies Page 24