As a security professional, I'm often asked whether testing is the best way to find security vulnerabilities in the development lifecycle. My two decades of experience in software have demonstrated
My two decades of experience in software have demonstrated to me that it's impossible to test security into an application.
The keys to preventing, detecting and resolving security vulnerabilities during the development lifecycle include:
- Good security architecture: Experienced security engineers have a number of "secrets" for building secure code. Centralize as much as possible. Centralize input validation, use a common encoding library, develop or implement a centralized authentication and authorization mechanism, etc. Centralizing this functionality imposes a burden of consistency on developers -- consistency breeds repeatability. It also forces the team to think up-front about concepts such as authorization schemes, encryption libraries, etc.
- Educated product, development and test/QA teams: I often joke that allowing an untrained developer to write production code is like owning an untrained Rottweiler. It's a disaster waiting to happen. Educating your full product team (from product owner to developer and tester) means security becomes part of every step of the process. Teach product team members when encryption is needed or how to design a good user password reset tool. Teach developers how simple it is to encode output in the ESAPI tools. Teach QA engineers how to proxy a Web application and perform basic penetration tests. As the team develops familiarity with security concepts, that familiarity will result in recognition when a poor security architecture or implementation decision is made.
- Early detection through feature security reviews, static code analysis, threat modeling and "inline" penetration testing: By engaging, testing and thinking about security through the lifecycle, bad implementation is detected early. In Agile organizations, teams benefit from discussing backlog items and identifying which items may have an impact on security via UX, design or implementation. These items can be flagged for security "mini-reviews" where potential issues can be discussed and plans made to address them. Static code analysis is a quick, effective way to scan an entire codebase and detect implementation issues. Threat models allow the team to consider the application as a complete system and identify where threats exist unmitigated. Inline penetration tests are small, short-cycle pen tests aimed at validating security decisions made during feature security reviews. Pen tests also ensure the feature implementation was performed properly.
- Making security activities a required process within the development lifecycle: In many organizations there is an emphasis on releasing features at almost any cost. Quality and security are sometimes sacrificed to the god of release dates and feature checkboxes. In organizations like this, it's helpful to have senior leadership (C-level) agree to minimally defined secure development lifecycle processes and gates. This helps enforce best practices, even under the stress of release dates and client commitments.
It's true that it's impossible to pen test security into an application, but a team that approaches security as another core value can build reliable, secure applications with little significant additional overhead. It takes education, planning, a good set of tools and initial commitment. While few teams inherently possess these skills, there are numerous opportunities for external training (organizations like SANS and OWASP are a great resource for rigorous training). Teams also benefit from bringing in experienced consultants. If the engagement is designed from the start to build independence, teams can learn and develop skills that will eventually drive their own internal process changes.
The important thing to keep in mind is that security is similar to any other good engineering process: It requires education, skill and careful attention. As teams develop the skills and knowledge needed and continue to pay careful attention, they can achieve their goals of delivering secure software applications.
This was first published in January 2014