Some excellently reported statistics here relating to web application vulnerability testing performed by Imperva: https://www.imperva.com/application_defense_center/papers/how_safe_is_it.html.
One of the most interesting (and worrying) quotes in the report is:
In contrast, the portion of tests yielding critical vulnerabilities constantly grows over the years to an overwhelming 89% in Year 4
. Another quote I’ll draw your attention to is:
In one third of all retests we found previously encountered vulnerabilities, of which half were claimed to be fixed by programmers. This indicates that programmers either did not understand the problem, did not know how to fix it, or in many occasions just tried to hide it (e.g. disable detailed error messages on Web server hoping to avoid SQL injection attacks).
.It’s easy to lay the blame at the desks of the developers for many of the reported problems. Many of the vulnerabilities are simple to fix bugs relating to error handling or checking input. Not only that but information about SQL Injection, XSS, error handling etc is hardly new ground from a development perspective. We’ve been banging on about this stuff for years now and if a developer tells me that he isn’t aware of the risks and how to resolve them then quite honestly I think he\she should consider a career change.
Here’s my opinion – the developers have a lot to answer for: and if they don’t understand the issues then the business needs to look at the way it acquires and trains it’s software developers. But the QA process is also at fault, who tested this before it went out of the door and what did they look at and how? And then let’s look at the schedule and the budget and the requirements and the whole SDLC process and actually check that somewhere along the way some-one thought to mention that security is a bit of an issue and perhaps they should look into it.
Personally I’m now reaching – no, actually I’m passed – the point of impatience when I see applications that still contain simple and obvious errors that are the result of poor quality coding. So, while the developer must take blame for shoddy work, it’s also a management issue.
However, none of this is a solution. We can rant, rave, soapbox, pontificate and none of that makes the problem go away. Here’s what I’ve done:
– made security an integral part of the product SDLC
– implemented a formal and documented risk management plan
– regular assessments of important products
– recommendations for training and awareness
– address the issues at the non-technical level so that product owners understand then too
– set corporate objectives based around improving the status.
So now we have something to measure and something to improve. Has it worked? Ask me that one this time next year!