The Quandary of Secure Application Development For Enterprises

In recent years, application code (particularly web and mobile application code) has been besieged by hackers around the world, thus catapulting it into the limelight of security regulation boards like the Payment Card Industry (PCI) Security Council.  While some progress to better secure application code has been made in over the past 5 years, it still continues to be one of the top attack vectors for some serious attacks. HP's 2012 Cyber Risk Report reported that 77% of mobile apps had information leakage vulnerabilities. Cenzic’s Application Vulnerability Trends Report from 2014 reported even more discouraging news when it found that 96% of all web/mobile apps contained one or more major vulnerabilities.  Also in 2014, Akamai Technologies’ State of the Internet report revealed that hacking attacks on websites went up 75% at the end of 2013. Now that businesses are expanding more into cloud services and mobile computing the attack surface for application code is going to continue to expand at an exponential rate. 

In today’s society, companies find themselves in the unenviable position of being highly reliant on applications to forge new business, while knowing they may have multiple vulnerabilities that could become the next major data breach headline in tomorrow’s news. To use the analogy of a new car, would you buy a new car with fatal flaws that could result in brake failure while driving? No of course not, yet many companies role out web and mobile applications to the public that could cause the same catastrophic results. Why would companies be so cavalier with the security of their applications?

It is not intentional nor is it a desired outcome, but rather the results of multiple factors coming together and culminating in the perfect storm. Unfortunately application development is not something that can be captured and contained in its own one size fits all nicely kept box.  Different languages, different development cycles, different business requirements, and even different developer tools all complicate the process. Often times, developers are tasked with developing or maintaining code for solutions that are either outdated and being kept on life support or are new groundbreaking ideas that have not been fully baked and therefore all the requirements are unknown. I often hear that the solution is to apply secure coding methods or to develop processes that involve a Secure Software Development Life Cycle (SSDLC).  While these items are very much a part of the solution they do not address the complexities of the problem.  This is because of the different needs and requirements of each developer for their individual platform or development cycle. 

Would you try to operate a PlayStation game on an X-Box console? No of course not; the two mediums just are not compatible.  Developers find themselves in a similar situation of trying to determine how to apply processes or code that may work in one instance to similar and dissimilar situations. Sometimes it works and sometimes it doesn't.

To illustrate it may be best to use the analogy of cooking a plate of Italian Spaghetti. You have a cookbook, but the cookbook is in a foreign language you do not fully comprehend. There are some nice pictures though, and you have a general idea of what the spaghetti should look like so you set off to cooking your spaghetti. As you are preparing your sauce, you discover that you only have pizza sauce and not true spaghetti sauce. To further complicate things the only noodles you have to cook with are Ramen noodles. While the finished product may look somewhat similar to spaghetti, I believe we can all agree it is not spaghetti.  Application development is very much the same way, even when using the same coding language like Java, there are still enough variations in styles and types of Java to make it impossible to apply similar standards across the board.

So what is the solution? I believe the solution cannot truly be resolved at the enterprise level, but at the team or platform level. Sure some things can be applied to ease the process, much the same way similar things can be applied to most types of spaghetti, but in the end it is the chefs, or in this case the development teams that must determine how to implement the general guidelines into specific recipes for their team.

Some form of SSDLC has to be applied to the development process to ensure that security is built into the code (not bolted on later), which helps avoid costly vulnerabilities and remediation later on. This may require a discovery project, training, and new tools. The one thing that it will most assuredly require is adaptability. The environments in which applications are forced to survive have become more treacherous, which has forced developers into unfamiliar territory where they must evolve. This evolution is not one that has to occur internally to the developer teams alone, but it can actually be assisted by other teams that specialize in security. In short, there is hope for the future.