Part 4 of 5 - How do you know how you're doing if you aren't measuring?
To view the previous post in this five-part series, click here.
Assessment
In order to think strategically about your investments in application security, it’s important to define and measure your risks. In order to reduce your risk, and increase your level of application security process maturity, it’s important to stop thinking in terms of vulnerabilities and start thinking in terms of risk. Here’s the high-level difference:
- A vulnerability-focused approach will lead you to put your energy into vulnerability discovery activities such as penetration testing and automated code scanning.
- A risk-focused approach will allow you to invest in risk prioritization and prevention activities such as threat modeling, design and coding standards and development team education.
By prioritizing risk you can ensure that your vulnerability detection and remediation activities are focused on the threats that could result in the highest impact to your business, rather than spending time finding and fixing vulnerabilities that have very little impact. In our 2012 survey on application security maturity, we found that the use of a threat model or other high-level risk assessment is exhibited by only 43% of surveyed organizations. This lack of measurement makes it very difficult to invest effectively or to improve over time.
An important part of the overall education of developers is to ensure that they are adhering to the organization’s security policies and practices. Such assessments are critical to maintaining security in the development process and to understanding if the training program is achieving its objectives.
Our most recent joint Ponemon study revealed that the majority of organizations do not take steps to determine compliance among programmers:
- 45% measure development teams for their compliance with regulatory requirements or security best practice
- 39% say development teams are measured for compliance with secure architecture standard
- 41% say development teams are measured for compliance with secure coding standards
Most security compliance requirements and regulatory standards include a section on application security. Unfortunately, the standards are not written by developers or in language that is actionable and understandable to developers. The first step in this process is create a mapping the provides guidance to your developers regarding how each compliance requirement can be met in the context of the code they are writing.
In order to succeed, security policies and compliance requirements must be considered in every step of the SDLC. For instance:
- Requirements should include policy analysis
- Design should include standards to adhere to the policies
- Implementation should include coding standards to adhere to the policies
- Assessments should be conducted to check design and implementation against the standards and policies
Despite the many public breaches and attacks that have been reported, most organizations are still not testing their applications for security. Only 43% of respondents say they have a process in place to test for vulnerabilities prior to release, and only 41% are using automated scanning tools to test applications during development. Additionally, only 42% subject applications to a manual penetration testing efforts by internal teams or by a third party. Leveraging third party security audits for high-risk applications is an indicator of a high-level of maturity.
On a similar note, I’d like to demystify a myth regarding application security testing. Many of the teams I talk to don’t believe their existing QA staff can help with security testing, however that’s not really the case. While it takes significant security expertise to conduct a deep penetration testing, any QA team can think about security during their testing activities and can cover some security abuse cases during their normal test pass. If every member of the development team (architects, developers and testers) think about security from start to finish, it will result in a more secure application.
It may also come as a surprise that there are a number of free security testing tools and security frameworks. While you won’t get the same level of support as you will get with the more expensive professional options, free tools will allow your team to get started quickly with less capital investment. Rather than getting blocked by cost or knowledge fears, it’s important to dive in and get started.
