I love my smartphone. I use it all the time and it is my first reference point for almost any question. I have also come to depend on many of the apps to support my daily tasks. As more and more people become dependent on these apps, how do we know they are secure and protecting us from cyber risks?
Celebrities have had their phones hacked and pictures stolen. Starbucks recently allowed that its phone app passed user passwords in clear text. Millions of Android users just found out that they are vulnerable to the Heartbleed security flaw. In fact, one study collected 8,260,509 unique malware installation packs targeted at mobile devices, the majority of which were aimed at stealing money or personal data.
Everyday users have a responsibility to keep their phones secure by using strong (and unique!) passwords for your phone, your voicemail, and your phone accounts; installing security, encryption, and anti-malware software; and not going to untrustworthy sites. Companies that produce mobile apps, however, must do their part as well. As a consumer, I should be able to trust that mobile applications, especially ones that have sensitive data, have undergone sufficient security testing and evaluation. Oftentimes, speed to release trumps security evaluation and this pushes unacceptable risk onto unknowing consumers.
Smartphone users should be able to rely on software development companies to create secure mobile apps.
Companies have a responsibility to their customers to secure their mobile applications.
Here’s a cookbook for companies on how to build a realistic application security model. (Most of these steps are good guidelines for web applications as well.)
1) Has the code been reviewed?
Code should be regularly scanned for security vulnerabilities during the development cycle. Companies that have to go back and add security after development often find that it can be more expensive. As Chris Wysopal, chief technology officer for Veracode , recently wrote in an article for SC Magazine, “it is cheapest to detect and correct defects as early in the process as practical.” He goes on to explain that a design flaw not detected until final testing will likely require hundreds of other lines of code to be changed and retested, as well. Whereas, if the flaw were detected during a threat-modeling exercise before any code is actually written, one could save both time and money. Further, I believe, this review should include all mobile application components, including the app that is installed on the smartphones itself (i.e. Android, Apple AAPL +0.64%, Windows), authentication process, web services, and middleware components.
2) Has the app undergone security testing?
Applications produced should be automatically tested as part of a build automation process. This testing process then becomes as common as compiling and version controlling to validate the hardening of the bits and bytes while still under development. Using an automated build cycle and functional testing for common vulnerabilities, such as SQL Injection, Cross-site scripting, and user-role permissions, provides peace of mind that the new feature has not introduced a new vulnerability along with it.
3) Who actually wrote this?
All development staff should have received some secure application development security training. It is not realistic for all developers to be security experts, but they must understand the fundamentals of web application security as they have a very real part in the security process that is too often overlooked. Again, correcting mistakes at the end of the development cycle typically results in additional time and expenses. There is minimal cost involved in general best practice instruction for developers. These can also be tailored for web developers and mobile developers. In the end, this makes #1 much less painful.
4) Are there security gaps?
Once developed, applications bring together multiple different components. Each component may add additional vulnerabilities along with it. It is important to stay up-to-date with the latest releases and security patches for every third-party component that is a part of the app. For instance, the Heartbleed vulnerability will affect applications for months because many companies do not realize that OpenSSL is a component of their application and are not aware of the vulnerability. Web services and middleware are other components that must be included in application security testing, but are often left out. Lastly, once fully integrated, there can still be business logic flaws in the application that allow an attacker to gain access to information for which they do not privileges. Therefore, business logic testing of the application in its final state should be incorporated into all development lifecycles.
5) What else should be done?
Hackers will always prefer to attack the weakest link, and for many companies that may be their applications. However, by following items 1-4, the weakest link shifts to other aspects of the technology architecture, such as the infrastructure, the people, and the processes. By utilizing other testing techniques such as penetration testing, infrastructure tests, and risk reviews, a company can gain a holistic view into its weakest links and prioritize accordingly.
In the end, we want information as close and as ready as possible. In today’s world, that’s usually with our phones, and we want apps to push more information to us through this medium. Organizations that follow this cookbook above and build a cyber resilience approach will gain my confidence and win market share.
Matthew Goche is a Director in Sungard AS’ consulting business responsible for security services. He leads the development of SunGard AS’ security solutions and expansion into new client markets. Mr. Goche firmly believes that his role includes educating organizations on the risks to their business, brand, data, employees, and customers posed by security vulnerabilities. He can be contacted at Matthew.Goche@sungard.com.
Trevor Christiansen is a Senior Consultant with Sungard AS’ consulting business. He is an expert in information security and threat analysis, but given today’s cyber challenges, focuses most of his attention on web security. Mr. Christiansen has worked in the information security industry for over 15 years. Prior to being hired on at SunGard AS he was responsible for securing classified networks for the Department of Defense.