Where would you rank mobile app security in your overall information security program? Is it a top priority? Maybe you’ve prioritized it somewhere in the middle where you have a budget but know you have plenty of room for improvement. Or, do you consider it a nice-to-have that you’ll address eventually? If you’re like many organizations that I’ve seen, you fall somewhere between budget and eventually. One thing’s for sure, mobile app security risks aren’t going away, and you need to get going.
The world achieved a milestone in October 2016, reports web analytics company StatCounter: Internet usage by mobile devices surpassed that of desktop computers. Whether you have a relatively simple marketing app or something more complex that serves as one of your key products or services, addressing the dangers of mobile app security flaws needs to be front and center in your information security program.
The cost of mobile app security risks
I’d like to convince you why you need to pay attention to mobile app security flaws. For one, the average cost of a data breach was $4 million in 2015 according to the Ponemon Institute. Gartner predicts that by 2017 endpoint breaches will center on mobile devices, and that vulnerabilities or misconfigurations at the app level, as opposed to the device level, will cause 75 percent of mobile security breaches. A NowSecure study of mobile app security found that one-in-four mobile apps contains a high-risk vulnerability. Mobile apps and the devices on which they run may have a small form-factor, but they pack a big punch in terms of business risk.
Vulnerable web applications have been a problem for years. Mobile apps have similar security issues. Like their web counterparts, code-related security flaws in mobile apps result in input validation challenges, the insecure storage and transmission of data, and a lack of security policy enforcement. There is some overlap in the testing of web and mobile apps, but mobile includes unique attack vectors that also need evaluation. Your organization likely invests in security testing for your Web apps, and you need to make sure you apply the same scrutiny to your mobile apps in 2017.
Mobile app security excuses, excuses
In my work, I’ve heard everyone from executives to IT managers to software developers shun the risks created by vulnerable mobile apps. These arguments are not unlike the pushback we experienced related to information security in general 10-to-15 years ago.
When someone learns of a security flaw in their mobile app, I typically hear a combination of excuses, such as:
- It’s just a marketing tool.
- We don’t have anything of value worth hacking.
- We have security policies that make sure everything is in check.
- We require strong passwords and the encryption of data in transit.
- We have an incident response plan we can invoke if needed.
- Our lawyers said we’re okay.
It’s as if many of these people are arguing for their own limitations. People do just that in terms of politics and societal issues all the time, but there’s simply too much to lose both professionally and personally when taking this approach and applying these philosophies to information security.
Fifty-six percent of organizations did not test their mobile apps or were unsure whether they tested them according to another Ponemon Institute study about the state of mobile app security in 2015. This corresponds with what I see in my work. That’s very shortsighted and, frankly, it’s dangerous.
So, what’s it going to be? Ignore the very real risks created by mobile apps and pay the consequences, or do what’s right and perform a more thorough analysis looking at threat vectors, specific vulnerabilities, and tangible business risks? Of course I would recommend taking the latter path, which will require investments in time, effort, and money. However, looking at the bigger picture over the long haul, you’re much better off resolving mobile app security shortcomings and integrating good habits into the software development lifecycle today than you are trying to rationalize why a breach occurred sometime in the future.