Security in the Unwalled Garden
In fact, according to a recent report by Arxan Technologies, 92 percent of the top 100 paid iOS apps and all 100 of the top 100 paid Android apps have been hacked. This finding, combined with the staggering number of apps and their increasingly mission-critical functions, makes for a huge and growing potential security problem.
Ernst & Young, in its 2012 report on the top 10 risks in the telecom market, cited security concerns in a way that keeps in mind that end users don’t delineate between the security purview of CSPs and that of app developers. “Customers place more trust in operators than in social networks, regarding operators as security guarantors across a range of services,” the report said. “Yet they still hold operators responsible for threats from third parties even for mobile malware attacks and rogue apps.”
Considering that network security has never been flawless, even when telcos or cablecos essentially had sole access to the value chain and sensitive customer information, how then can security be ensured with so many fingers in the pot? The answer increasingly lies with some form of mobile device management (MDM). Especially popular among enterprises looking for the magic formula for reining in BYOD programs, MDM solutions from firms large (Symantec, McAfee and IBM are doing interesting things in the space) and small (AirWatch and Amtel MDM) aim to secure, monitor and manage devices across a range of operating systems and operators.
In addition Symantec is broadening its mobile security push by forming a partner program designed to encourage third-party application developers to bake robust security controls (enforced encryption, for instance) into their products. This sort of back-end development work may be especially useful, as it does little to compromise the front-end user experience. Subscribers don’t feel it in the way they might with an MDM, and the very user experience that draws users to smartphones and tablets could be maintained in an even less adulterated way.
Many, however, are questioning the wisdom of perpetuating such an open system as the current app development climate. After all, virtually anyone can get ahold of the means to create an app, which is a potential entry point for malice on its own, and this potential for malicious action is exacerbated by the open, sharing culture that app development promotes. Code is often reused again and again in the interest of speed and efficiency, which may mean that lots of developers who didn’t write their own code could be passing along just about anything without realizing it. What’s more, the wide availability of code for use by developers also allows potential attackers to view and analyze it, looking for potential weaknesses.
CSPs and device manufacturers who are wary of this process have a few options. They can help to provide some sort of closed code library for app developers that limits access and can be policed for problematic code. They can also heavily limit the permissions of a given developer to ensure that any damage is localized.
And, of course, CSPs and device manufacturers can just start tossing out problematic apps that are popular targets for incursions. Or, instead of blacklisting certain apps they can whitelist certain apps and ban everything else. It’s an approach that’s looking more appetizing for some security experts (you can check out a Forrester blog on the topic here, as well as in this month’s “IT Security From Down Under” article), but one that is downplayed by plenty of security and IT professionals, so imagine how the average consumer would react to the same level of app limitation.
And there’s the challenge we’re left with: in an era in which your customers are as interested in the services you enable as in the services you provide, how do you build your walls in such a way that you can keep intruders out while making sure your interior is still the sort of place your subscribers want to be?
