March 26, 2012

Mobile Malware: Coming Soon to a Device Near You

Several companies that closely track real-world computer networking threats have recently released reports on the state of mobile malware. While the findings are sobering, it's not exactly a shocker that incidents of mobile malware are on the rise.

Narcissistic hackers have traditionally targeted the most popular computing platforms so their mischief can achieve maximum notoriety; now, they're also doing it for optimum financial gain. And increasingly, the popular platforms in their crosshairs are mobile ones.

In fact, 2011 saw a 155% rise in mobile malware across all mobile operating systems, according to Juniper Networks' 2011 Mobile Threats Report. And Juniper reports that those targeting Google's Android operating system jumped - wait for it - 3,325% in just the last seven months of 2011, from 400 samples in June to over 13,000 samples by the end of 2011. Ouch!

WirelessTN-March-27-ART.jpgMcAfee Labs last month reported that mobile malware had recorded its busiest year to date (see figure) - while PC malware actually declined. Symantec's 2012 State of Mobility Survey, also published last month, calculated that mobile security incidents cost enterprises $429,000 on average annually and cost small businesses $126,000.

What does all this mean and what can you do about it?

Android Is Top Target

The Google Android mobile OS now runs on about half of the world's smart phones. Given the bring-your-own-device (BYOD) trend, it's unrealistic to think you can keep Android-based devices out of your organization. Yet Google's Android Market, the company's own app store that offers more than 300,000 apps, suffered several high-profile malware attacks last year, forcing Google to disable some infected apps remotely. Some reasons for Android's vulnerability:

  • Its "openness."  Though open platforms foster creativity and drive choice in apps and hardware support, the downside is that lots of people understand the OS and can thus exploit it. (Think "Windows.")
  • Low level of rigor in reviewing apps sold in Google's Android Market.  This makes it easier for the bad stuff to get into the store. There are also alternative Android app stores, not officially endorsed by Google, and some have included repackaged versions of legitimate apps that include adware or Trojans.
  • Increasingly broad adoption, driving hackers to Android like moths to a flame.

Could Apple's Stinginess Backfire?

Apple's iOS platform has been the most secure because of its closed ecosystem. But Apple's stinginess with low-level APIs means that iOS developers can't easily determine if an Apple device has been jailbroken or peek into other applications' sandboxes to identify (much less remove) suspected malware. 

And despite Apple's tight policing of what goes into its App Store, some chinks in the process have appeared. For example, recently it became public that the App Store has accepted and sold apps such as PATH Train, which transmit a user's full address book to remote servers for later reference, without permission - though collecting contact data without user consent violates Apple's guidelines.

While Apple generally does a good job of keeping intrusions at bay, such incidents could shake industry confidence in Apple's ability to find a fix before financially motivated hackers succeed with an exploit. 

Fighting Back

The advanced rate at which folks download new apps are making the apps themselves a popular vehicle for infections. For example, malware can be tied to a free game or utility that users don't think twice about downloading.

So, consider building your own enterprise app store (EAS) to deliver mobile business apps from your own servers to employees based on their access rights. Doing so is possible with Android apps but not with iOS, because of Apple's tight reign on public apps. Your mobility administrator can block App Store downloads and push enterprise-developed apps over the air to iOS devices, but cannot push or remove public Apple App Store apps.

For non-iOS devices, consider a policy of application whitelisting. By allowing only whitelisted applications to be installed, you can test software before releasing it to users. Depending on the limitations of each mobile OS, you can whitelist/blacklist applications using most mobile device management (MDM) systems and services on the market, many of which offer EAS capabilities.

Also, MDM providers, some Wi-Fi vendors and others are offering wireless network access control (NAC) capabilities, which scan mobile devices for the state of their security posture and compliance with the latest malware-fighting software versions before allowing them onto the network. Again, this is more about fighting Android malware, because iOS APIs don't currently permit effective anti-malware measures.

Let's face facts: Mobile devices are now powerful endpoints that require the same attention given to traditional PCs. So it's time to integrate mobility management into your overall IT provisioning and management framework.


3 Comments

