I know we have always preached that application security is much more cost effective when it is baked in. But, the reality of today’s application horizon is that security is an afterthought, at best, for a majority of web applications. A variety of reasons ranging from inexperienced developers to legacy technologies and from apathetic customers to security issues in core technologies have made this so. In fact, in our application security testing services we often encounter applications in production environments that fail to protect against attacks from 10 years ago!

The average development team we work with seems to be interested in fixing the problems, but often lack the basic understanding of how common attacks like SQL injection and XSS work. Without a basic understanding of the threats, how on earth can they be expected to protect against them? Recently, we spent more than four hours explaining the white list vs black list approaches to a certain development team who shall remain nameless. It took almost a half day of conference calls and email exchanges for them to understand how these basic approaches to filtering user input could be employed to protect their application against input validation attacks. It was not that they were not trying. The problem seemed to be that their application was developed by a small group of intern level programmers and the team members with real programming experience (the one(s) who had done the engineering and application design) were long since gone from the company or reassigned to other projects. Without experienced oversight and guidance, the interns had produced working code for sure, but without any underlying controls, security, availability or reliability!

Today, if we look at the marketplace, there are a ton of solutions attempting to bolt on security after the fact. Everything from code scanners to web application firewalls are emerging as controls to help organizations deal with web application security. One of the big problems with these technologies is that they require changes to the underlying source code, logic or web server environments. At the very least, WAFs act as a filtering device at the protocol layer, and many applications simply perform unreliably when a WAF is “protecting them”. What we really need is a reliable way to add security to web applications without changes to protocols, environments or logic.

Of course, the ultimate argument is that what we really need is secure code. I have read a lot of security pundits lately talking about how “secure code” is the solution. “Secure code” has become the latest battle cry, silver bullet, smoke and mirror trick and marketing hype. However, “secure coding” is not easy. It is not immediately available for most organizations – there is no switch to flip on your developers to make them churn out “secure code” – there is no ONE class or seminar you can send them to make them write “secure code”. Instead, it takes ongoing education, updates to existing code tools, frameworks and development environments. It will be a long, slow process. It will be a human process and it will be expensive.

Even then, once we get all of our programmers making “secure code”, there will still be problems. New attack formats will arrive. Legacy applications will still have old issues – some may be rewritten, but it won’t be cost effective for all web applications. New technologies and web enhancements will certainly degrade the security posture of even today’s most hardened web application. In other words – as you have heard me say before – Security is a journey, not a destination. We won’t get all of our code secure. We will never cross the line when all web apps are safe. We will simply move closer to a time when a majority of web applications are secure enough to meet our level of risk tolerance. Even then, that moment is likely fleeting. The center will not hold. The universe breaks down upon itself. Entropy is a true constant in the universe, even the security universe. The center will just not hold……