Figure 2-7: A ransom note posted on jailbroken iPhones.
Going to the website directs the user to send five euros to a PayPal account, after which the hacker will e-mail instructions to remove the hack, which most likely involves restoring the iPhone to factory settings. Now in relative terms, this is not a serious attack, and any compromised iPhone user will more than likely be willing to pony up five euros to get on with his life. However, the underlying vulnerability that is exposed by the user experimentation is the worrying part.
Another variant of this type of attack involved a hacker taking over the background screen of the iPhone and posting an image of yesteryear’s pop singer Rick Astley, as shown in Figure 2-8. Annoying for sure. Imagine Invasion by Alien Rick Astleys.
While the risk of a hacked phone is quite obvious, what isn’t as obvious is how a compromised phone could play havoc with enterprise data. For instance, all the data stored on the phone is now at the mercy of the malware. Similarly, any enterprise applications that can access corporate servers are also now vulnerable. One of more common pieces of malware turns on voice recording when the user is on the phone. Imagine a conversation between your employee and the CFO on the revenue numbers for the current quarter being surreptitiously recorded and spied on by unscrupulous third parties. The party is just starting, so get on your dancing boots.
Figure 2-8: Rick Astley in the background of a hacked iPhone.
Secure Shell (SSH) is a network protocol that allows data to be exchanged using a secure channel between two networked devices. It’s a common administration tool that is used to configure and troubleshoot remote devices. In an infected device, the recommendation is to navigate to /private/var/mobile/home, which hosts the viral files. Files named inst, cydia.tgz, duh, sshd, and syslog should be removed to deactivate the malware. As you will see later in this chapter, the manual process of removing these files on hundreds of thousands of enterprise devices is challenging, and there needs to be a more automated and scalable way of doing this. Fortunately, there is one. Keep reading.
Infesting enterprise systems by using location-based services
LBS (location-based services) has been widely recognized as the one of a handful of types of mobile applications that have the potential to become the next SMS in terms of user-base penetration, revenue opportunity, and customer adoption. LBS is any type of service (typically delivered on a mobile device) that utilizes the location of the device to customize the service offering. Examples include coupons from nearby restaurants, instant location-based social networking, and so on.
Why is this technology so hot? That’s simple — the ability to track the location of users and serve them with customized information that is of value at that time and place is an unbeatable proposition. SMS is arguably the most enduring and consistently high-revenue-generating service that providers globally continue to monetize. However SMS’s ubiquity is not without its issues. SMS-based spam is one such irritant. Figure 2-9 shows examples of SMS spamming on an Airtel (an India-based mobile operator) customer’s phone.
Figure 2-9: SMS spamming from an online retailer in India.
What does this mean for LBS? Can it be exploited the same way as SMS? You’re reading this book, so you know that with every mobile opportunity comes the possibility for exploitation. Mobile users constantly trade privacy for convenience. The reason why LBS can be much more intrusive than SMS is the ability of the service provider to obtain the user’s location. The convenience of a service that the user really wants may be a reason that he is willing to trade his location details. However, given the large number of applications that mobile users download regularly, individual location information that is used by each application is not always known. It is certain that some of these applications could not only use the location information for pushing unwanted ads or messages but also share this location information with third parties. The third party could then spam the user, and worse still, the spam could be a veiled phishing attack that compromises the device and its contents. That is why location-based spamming is so problematic. Say your employees are traveling around with smart devices that talk to the network all the time, advertising their coordinates. Spammers salivate for this kind of information so they can serve up customized spam to a targeted user base and veiled phishing attacks that could cause even the most wary and alert users to succumb.
Thwarting spam-only applications
There have been some positive developments on the vendors’ front to thwart spam-only applications. A spam-only application is an unsolicited intrusion into the user’s device by proffering up services — some legitimate (and solely out to make a quick buck) and others nefarious (trying to lure the user and compromising the device in the process). In fact, at Apple’s iPhone development center website, it clearly states this:
If you build your application with features based on a user’s location, make sure these features provide beneficial information. If your app uses location-based information primarily to enable mobile advertisers to deliver targeted ads based on a user’s location, your app will be returned to you by the App Store Review Team for modification before it can be posted to the App Store.
While it’s encouraging to see this proactive stance by the regulator of the most popular App Store in the universe, there will always be more fertile ground for the spammers that is less likely to be as regulated, such as the Android Market, where spammers can sell their wares. And even in the Apple App Store, there is opportunity for spurious applications to circumvent the controls. Once Apple catches on, that loophole will be closed, but another will emerge and be exploited, and the cycle will go on.
At the face of it, location-based spamming does not seem like much of a problem because your users are being spammed all day long, anyway, and have tools and the common sense to filter these out. However, mobile spam is much more sinister in nature because the spammers use the location information to lure individuals, tempting them to hit an MMS or SMS or web page pop-up that seems very topical. For instance, your employee is driving by a movie theater on Friday evening and gets an offer for a coupon for a free drink and popcorn if she hits the accept button. When she does, her phone is infected by a Trojan that controls her smartphone and, by extension, your data, if she has connected to the network.
Assessing the Arsenal
In earlier sections of the chapter, we scour the mobile landscape evaluating the device characteristics, the infection vectors that could get a device compromised, and the risk of having compromised devices in your network. Now it’s time to look at your arsenal of tools and find out how you can fight back against this growing threat.
To manage or not to manage
Say, for example, that until recently you have been issuing handsets to employees on behalf of the enterprise and, therefore, have been legally authorized to install monitoring, troubleshooting, and security applications at the behest of the corporation. Now, increasingly, your employees are demanding that they bring their own devices into the enterprise. This poses an interesting dilemma. Is an employee-owned phone accessing the enterprise network to connect to and use enterprise data considered an enterprise phone? If so, the legal definition of an enterprise-owned asset can be applied; and monitoring, security, and remote management capabilities can be handily used on the employee-owned handset.
If, on the other hand, this device does not fall under the purview of an enterprise asset, you have a problem on your hands because you have a bevy of uncontrolled and unmonitored devices roaming freely in your enterprise. Remember, the devices were bought by employees, and denying them access would be enough to cause a riot. However, expressly installing applications on each and every device is not only impractical, given the breadth of devices and the manual implications of such an endeavor, but also tough to sustain (given your shrinking IT budget).
So the takeaway here is that you need to be cognizant of this dichotomy and embrace a security policy that covers both enterprise-own
ed and employee-owned devices with a consistent view of protecting enterprise assets.
Chapter 4 goes into detail about how you can craft enterprise security policies that take into account these two classes of devices: enterprise-issued managed devices and employee-owned and -customized devices.
Where the need for compliance comes in
Do you work in a highly regulated environment, saddled with Sarbanes-Oxley, PCI, HIPAA, and the more recent bevy of financial regulations? Technically, your brethren in the utility, oil and gas, and airline industries are also saddled with regulations. So while you may feel burdened with staying in compliance, it is not a unique challenge to the IT industry.
Some of the weakest links in your enterprise asset chain are all those mobile devices. It puts your work processes in a precarious position because it leaves you vulnerable in the event of an audit, not to mention the larger business is at risk as well. The need to protect PII (personally identifiable information), confidential client information, and proprietary company data are the key tenets of many of these regulatory requirements, and the surge of mobile devices is eating through your compliance.
Mobile security apps start to emerge
Companies are starting to realize that you need to be armed with tools to protect your enterprise and its users. Companies such as SMobile (acquired by Juniper Networks in July 2010), Lookout, and others have security applications that are available on a variety of smartphones with the express purpose of providing a secure experience, including antivirus, URL filtering, malware detection, encryption capabilities, and so on. In addition, mobile-specific applications like SMS are also getting attention. Diversinet offers an SMS solution with robust encryption and authentication to augment the somewhat weak security that is built into SMS.
This means that the tools for enterprise mobile device security are increasingly available. You can start to experiment and roll out solutions to enterprise network users. The ubiquity of devices and their operating systems means that any solution that you employ needs to support at least the top smartphones in the enterprise so that you can cover the broad customer base with smartphones.
Planning to Sustainably Keep the Threat at Bay
The mobile device security problem is real and likely to get worse unless you take proactive measures. And because an after-the-fact security plan is much harder to implement, it is better to take the time now to define the devices, operating systems, and management applications that you will support and what levels of access you want to provide based on the posture (that is, the real-time assessment of the security grade of the device, taking into consideration the patch level and operating system version and the applications as well as any add-on features turned on by the user), location, and the device itself. In the following sections, we introduce some defensive postures that you should consider and then go into more detail in other chapters of the book.
Establish enforceable policies
However sticky this may be, the need to ensure that basic policies are enforceable on the devices accessing the enterprise is one of your fundamental challenges. Typically, these policies would be in the realm of
Browser usage
Video player usage
Camera and video camera usage
Installation of approved and unapproved applications
Use of screen capture
Use of location information
SMS usage
Connecting via Bluetooth
Connecting via Wi-Fi
Tethering
Use of encryption
Use of cloud backup services
Use of local removable storage
Chapter 4 delves into the details of policy implementation.
Policy needs to be a constantly evolving template that you update with the rapidity of evolving devices, operating systems, and applications. Therefore, a “create it once and forget it” mentality is not a viable modus operandi. For example, you might need to add a jailbreaking policy to deal with a practice that may not have been in existence when you first created your smartphone policy definition. With the landmark judgment passed by the Library of Congress in August 2010 that essentially makes jailbreaking legal in the United States, you now have to adapt your policy with the assumption that an increasing number of jailbroken phones will be winding their way into your enterprise. Don’t be surprised by a breach or loophole that is exploited because you don’t have a policy that covers this relatively new phenomenon.
Evaluate tools without biases
While it may seem very comfortable for you to go after security solutions that you have already deployed in the enterprise, from a vendor sourcing perspective realize that smartphones are very different beasts. Do yourself a favor by looking at the new mobile vendors who have offerings tailored for smartphones. Take into account the smaller memory footprint, battery life, location awareness, and myriad wireless interfaces, each presenting a unique attack surface. Also, the highly customizable nature of these devices means that any solution that you employ needs to be adaptable to suit the changing posture of the end device and to ensure that the device is secured at all times, or you should at least be able to flag deviations to policies so you can take remedial action.
Secure the location
Even though it sounds superfluous, it still bears repetition that the single most important attribute that a smartphone has — compared to its fixed counterpart — is its ability to move. Therefore, its location attribute is its crown jewel. This has not been lost upon vendors and app developers alike. Compromising a smartphone’s location attribute has resulted in services like location-based spamming (LBS) that utilize this attribute as their coordinates for delivering services. It is important to note that while LBS has a multitude of very genuine and user-friendly applications, an offshoot of a location-based service is location-based spamming, which can cause angst both to the user and to you. (We discuss location-based spamming in more detail in the section “Infesting enterprise systems by using location-based services,” earlier in this chapter.)
One of the top challenges for you is to ensure that the smartphone’s geopositioning ability is protected so that the location of your employees is not inadvertently disclosed by spurious applications. You need to develop in-house tools or deploy third-party tools that guard this attribute religiously and warn the user about any potential disclosure of location to unscrupulous persons. (The most obvious culprit to use and misuse this information is a web browser that employs the Geolocation API, which is a web standard.)
Browser vendors such as Mozilla (see Figure 2-10) are giving more controls to the end user to protect this critical information, but it’s unfair to burden the end user with these kinds of critical decisions. It’s up to you to both educate and preferably automate these kinds of decisions on behalf of your users so their security is not compromised.
Figure 2-10: Mozilla location-aware browsing controls.
It might sound spooky, but there is an element of your users’ physical security at risk here, too. Imagine that the snooper has critical access to some enterprise assets and therefore launches a location-based theft. Some of the most popular social network applications — Foursquare, Twitter, and Facebook — have geolocation features for users to track their friends, and this information can easily be used by not-so-friendly folks for nefarious activities.
Imagine that a high-ranking individual in your finance department ends up with one of these nefarious applications on his mobile device. Based on the location information that the device advertises, the user’s whereabouts can be tracked down, and the device can be pilfered to obtain access to sensitive financial information.
Mobile security 101 classes
You must take it upon yourself to educate the mobile device users who connect to your network. This training could take various forms: online webcasts, live discussions, and some real-world classes to drive home the point. It isn’t easy to convince these “smart” smartphone users to
take the time to understand issues that they don’t even know exist, so some amount of doomsday-scenario portrayal that gets their attention is encouraged.
You might consider revoking all access to the enterprise network until the user has taken the training and passed the quiz with a respectable grade.
Because user awareness is so critical to the success of mobile device security in the enterprise, the time and effort invested in creating the training program and certifying the user community are well worth it. Trust us on this point.
We highly recommend periodic recertification of the user community because the target is always moving. The training also has to be kept up to date. Unless the solution is kept current, with periodic updates to the policy and the corresponding education of the workforce, the solution becomes impotent.
One thing you should be aware of is that the language used to educate users should be simple. Explaining the policy with anything that is overly technical, convoluted, or full of jargon will result in nonconformance or defiance. For instance, Figure 2-11 could be a poster on every users’ corkboard that they can glance at every now and then to refresh their memory. The language is clear, concise, and simple.
Figure 2-11: A sample mobile security cheat sheet.
Turning mobile devices into allies
However daunting all this may at first seem, there is no getting around the fact that you need to have a presence on any end device connecting to your network. Watch for this catchphrase: “Connecting to the network.”
Your users connect to the network with various types of devices with myriad operating systems. Preinstalling a client on all of these devices is an intractable problem, but there is a common action here that you can leverage. In essence, whenever a smartphone attaches to the network — defined here as some sort of authentication scheme followed by encryption — this mandatory action of authentication can be followed by a network-initiated device agent download, which is customized to the device attaching to the network and therefore guarantees that a client resides on every smartphone attaching to the network. Figure 2-12 illustrates how a device agent works.
Mobile Device Security For Dummies Page 7
