Wednesday, June 29, 2011

Symantec: A Window Into Mobile Device Security

Executive Summary

The mass-adoption of both consumer and managed mobile devices in the enterprise has increased employee productivity but has also exposed the enterprise to new security risks. The latest mobile platforms were designed with security in mind—both teams of engineers attempted to build security features directly into the operating system to limit attacks from the outset. However, as the paper discusses, while these security provisions raise the bar, they may be insufficient to protect the enterprise assets that regularly find their way onto devices. Finally, complicating the security picture is the fact that virtually all of today’s mobile devices operate in an ecosystem, much of it not controlled by the enterprise—they connect and synchronize out-of-the-box with third-party cloud services and computers whose security posture is potentially unknown and outside of the enterprise’s control.


Summary of iOS Security

Overall, Symantec considers iOS’s security model to be well designed and thus far it has proven largely resistant to attack. To summarize:

  • iOS’s encryption system provides strong protection of emails and email attachments, and enables device wipe, but thus far has provided less protection against a physical device compromise by a determined attacker.
  • iOS’s provenance approach ensures that Apple vets every single publicly available app. While this vetting approach is not foolproof, and almost certainly can be circumvented by a determined attacker, it has thus far proved a deterrent against malware attacks, data loss attacks, data integrity attacks, and denial of service attacks.
  • iOS’s isolation model totally prevents traditional types of computer viruses and worms, and limits the data that spyware can access. It also limits most network-based attacks, such as buffer overflows, from taking control of the device. However, it does not necessarily prevent all classes of data loss attacks, resource abuse attacks, or data integrity attacks.
  • iOS’s permission model ensures that apps can’t obtain the device’s location, send SMS messages, or initiate phone calls without the owner’s permission.
  • None of iOS’s protection technologies address social engineering attacks such as phishing or spam.

Summary of Android’s Security

Overall, while we believe the Android security model is a major improvement over the models used by traditional desktop and server-based operating systems, it has two major drawbacks. First, its provenance system enables attackers to anonymously create and distribute malware. Second, its permission system, while extremely powerful, ultimately relies upon the user to make important security decisions. Unfortunately, most users are not technically capable of making such decisions and this has already led to social engineering attacks. To summarize:
  • Android’s provenance approach ensures that only digitally signed applications may be installed on Android devices. However, attackers can use anonymous digital certificates to sign their threats and distribute them across the Internet without any certification by Google. Attackers can also easily “trojanize” or inject malicious code into legitimate applications and then easily redistribute them across the Internet, signing them with a new, anonymous certificate. On the plus side, Google does require application authors wishing to distribute their apps via the official Android App Marketplace to pay a fee and register with Google (sharing the developer’s digital signature with Google). As with Apple’s registration approach, this should act as a deterrent to less organized attackers.
  • Android’s default isolation policy effectively isolates apps from each other and from most of the device’s systems including the Android operating system kernel, with several notable exceptions (apps can read all data on the SD card unfettered).
  • Android’s permission model ensures that apps are isolated from virtually every major device system unless they explicitly request access to those systems. Unfortunately, Android ultimately relies upon the user to decide whether or not to grant permissions to an app, leaving Android open to social engineering attacks. Most users are unequipped to make such security decisions, leaving them open to malware and all of the secondary attacks (for example DDoS attacks, Data Loss attacks) that malware can launch.
  • Android recently began offering built-in encryption in Android 3.0. However, earlier versions of Android (running on virtually all mobile phones in the field), contain no encryption capability, instead relying upon isolation and permissions to safeguard data. Thus, a simple jailbreak of an Android phone or theft of the device’s SD card can lead to a significant amount of data loss.
  • As with iOS, Android has no mechanism to prevent social engineering attacks such as phishing attacks or other (off-device) Web-based trickery.

No comments:

Post a Comment