BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Mobile application security is such a new domain that enterprises unwittingly expose their data -- and their customers' data -- to vulnerabilities. Manish Mathuria, co-founder and chief technology officer of InfoStretch Corp., a mobile application lifecycle management company, will discuss mobile application security concerns at the upcoming Quest conference 2014. His session is aptly named, Your Enterprise Mobility: How secure?
In the following Q&A, Mathuria provides insight into mobile security and offers strategies for enterprises to better protect their software. This Q&A has been edited for length, clarity and editorial style.
When it comes to mobile app security testing, what are enterprise application developers worried about?
Manish Mathuria: It's definitely very near and dear to CIOs. Most brands have apps that do something significant with the end users' mobile device. This device stores all kinds of data -- their personal information, their contacts, their calendars, things like that. So the companies and enterprises building mobile apps are definitely concerned about security from multiple sides.
One thing is that mobile app platforms are relatively new, and therefore, both the know-how -- as well as inherent security in the code -- is not very well understood. I have about five years of experience developing mobile apps. That is considered a very long time. I might not have understood how the security model works, so inadvertently I'm writing code that is subject to vulnerability.
Then, in the overall process of releasing the applications, enterprises are not that concerned or that knowledgeable about hardening the code against reverse engineering. I could get a binary and could basically reverse engineer the code. Worse yet, I could even take that code and republish it on the marketplace under a slightly different name and an unsuspecting user would not even realize which one is the real application. Particularly on an Android marketplace, this has been very common.
Manish Mathuriaco-founder and CTO, InfoStretch Corp.
Then there is this whole surrounding environment on the device. Existing malware on the device could tamper with the exchange of information, which is either happening with the storage of the device or via communicating or via interaction with other applications, such as sending a text, or receiving a text, or interacting with an email application; there are various ways that an app could be subject to vulnerabilities. So these are a few areas that are high on the radar where potential data breaches can sneak in.
What tools would help development teams with mobile app security testing?
Mathuria: That's a good question. What we have found is that there is no one tool that is sacrosanct in terms of resolving all security-related testing. We work with a couple of tool vendors, primarily Veracode and IBM, and we have expertise in their products. These bigger tools are definitely our first path. In addition to that, we create a suite of other tests, either manual or automated, through an open source tool.
Our open source tools tend to look for specific vulnerabilities. So, for example, if your app is writing data to storage on the device or using an embedded sequel database, there are specific tools that we can run on the app that tells us if there are any sequel-related vulnerabilities. We have found that we can sometimes expose these vulnerabilities through open source tools, vulnerabilities that we were not able to expose through commercial tools.
Could you provide some examples of a mobile app security breach? What exactly is at stake?
Mathuria: There's a lot at risk. It starts with something very obvious like identity theft. Malware could leak out access to my significant accounts and then log in to those accounts and capture my identity information.
In addition to that, a device has a lot more other data. When I access my application through a browser, a lot of things are sandboxed by the nature of how the browser works. If there is a lot of personal content that I have on my computer and I'm accessing something through the browser, the vulnerabilities can exist only in the way the browser communicates with the server; [that is] not so on a mobile device.
On a mobile device, if I somehow got the wrong app on my device, then this app would get permissions from me to access my contacts, to access my email, my other information and potentially access the data storage and get a lot of information from there. This is much worse than what could happen just through a browser. And it's just waiting to happen. So far we have had a lot of mobile malware-related incidents that haven't resulted in a major brand getting significantly impacted. But a more significant incident is just waiting to happen.
What advice do you have for developers who are just getting started in mobile security?
Mathuria: The first thing is, be aware that mobile security testing should be mainstream. Doing static analysis of code, for example, is a basic thing that will give you the biggest bang for your buck. Using tools to do static analysis of code will point out the obvious mistakes.
It will also point out a lot of false positives, but, typically, more information is not necessarily bad. It could throw so many false positives at you that you would be forced to discuss it with the development team. In that process, the QA [quality assurance] team and the development team both become aware of what that potential breach could be.
So just running basic tests, static analysis tests, through the code teaches you a lot. That's at the core. And then, in addition to that, expanding the test horizon where you are hardening the code, developing standards around it, not releasing software before those standards are met.
This is what we at InfoStretch help with. When we go to a customer, it's a lot of education. We don't just run the tests. The biggest part of our efforts is spent on developing the standards and augmenting their release standards so that security becomes an integral part of their release cycle.