IT Still Facing Mobile Challenges

Do you want the good or the bad news about mobile security first? As is so often the case, the news is something of a mixed bag.

The good news is that Apple Inc.'s iOS and Google Inc.'s Android OS incorporate important information security safeguards. According to researchers from Symantec Corp., in fact, both platforms were designed with security in mind.

The bad news is that neither platform seems to have been designed with enterprise security -- or with the manner in which information assets are consumed and disseminated in business contexts -- in mind.

That's the upshot of a sobering new report from Symantec Security Response, A Windows into Mobile Device Security.

"[W]hile these security provisions raise the bar, they may be insufficient to protect the enterprise assets that regularly find their way onto devices," writes Carey Nachenberg, a vice president and fellow with Symantec Security Response.

By far the most intractable difficulty, Nachenberg notes, is that -- almost by definition -- enterprises have much less control over mobile security.

"[V]irtually 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," he writes.

It found that iOS's access control implementation, for example, is "at parity with traditional Windows-based desktops," while Android's ... is less so.

"Android password policy system is sufficient to protect devices against casual attacks," writes Nachenberg. "However, since current versions of Android do not encrypt data stored on the removable SD memory card ... an attacker with physical access to an Android device could simply eject the SD memory card and obtain a subset of the device's data in a matter of seconds, bypassing any and all password controls enabled on the device."

On the other hand, both platforms do an inadequate job of isolating potential exploits: in the case of iOS, a malicious app -- which, in almost any conceivable case, could only be used on a jailbroken phone -- would have more or less unfettered access to the Internet; in the Android scheme, a cracked app could successfully steal or corrupt data, in spite of the Android OS's superficially robust isolation implementation.

That being said, Nachenberg writes, although crackers "have in a small number of instances bypassed Android's isolation system by exploiting [vulnerabilities]" the frequency of vulnerabilities has "been small in number, and most have been fixed quickly."

Nachenberg and Symantec also give iOS high marks for its resistance to malware, thanks largely to Apple's draconian software development model.

"The primary security goal of Apple's provenance approach is to limit malware, and in this regard, Apple has been effective," he reports, adding that malware authors haven't had much -- if any -- success targeting non-cracked (or non-"jailbroken") iOS-powered devices.

There are a few reasons for this, Nachenberg suggests, pointing out that Apple not only requires application developers to obtain a signing certificate (which at the very least entails a registration fee), but also tests every application that's submitted to its App store for potential mischief. Lastly, he argues, "Apple's code-signing model prevents tampering with published apps -- [i.e.,] there is no way for an attacker to maliciously modify another app [e.g., by adding spyware] without breaking the 'seal' on that app's digital signature."

Android -- which has recently been something of a malware magnet -- comes out much the worse in this regard. "History shows us that platforms that allow software developers to anonymously release their applications have experienced larger volumes of malware than those platforms that require each app to be digitally stamped with the certified identity of its author. The Android platform appears to reinforce this historical precedent," Nachenberg writes.