Chapter 9. Stage 4: Risk Analysis

Chapter 9. Stage 4: Risk Analysis In this chapter: Threat-Modeling Artifacts 103 What to Model 104 Building the Threat Model 104 The Threat-Modeling Process 105 Using a Threat Model to Aid Code Review 128 Using a Threat Model to Aid Testing 129 Key Success Factors and Metrics 129 If we had our hands tied behind our backs (we don't) and could do only one thing to improve software securitythreat modeling, better security code reviews, or better security testingwe would do threat modeling every day of the week. The reason is simple: when performed correctly, threat modeling occurs early in the project lifecycle and can be used to find security design issues before code is committed. This can lead to significant cost savings because issues are resolved early in the development lifecycle. Derived from numerous studies and research sources, Table 9-1from Steve McConnell's Code Complete (McConnell 2004)shows the relative cost of fixing defects in code. Table 9-1. Relative Cost of Removing Software Defects Defect Introduction Point Defects Found During Requirements Defects Found During Architecture Defects Found During Construction Defects Found During Test Defects Found After Release Requirements 1 3 510 10 10100 Architecture None 1 10 15 25100 Construction None None 1 10 1025 The idea behind threat modeling is simply to understand the potential security threats to the system, determine risk, and establish appropriate mitigations. Threat modeling also helps businesses manage software risk, creates awareness of security dependencies and assumptions, and provides the ability to translate technical risk to business impact (and vice versa). Over the last two years, Microsoft has extensively researched how to improve threat modeling and has garnered feedback from the Microsoft Trustworthy Computing Academic Advisory Board (TCAAB 2003), Microsoft employees, and others in the software and security industries and academia. Note The meaning of the word threat is much debated. In this book, a threat is defined as an attacker's objective. To some, the threat is the attacker or adversary; we refer to this entity as the threat agent. These definitions are used in the Common Criteria. The threat-modeling processes documented in Writing Secure Code, Second Edition (Howard and LeBlanc 2003) and then explained further in Threat Modeling (Swiderski and Snyder 2004) have received some valid criticism; most notably, they require too much security expertise, and they're subjective (Torr 2005). The updated method described in this chapter addresses both these issues by providing a more streamlined and coherent process. Note that threat modeling is not a static process. At Microsoft, we are constantly learning how make the technique easier, more approachable, and frankly, more beneficial. The benefits of threat modeling are numerous. Notably, threat modeling Contributes to the risk management process because threats to software and infrastructure are risks to the user and environment deploying the software. Uncovers threats to the system before the system is committed to code. Revalidates the architecture and design by having the development team go over the design again. Forces development staff to look at the design from a different viewpointthat of security and privacy. To understand the most at-risk components, development staff focuses on components with a high attack probability. Helps clarify the selection of appropriate countermeasures for the application and environment. Contributes to the Attack Surface Reduction (ASR) process for the software. (See Chapter 7, "Stage 2: Define and Follow Design Best Practices.") Helps guide the code review process. Guides the penetration testing process. We'll discuss all of these throughout the rest of this chapter. But before we do, we want to explain something very important about threat models. At Microsoft, we have found that a good set of threat models is a sign of a "security healthy" team. Good threat models mean the team has thought through the security and privacy issues in depth. Contrast this with a group that has poor or incomplete threat models, and this might indicate the team has not spent enough time thinking through the threats to the system. It does not mean the code is poor quality; it might very well be rock-solid, but the team still might need help understanding the threats. Best Practices A good set of threat models is a sign of a "security healthy" team. It indicates that the team has thought through security and privacy issues in depth. A group that has poor or incomplete threat models might not have spent enough time thinking through the threats to the system. Although the code they produced might be great, team members might need help recognizing that code threats continue to be a serious issue.