I wrote my first article on mobile device security way back in June 2005. In it, I pondered whether cell phones were going to be the next big security target. This was before the massive convergence of computers and phones. Even back then, we saw the storm brewing. In fact, the first real cell phone worm, Cabir, was released in 2004. SMS (or texting as the kids call it) seemed like an even more obvious vector than Bluetooth and, sure enough, there are plenty of SMS-based attacks to be seen.
Convergence is all done now, and phones, computers, laptops, and iPads are mostly interchangeable. Today, the threats and risks that used to apply only to our Internet-connected computers with all of our personal data, financial data, medical data and so on, apply to all of our mobile devices. Oh, joy.
In fact, it’s even worse than that because those enterprises that battened down the hatches on their computer systems and wireless networks long ago now have to contend with the incredible pace of change involved with mobile devices, even devices their users buy for personal use. BYOD means modern mobile devices hop right on the corporate network as easily as they do at Starbucks. But they are harder to secure than a laptop.
Today’s mobile devices pack quite a technical punch --multi-core, multi-GHz processors, gigabytes of onboard and external storage capability coupled with WiFi, Bluetooth, and GSM or CDA radios -- all packed into a form factor not much larger than a candy bar. Yay. Little computers for your pocket -- and the future of business to boot (there’s an app for that).
Mobile security 101Mobile devices have lots of moving parts to secure, from loaders and hardware at the bottom of the stack, to operating systems, VMs, and platform APIs, all the way to the ubiquitous apps. Each of these areas is prone to potential security weakness, not to mention the gaps between them all. But wait, there’s more. These parts are made, distributed, and used by multiple players who can directly impact the security posture of a device: users and their friends, mobile carriers, app store curators, OS manufacturers, and device manufacturers. Those are only the main players. Questions for another time: Who makes the firmware? Where do the chips come from? Who built in a backdoor for remote management? Each of these players has an opportunity either to build security in properly or to screw things up completely for everyone. Look at this way: We don’t get safe cars, airplanes, medical devices, or any other such thing unless every parts supplier, integrator, and everyone else not only cares about safety, but actually competently does something about it.
ABOUT THE [IN]SECURITY COLUMN
This monthly security column by Gary McGraw started life in print in IT Architect and Networkmagazines and was originally called “[In]security.” That was back in October 2004. The column then transitioned into Web content at several publications before finding a home at SearchSecurity. You can always find pointers to the complete[In]security series on McGraw’s writing page. Your feedback on the column is greatly appreciated.
Each of the moving parts requires real security attention. Running a worldwide consultancy, I've been uniquely positioned to see a wide overview of the entire mobile security landscape, taking on projects that run the gamut from handsets, to carriers, to back-end services. It’s a big landscape out there. We’ve assessed a plethora of parts, including: SMS, mobile and REST, mobile and SOA, and pure mobile apps for all kinds of players, from carriers to financial institutions and credit card consortia.
So what did we learn? We learned something we already know: It’s the software stupid! We can either build all of the moving parts correctly from a security perspective -- and make sure they interact properly -- or we can give up and go home.
BTW, we don’t just mean look for a bunch of bugs (though that’s a good idea, and there are a number of potential problems built right into iOS, Symbian, and Android and their base languages Java and Objective-C). Many of the security weaknesses we have uncovered in real mobile systems are architectural flaws. That means what we have been saying all along about bugs and flaws applies just as well to mobile security as it does to regular software security.
Mobile software security touch pointsIn fact, if there is a silver lining in the big black cloud of mobile security, it’s that what we know about how to carry out software security can be applied directly to mobile security.
A quick review is in order. Pen testing? Good start, especially if you think your mobile app is perfect, because it’s not. A smoking burning pen test result will disavow you of that belief. Code review? You bet. Use a tool for best results. Architectural risk analysis, which is sometimes confused with threat modeling? Yep. Remember the flaws; they will make up at least half of the security defects that need to be fixed. The fact that the app you’re shipping has too much functionality, asks for too much permission to run, and collects way too much personal data. These are all flaws. Oh yeah, and make sure you fix the stuff you find. Too many security vendors and consultants are happy to break your stuff for you (sometimes mysteriously), and too few fix the problems they find. Ironically, if you don’t fix the security defects you find, your mobile system may even be less secure than when you started looking at it!
There are some differences in potential vulnerabilities when it comes to mobile software security, even if the security review techniques are the same. Mobile applications must more diligently authenticate their users, make fewer assumptions about the protection and transport of data, and more carefully handle the storage, creation, and deletion of subscriber data than standard-issue software. Just think about how your view of security would change if you lost your laptop as often as you lose your phone. As you do a review for security, make sure to consider five basic vulnerability areas: architectural flaws, device loss, platform weakness, isolation and permission problems, and application weakness.
Outsource mobile developmentLots of companies are outsourcing their mobile development to others. This happens when internal dev staff has no mobile experience. Sadly (but unsurprisingly), software security problems don’t automatically disappear when somebody else writes the code. In fact, they may be even less invested in security than you are. So, what to do about mobile app code you outsource?
The answer is fairly straightforward: Demand some evidence the vendor you choose has a clue about software security and back that up with service-level agreements (SLAs) that cover security.
If you are only commissioning one app, then by all means pen test the heck out of it. But know that a pen test is no substitute for a real code review, much less an architectural risk analysis. If the app is important enough to your business, make sure to get inside it and check it out thoroughly. Fix what you find. Lather. Rinse. Repeat.
If you are using a vendor to develop lots of mobile apps for you, ask them about their software security initiative and steer them toward the Building Security in Maturity Model (BSIMM). Do they have a software security development lifecycle (SSDL), a software security group (SSG) and a real software security initiative (SSI)? They should, and they should be able to describe them very clearly.
About that app storeIf you decide you need to host an app store of your own, you really have your work cut out for you. Do you stick whatever anyone sends you on your virtual shelves? What about malware? Do you check permissions against some sane notion of required privilege? Do you take responsibility for infecting your customers? Are Trojan horse programs OK by you? Starting and maintaining an app store is a big enough ball of wax that it deserves its own article. Suffice to say, security should be a fundamental concern.
Mobile malwareI recently wrote an article on bad software, aka badware, and malware. Eliminating badware will help solve the malware problem. This insight applies to mobile security just as it does to any other software-based system. Need some fresh evidence? Look no further than the recent Flame malware, which includes a Bluetooth component aimed directly at sucking the secrets out of mobile devices.
If you haven’t started already, it’s time for your company to get its mobile security act together!
No comments:
Post a Comment