Tempus Fugit. Or in other in other words ‘Time Flies‘
And how! After a very busy Q4 to end 2011, I barely had enough time to crank out a guest post on Branden William’s blog around the end of the year. It’s about the ability of virtualization to do what it does – automate things over a large scale – and how that knife cuts both ways. Check it out here.
After a bit of an absence, I’m back to the blog and back with a host of topics. In the next couple of months look for more on Cloud and Virtualization security, as well as a few discussions on how cloud impacts other platforms like mobile. To start the year off (in Feburary), here’s a discussion about mobile platform security in general.
A colleague recently forwarded an OWASP presentation on mobility security to our team. For those not familiar with the Open Web Application Security Project, they are a great collaborative security group that have a number of application security projects worth participating in (http://www.owasp.org). They also produce Top Ten lists. Unlike David Letterman, OWASP talks about top ten risks of various areas of computing. Again, the initial and most updated top ten list focuses on application security. The challenge, however, is when they begin to step beyond the top ten risks of application security and enter other areas.
I’ll review their Cloud Risks in another post, but for now here’s OWASP’s top ten risks for mobile security:
1. Insecure Data Storage
2. Weak Server Side Controls
3. Insufficient Transport Layer Protection
4. Client Side Injection
5. Poor Authentication and Authorization
6. Improper Session Handling
7. Security Decisions via Untrusted Inputs
8. Side Channel Data Leakage
9. Broken Cryptography
10. Sensitive Information Disclosure
To their credit, OWASP clearly defines their focus as the application layer. This allows the developers to make an impact in improving the security of mobile applications, which I certainly applaud. However, the challenge comes when we really look at the risks they articulate, and understand the differentiation between a risk that is unique to the mobile computing environment and a risk that is typical to application development. To my mind, OWASP does an excellent job in talking about secure coding practices. Any additional area looked at should focus on the deltas between general good coding practices and what is unique/challenging about that particular coding environment.
Mobile Computing has Unique Risks
Without a doubt, the mobile computing environment has a different risk profile than other endpoints/clients. OWASP nails this on the head when they talk about Insecure Data Storage, Poor Authentication and Authorization, Security Decisions via Untrusted Inputs, Broken Cryptography and to a certain extent, Sensitive Information Disclosure. The mobile storage platform is far more available compared to other platforms – especially when the ability to access system files or applications on removable SD cards enter the mix. Application programmers need to remember to not assume encryption is at play elsewhere in the environment. Poor authentication and authorization is definitely a mobile platform application challenge. The available computing power on mobile platforms, while much greater than the PCs of yesteryear, still lag the raw capability of more traditional endpoints. Combine that with the challenge presented by having so many interesting potential tokens laying about on the phone like the IMEI, and it can be a recipe for disaster. Especially considering those tokens are endemic to the phone, and not altered or change except in highly unusual circumstances.
The exposure of phone functions to areas not typically associated with phone use is an interesting risk tied to the mobile platform. OWASP captures this when they speak of Security Decisions via Untrusted Inputs. We’re all familiar with malicious apps that dial 900 numbers, send text messages, or publish user data to certain marketing organizations. Placing application security demands on the end user of a phone app is a recipe for a target rich environment. Overall, I think the application market providers have done a fair job of policing their apps to weed out the bad seeds. However, I’m surprised at the lack of policing applications on the phone itself, and the ability of application providers to watchdog other apps is a bit challenging. At the end of the day, it’s definitely a unique risk to the mobile platform.
Broken Crypto isn’t necessary an issue unique to the mobile platform, but it is certainly more prevalent there than more traditional endpoints. This is nominally a function of the raw power of the device to use crypto, or at least it used to be. That’s not as much of an issue any more. The real challenges tend to be in the developer area – either using custom algorithims (read: untested by the community at large) or by not leveraging platform capabilities. A similar approach is taken with the last semi-unique risk: Sensitive Information Disclosure. OWASP makes key points about not hardcoding data at the endpoint when the endpoint isn’t a trusted platform. It is unlikely, although not impossible, that the endpoint will be a trusted platform within the foreseeable future. Too many third party apps, and too many capabilities to bypass existing operating system/platform protections. Mobility apps should be server side, data should be primarily server side, and the control should be kept in the hands of the folks that know how to secure computing assets.
Mobile Computing has the Same Risks as other Platforms
Where OWASP’s list and I part opinion is the remainder of the risks. These are not specific to the mobility platform, but rather general application risks repurposed. Weak Server Side controls, for example, is by definition not a risk specific to the mobile platform, because it’s at the server. It’s important, true. However, it’s equally important to get right for any application, regardless of the target endpoint. Insufficient Transport Layer protection is another category. The fundamental programmatic flaw is one that’s endemic to application programming regardless of endpoint. If I rely on ROT13 to protect data in transit, I deserve what I get from a data exposure standpoint. To be really secure, I always run ROT13 twice. Client Side Injection may be unique, however, it’s still the same general class. Keeping it platform independent here is a challenge, because browser side attacks, XSS (the web feature), and SQL injection are basic web application problems. The twist isn’t the problem, it’s the impact – more direct ability to access phone functions for fraud as opposed to identity theft. Personally, I’m more concerned about the latter than the former.
Improper Session Handling and Side Channel Data Leakage are also common application risks. One of OWASP’s contentions is that mobile application sessions are much longer, however, I’m not as sold on this. When I go to my phone to do my expense reports, check email, or play a game or two, I’m in and out quickly. If I need more time within an app, then I need to switch to a different platform for the greater flexibility. On the other hand, when I’m in my banking app on my PC doing my finances or advanced expense reporting, I’m usually there for a while. It often comes down to a function of screen size. I’d say poor session handling is again a general application problem as opposed to specific to the mobile platform. Ditto with side channels – these are typical. A rogue application on a laptop or PC can accomplish the same ends as a rogue app. The solutions are even the same – don’t store sensitive information in places it can be accessed by other entities.
Mobile Computing has a Vastly Different Set of Users
Again, if it’s not unique to the platform, it shouldn’t be repeated in a custom development area. Having less than 10 risks is okay. In fact, I’d even suggest a substitution here that really needs to be addressed – the knowledge and capability of the user. In corporate environments, we cheat on this last one. We can enforce limited awareness training, but we primarily resort to the cheap technical fixes instead – things like compliance checking, mandated builds, and limited rights. On a mobile platform, we often don’t have that ability, because it isn’t necessarily our platform to control. There’s also a significant education gap to remember. White collar workers that are used to working on computers for business have absorbed some security practices by osmosis. A significant percentage of the population, however, has more computing power in their phone than they do in their workplace. For those folks, there needs to be another solution in place to help address the real security challenges of the mobile platform.
Security practitioners must remember, for all tiers of service, to know the audience. The audience for mobile computing is an inherent risk that has significantly different risk profiles and understanding of computing. Due to that, application security is a good start, but it won’t solve the fundamental problems connected to mobile security. Mobile devices likely already exceed the amount of traditional computers. I’d say we should be looking more at disrupting mobile bot nets and mobile threat modeling now than traditional computing threat modeling.
