Abstract
Software defects lead to security vulnerabilities, which cost businesses millions of dollars each year and threaten the security of both individuals and the nation. Changes to the software engineering process can help to reduce the number of defects, improving the quality of the process. This chapter introduces the concept of threat modeling to include security in the process of developing software. Adding threat modeling to the software development process will improve the quality of the process. The majority of software coding errors are preventable using a process designed to avoid a series of common errors. Increasing the visibility of common errors will enable software engineers to produce code with substantially fewer security errors. Threat modeling provides insight into the risks facing the software at design time, increasing the software engineering team’s opportunity to avoid errors during coding.
TopBackground
Whether we listen to the news, read the newspaper or online news feeds, or monitor reports from the US CERT, we learn of cyber vulnerabilities and exploitations. These exploits and vulnerabilities are occurring at an alarming rate, costing businesses millions of dollars each year and threatening the security of the nation and of individuals (CSI 2006). Most cyber vulnerabilities can be traced to defects in software that are caused by bad design and poor development practices (Howard & LeBlanc, 2002; Howard, LeBlanc, & Viega, 2005). Defective software is largely the result of poor software engineering techniques that often “add on” security considerations rather than include them from the beginning. Yet the efficacy of bolt-on, after the fact security measures has been called into question (Conklin & Dietrich, 2005).
The Software Engineering Institute (SEI) at Carnegie Mellon University has analyzed programs written by thousands of programmers and concluded that even experienced professionals unintentionally make errors in design and programming. These errors result occur in the determination of requirements, designing, developing, and testing the software (Davis & Mullaney, 2003). Errors occur in new code and in code corrections, with one defect for every seven to 10 lines of new or changed code being a normal rate. In another benchmark study, analyzing hundreds of software projects, Jones found that released software contains from one to seven defects per thousand lines of new or changed code (Jones, 2000). Regardless of the actual error rate, these errors manifest themselves in the form of vulnerabilities and the need for costly patches.
Key Terms in this Chapter
Threat Model: A tool used in software engineering to develop an understanding of the threats to software in the design portion of the development cycle.
Risk: Is the probability that something undesired happens combined with the expected loss associated with the event.
Security Review: A team event led by a security expert that is a formal examination of material with respect to meeting security criteria of conforming exactly to requirements and only to the requirements.
STRIDE: A taxonomy of types of attacks that can be manifested against software.
Attack Surface: The collection of all the input interfaces between a software module and all sources of inputs.
Mitigation: Steps taken to address a vulnerability in an attempt to prevent an undesired outcome from occurring.
Threat: Any circumstance or event with the potential to cause harm to a software program or the tasks it is designed to perform.
Vulnerability: A weakness in software that can be exploited by a threat to cause harm to the process the software is designed to perform.
DREAD: A method of analytically assigning values to risk for the sake of comparison in software engineering projects.