Joanie, I recommend a variation on your recommended security posture scan at at network connect. For enterprises using MDM to provision and enforce mobile device security policy, MDM can detect deviations in security posture (jailbroken and rooted devices) in near-real-time and then disable enterprise service and data access immediately (not just at next network connect).

For example, if a user installs a blacklisted AppStore or Android app, MDM can immediately remove Exchange and enterprise Wi-Fi and VPN settings and credentials that give that device enterprise access.

If corporate data is sandboxed in an encrypted container, that container and any enterprise apps that use it can be remotely disabled by removing keys or profiles. A notification can be presented to the user, suggesting he or she remove the blacklisted app to regain access. Once the user complies, access can be immediately restored.

And if a compromise is permanent and high-risk (think C-level exec who just visited the JailbreakMe website on his iPad), MDM can remotely wipe the device over 3G, without waiting for it to reconnect to email or VPN, etc.

In short, putting mobile devices under MDM control gives enterprises a range of tools to take immediate action to detect and remediate non-compliance - including but not limited to mobile malware. Note that these controls can apply even when mobile malware scanning occurs elsewhere (e.g., at mail server, "in the cloud") as it must for today's iOS devices.

Hello Joanie,
I find your views here to be 98% on target, and it is great to see articles of this nature being produced. The 2% loss here is due to this statement

"So, consider building your own enterprise app store (EAS) to deliver mobile business apps from your own servers to employees based on their access rights. Doing so is possible with Android apps but not with iOS,"

While it is true, Apple forces you to buy expensive Enterprise Distribution Licensing, you can have private iOS apps in your own Private App Store. At Sayers our mobility practice works with customers of all kinds faced with the BYOD push. We favor solutions that allow for encrypted apps delivered from a secure private app store over classic MDM only offerings.

Again Thank you for such a well presented read on the state of Mobility Affairs!

Best regards,
Jerry Buote
Sayers

Hi, Jerry - Yes, companies that participate in Apple's developer program can write and push enterprise apps from their own private app stores. What nobody can do (at least for non-jailbroken iOS devices) is push or remove public apps that Apple insists upon distributing only through the Apple App Store.

In summary, let’s say I’m an enterprise. I probably want one place - call it an enterprise app store (EAS) - that employees can visit to download all the mobile apps they will need for work. Those apps likely include a mix of homegrown apps and some public apps offered at the Apple App store.

I can develop and push the homegrown iOS apps through my own private app store that I host on site using EAS or MDM tools or that a third party other than Apple hosts. However, to get the public iOS apps they need, employees have to separately download them from Apple's App Store. So that's two places, not one, where users need to go to get their required apps.

Apple’s Volume Pricing Program (VPP) does allow me to buy these "whitelisted" apps in bulk. Employees can use a special redepmption code for downloading them so that they aren’t personally charged, which could cause post-sale reimbursement administrivia.

However, users have to actively pull those public iOS apps I’ve bought for them down themselves from a place other than my EAS: from the Apple App Store. So I can’t ensure that the whitelisted apps are on the user’s device unless the user cooperates. And I can’t enforce blacklisted Apple public apps by forcibly removing them. iOS 5 allows me to ALLOW ALL apps from the App Store or to DISALLOW ALL from the App Store. If an employee downloads a blacklisted app, I can't remove it. Depending on the tools I'm using, I might get an alert or an email that a non-desirable app is on a user's device, or I might be able to remotely wipe the entire device. However, what no product on the market can do is selectively prevent that one app from being downloaded, because Apple doesn't provide such an API.

Thanks for reading and writing! - Joanie

Search Webtorials

Get E-News and Notices via Email


  

 



  

I accept Webtorials' Terms and Conditions.

Trending Discussions

See more discussions...

Featured Sponsor Microsites






















Archives

Notices

Please note: By downloading this information, you acknowledge that the sponsor(s) of this information may contact you, providing that they give you the option of opting out of further communications from them concerning this information.  Also, by your downloading this information, you agree that the information is for your personal use only and that this information may not be retransmitted to others or reposted on another web site.  Continuing past this point indicates your acceptance of our terms of use as specified at Terms of Use.

Webtorial® is a registered servicemark of Distributed Networking Associates. The Webtorial logo is a servicemark of Distributed Networking Associates. Copyright 1999-2018, Distributed Networking Associates, Inc.