Suppose Acme Inc., a multi-billion dollar company, suffers a web application breach that results in loss of critical client data. Buoyed by news of legal settlements, a group of clients decides to file a class-action lawsuit. Acme’s lawyers begin to prepare a defense and one of the first areas of investigation is assessing if Acme followed industry-standard security practices.
Many organizations might give a response that says something like this
- We use firewalls with restrictive settings
- We have strong network security practices, such as firewalls, comprehensive logging and monitoring, and regular patching
- We have comprehensive physical security and a SSAE 16 certified data center
- We scan our networks for security vulnerabilities using XYZ network scanner
- We use SSL with ###-bit encryption
- We scan our software for security vulnerabilities using ABC security scanner
Many would argue that this constitutes “industry standard”, despite the fact that only the last two points are really focused on web application security. Certainly all of these controls are important and not having them exposes an organization to risk. Yet, so many organizations that employ all of these controls still have significant exposure.
There are a number of reasons why this happens. One of the most common, however, is that an organization like Acme simply has no means to detect the application vulnerabilities which its scanner doesn’t find. It might be lulled into a false sense of security thinking that the scanner will detect the OWASP Top 10 web application risks. In fact, many security-sensitive organizations deploy mission-critical software on a regular basis relying primarily on automated scanning solutions to find security vulnerabilities.
Many of these automated scanning solutions are outstanding in their cost effectiveness and ability to find certain classes of vulnerabilities. For example, a properly-configured static analysis solution may help you find every instance of potential SQL injection in your software. Scanning tools are mandatory components to a successful enterprise application security program. At the same time, automated solutions have limitations inherent in their technology. For example, static analysis may not be able to find something as pervasive as a brute-force authentication vulnerability — the 3rd leading cause of hacking data breaches according to the Verizon data breach investigations report. A dynamic testing solution may not be able to reliably detect every instance of SQL injection. Even when combined, we estimate that at least 42% of application security issues cannot be found with these scanning solutions unless they are customized. A single tool is unlikely to find more than 45% of security issues — and many will find far less depending on their support a particular the application’s technology stack.
Yet because techniques like manual security testing, threat modeling, developer education, and architectural analysis are expensive to scale, the baseline for “industry standard” remains low. It’s quite possible that experts would view Acme as having followed industry norms, even though the controls are insufficient to prevent a number of attacks. This has wide-reaching consequences. If the information security group in Acme argues for more attention to application security, they are going to face an uphill battle in asking for time, staff, and/or budget to go beyond industry best practices. Clients who want to audit Acme’s policies may see the large number of security practices and think their data is safe, particularly if the clients themselves are not experts in information security.
The information security needs to raise the bar by making preventative activities part of the minimum industry-standard baseline. The Payment Card Industry was one of the first to recognize the gap. PCI DSS 6.5 states:
“Develop applications based on
secure coding guidelines. Prevent
common coding vulnerabilities in
software development processes, to
include the following .. [list of OWASP Top 10]“
This is the right direction. Unfortunately, in our experience companies often pass this requirement with little real evidence of a secure Software Development Life Cycle (SDLC) because many Qualified Security Auditors simply don’t know how to audit for it apart from interviewing a few key developers. Those QSAs, external auditors, and internal auditors who do demand real evidence of secure SDLC activities are helping the entire industry move forward. They are raising the bar on application security due diligence.