Why Are We Failing at Software Security?

Wednesday, May 01, 2013

Nish Bhalla


A recent report by Veracode found that 70% of applications fail to comply with enterprise security policies - a 10% jump over last year. An earlier report by HP found similarly dismal numbers when it comes to application threats. Major software breaches occur regularly at the highest levels. 

At the same time, application security threats are well-known and documented in the industry. The OWASP Top 10 has been around for many years. If developers simply completed a comprehensive set of software security requirements, it would eliminate a high percentage of the most serious application vulnerabilities.

So why are we failing at software security? 

While there are many granular reasons for software security failures at the institutional, developer or vendor level - which could boil down to any number of factors, including an incohesive team, limited budget, inexperience, etc. - there are five industry-wide problems that are fueling the current state of insecurity. These are complicated problems and will not be easy to solve. But until we do, software security will remain at risk.

Here are the top five problems that are holding back application security:

1. Lack of a Mandatory Industry Standard - Unlike the payment card industry, there is no single industry standard for application developers that mandates compliance with critical security protections. This is a significant shortcoming in our industry. We should have a rigorous standard that every application developer has to follow, regardless of what industry they’re in. Whether the company is in retail, oil/gas, financial services, etc., at the very least all external-facing apps should have to meet basic security standards. 

2. Measuring Success or Failures - Today, no one is really measuring when a security control has helped mitigate an attack. Security executives can put a ballpark figure on how much a threat will cost if it’s exploited in the wild - but they can’t say how likely it is that such an event will actually happen to their environment. Unlike the insurance industry, where the actuaries have collected data and come up with an approach to formalize and interpret risk to financial data and built interpretations to common parlance, we as an industry haven't done that or come up with models that work for each industry.This failure to create a risk-model for application security lowers the incentive for companies to spend more on security - and weakens the CISO’s case at the executive level. It’s a key obstacle that must be overcome.

3. Apathy in the C-Suite - Today’s CEOs are often unmoved when it comes to security risks - especially when it comes to applications they produce or consume. For the executive, infosec is a cost and not a profit center - and they remain skeptical of claims that the cost of security is far less than the cost of a breach. Part of the problem is that we lack an industry standard and don’t have viable risk-modeling - two things which would make these decisions more clear-cut. But there’s another reason too - it’s been ingrained in corporate culture to prioritize business operations over security considerations (not just cyber, but traditional physical security too), and to consider the latter as simply a cost of doing business. We need to do a better job of explaining how security weaknesses can undermine these business operations, damage revenue expectations, alienate consumers/clients and cause long-term harm to the brand.

4. The Security-Developer Conflict - Infosec teams don’t speak the developer’s language, and vice versa. There often exists an adversarial relationship between these two, as the security process makes the developer’s job harder. Infosec teams need to do a better job of reducing friction in the security process - by assimilating their needs into the normal development process, leveraging automation as much as possible, defining requirements up front and being more cognizant of the needs and concerns of their developer counterparts. On the other hand, developers often fall woefully short on basic security knowledge. Better training is needed, along with improved communication and integration between the two sides.

5. Over-Reliance on Limited Tools - Developers, procurement departments and security teams all rely too much on scanning tools and basic software security requirement lists like the OWASP Top 10 (which was never intended to be a catch-all for appsec) to gauge security. We need to do a better job of shifting the mindset from “detect-and-fix” to “prevent-and-verify.” Software security requirements should be much more comprehensive (a good place to start is the OWASP Application Security Verification Standard Project) and done from the beginning of an application’s design process - to eliminate any potential vulnerabilities before the app is ever released. Scanning tools shouldn’t be relied on to find the flaws; instead they should be used to confirm that the software requirements have been fully instituted.  

Nish Bhalla is the Founder/CEO of Security Compass, an information security company that specializes in app security and recently developed SD Elements, a platform for secure app development. His company consults for Fortune 500s, retailers and banks, and contributed to HP’s 2012 Cyber Risk Report on mobile app threats. 

Possibly Related Articles:
Vulnerabilities Webappsec->General
OWASP Software SDLC Development security
Post Rating I Like this!
Mic Micac I have been researching this subject for a few days now for a report I am writing. Your post has been very helpful in this regard. Thanks for another great post.
waqas nayyer Main point of top 5 problems which you have mentioned in your post are quite true..You post really impressed me
waqas nayyer Main point of top 5 problems which you have mentioned in your post are quite true..You post really impressed me
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.