Gary McGraw of Cigital, one of the thought leaders in software security, describes how to integrate software security into SDLC. In the book Software Security: Building Security In he introduces a set of touchpoints: key areas in the SDLC where security must be considered in designing and building software. The touchpoints, listed in order of effectiveness, are:
- code reviews, including both manual code reviews and automatic checking with static analysis tools, looking for errors in API use, inadequate validation and error handling, proper logging and specific security-related bug-patterns
- risk analysis in architecture and design
- penetration testing
- risk-based security testing
- abuse case scenario planning
- security included in requirements
- secure operations
- and external, expert reviews including third party security walkthroughs of architecture, design and code.
In a Computerworld interview Gary McGraw
Gary McGrawgoes on to say that
“Software security relates entirely and completely to quality. You must think about security, reliability, availability, dependability — at the beginning, in the design, architecture, test and coding phases, all through the software life cycle.”
Code reviews, static analysis, risk analysis in architecture and design, risk-based testing, … all of these are necessary in building high-quality software. What is required in addition is building the team’s knowledge of software security: most programmers don’t learn much if anything about software security in school, and need to be taught about the problems and best practices and tools needed to build secure software systems, just as they need to be taught about developer testing, or high availability systems design, handling concurrency issues in massively parallel systems, and the other complex problems that need to be solved in real systems. Secure software requires:
1. Security awareness training and technical training from companies like the SANS Institute, Foundstone and Cigital. First to understand that IT security is not just about hardening infrastructure and secure operations, that a secure system requires building software in a secure way in the first place. Then training in threat modeling and defensive programming to understand the technical problems, the risks, exploits, attack patterns and common vulnerabilities such as the OWASP Top 10, and best practices, tools and other resources available to build secure software.
2. Developing and sustaining “an attack-based” approach to designing and building systems - making sure not only to check that software meets the specifications, but also checking to ensure that “bad things don’t happen”. Architectural risk analysis, abuse cases, exploratory testing, stress testing, war games, fuzzing, gorilla testing and other types of destructive testing all need to be done: not just to ensure security but also the reliability and overall quality of the system. In other words, a negative, attack-based posture should already be followed in testing and reviews, not just for security.
From Gary McGraw again in a recent podcastHow to Start a Secure Software Development Program":
"I guess the biggest difference is thinking about an attacker and pondering the attacker’s perspective while you’re building something”
To build this perspective takes management focus, time, training, mentoring on what to look for in design and code reviews; and continual reinforcement.