Attacks on applications succeed because they are still not secure.
Even though we have SSDLC, SDL and SDL-Agile, organisations still churn out vulnerable applications. Even though we have scanners and static analysis tools, application security bugs still get through the gate. Even though we have penetration testing and vulnerability assessment services, we still see high-profile data breaches far too often in the press.
Today, development departments are under pressure not just to do more, but to do more with less. Chronically the focus is very much on new features, new platforms and new releases and this has to be done with less time and less resource than ever before.
Security has to be a by-line, after all developers are creative. To developers application security is not considered ‘cool', as it stifles creativity. This gives an insight into what's going wrong, even after all of this investment in time, technology and resource.
In my meetings I hear from organisations time and time again that the problem for them is that there are too many vulnerabilities in their software and too much insecure code is getting past the bar. I hear that the same vulnerabilities are seen repeatedly in penetration tests and that the team doesn't seem to be learning from its mistakes.
Looking at the press, we see that some of the best-known and largest organisations are victims of security breaches originating from their applications. All this despite the heavy investment in application security technology, process and people.
It's a complicated problem and there is a raft of reasons for it. Due to the nature of development the application changes over time and just like any software bug, application security bugs are unwittingly introduced with new functionality. Initial security evaluations can't address this new functionality.
Third Party code is such as that, as it is introduced from a vendor but no consideration is given to the vulnerabilities in it. In the larger project this includes use of libraries or implementation/integration of a platform that you didn't write, such as a CRM, ERP or CMS.
Static analysers, scanners and some services create too much noise (false positives) eventually leading organisations to ignoring the output reports of these activities. The same technology and services can miss vital flaws (false negatives) meaning that the true risk of the application is unknown. This results in a false sense of security and unknown security debt.
Even a good security evaluation report only reports problems and therefore remains on the managers' desk, as there is not the time or resource required to investigate and fix these problems.
Application security can be a dark art. Automation is blighted by false positives and negatives. It's not clear to management what the problems are (until a breach happens), while false positives and negatives are too common in automatic security technology and services, and they report problems when we need solutions.
Beware the roosters
In the fable ‘The Chicken and the Pig' often referenced in Agile project management, a pig and a chicken are walking down the road. The chicken says: "Hey pig, I was thinking we should open a restaurant!” Pig replies: "Hmm, maybe, what would we call it?" Chicken responds: “How about 'ham-n-eggs?" The pig thinks for a moment and says: "No thanks. I'd be committed, but you'd only be involved!”
The chicken is someone who consults on the project while the pig is committed and has to forego other projects until this one is done. Success relies on both chickens and pigs, however roosters (those giving unhelpful and unproductive advice) are to be avoided. How can this be achieved?
There are three simple things that it's vital to look for when evaluating your approach to application security:
- Accuracy – Identify vulnerabilities that pose a real threat to critical data, but only those vulnerabilities. This will avoid wasting time on irrelevant issues.
- Clarity – Provide everything required to effectively securing applications; it's not enough to find the problems, results must be concise and relevant, there must be root cause analysis and there must be solutions offered.
- Simplicity – Must be understandable by everyone in the process and any output should be step by step: problem, explanation, evidence, root cause and remedy.
Adam Brown is UK manager of Quotium