Secure Software Design and
Development
(Part II: Seven Touchpoints
for Software Security)
CHAPTER 3. INTRODUCTION TO SOFTWARE
SECURITY TOUCHPOINTS
BOOK: SOFTWARE SECURITY: BUILDING SECURITY IN, 1ST EDITION BY GARY MCGRAW
Seven Touchpoints
Seven Touchpoints
1. Code Review (Tools)
Artifact: Code
Example of risks found: Buffer overflow on line 42
⮚ Doing code review alone is an extremely useful activity, but given that this
kind of review can only identify bugs, the best a code review can uncover is
around 50% of the security problems.
⮚ Architectural problems are very difficult (and mostly impossible) to find by
staring at code. This is especially true for modern systems made of
hundreds of thousands of lines of code.
⮚ A comprehensive approach to software security involves holistically
combining both code review and architectural analysis.
1. Code Review
1. Code Review
1. Code Review
1. Code Review
1. Code Review
1. Code Review
2. Architectural Risk Analysis
⮚ Artifact: Design and specification
⮚ Examples of risks found: Poor compartmentalization and protection of critical
data; failure of a Web Service to authenticate calling code and its user and to
make access control decisions based on proper context.
⮚ At the design and architecture level, a system must be coherent and present a
unified security front. Designers, architects, and analysts should clearly
document assumptions and identify possible attacks.
3. Penetration Testing
⮚ Artifact: System in its environment
⮚ Example of risks found: Poor handling of program state in Web interface
⮚ Penetration testing is extremely useful, especially if an architectural risk analysis
informs the tests. The advantage of penetration testing is that it gives a good
understanding of fielded software in its real environment.
⮚ Software that fails during the kind of canned black box testing practiced by
prefab application security testing tools is truly bad.
⮚ Thus, passing a low-octane penetration test reveals little about your actual
security posture, but failing a canned penetration test indicates that you're in
very deep trouble indeed
4.Risk-Based Security Testing
⮚ Artifact: Units and system
⮚ Example of risks found: Extent of data leakage possible by leveraging data
protection risk
⮚ Security testing must encompass two strategies: (1) testing of security
functionality with standard functional testing techniques and (2) risk-based
security testing based on attack patterns, risk analysis results, and abuse cases.
A good security test plan embraces both strategies.
⮚ Security testing is about making sure bad things don't happen. Thinking like an
attacker is essential. Guiding security testing with knowledge of software
architecture, common attacks, and the attacker's mindset is thus extremely
important.
5. Abuse Cases
⮚ Artifact: Requirements and use cases
⮚ Example of risks found: Susceptibility to well-known tampering attack
⮚ Building abuse cases is a great way to get into the mind of the attacker. Similar to
use cases, abuse cases describe the system's behavior under attack; building
abuse cases requires explicit coverage of what should be protected, from whom,
and for how long
6. Security Requirements
⮚ Artifact: Requirements
⮚ Example of risks found: No explicit description of data protection needs
⮚ Security must be explicitly worked into the requirements level. Good security
requirements cover both overt functional security (say, the use of applied
cryptography) and emergent characteristics (best captured by abuse cases and
attack patterns).
7. Security Operations
⮚ Artifact: Fielded system
⮚ Example of risks found: Insufficient logging to prosecute a known attacker
⮚ Software security can benefit greatly from network security. Well-integrated
security operations allow and encourage network security professionals to get
involved in applying the touchpoints, providing experience and security wisdom
that might otherwise be missing from the development team.
*. External Analysis
⮚ This is not really a touchpoint, but it's important enough to emphasize so I've put
it in the touchpoints picture anyway.
⮚ External analysis (i.e., analysis by somebody outside the design team) is often a
necessity when it comes to security.
⮚ All software security touchpoints are best applied by people not involved in the
original design and implementation of the system.
Best Practice
Best Practice
