Chapter 7. Stage 2: Define and Follow Design Best Practices

Chapter 7. Stage 2: Define and Follow Design Best Practices In this chapter: Common Secure-Design Principles 76 Attack Surface Analysis and Attack Surface Reduction 78 The software industry abounds with security software coding best practices (few of which are followed), but there is a dearth of pragmatic secure-design guidance. Microsoft has spent considerable time working to make secure design accessible to the average non-security expert. Saltzer and Schroeder's classic paper "The Protection of Information in Computer Systems" (Saltzer and Schroeder 1975, Computer Security Resource Center 2002) offers many time-tested secure-design principles that apply today as much as they did in 1975. Secure design is necessary for all computer software, from operating systems to online computer games (Yan and Randell 2005). This chapter offers brief ideas for applying secure-design principles to modern application software. Extensive coverage of these principles is beyond the scope of this book; for more information, please refer to one or more of the many references (Anderson 2001, Bishop 2002, Howard and LeBlanc 2003) on the subject. Internet Engineering Task Force (IETF) requests for comments (RFCs) must also include security information. Rescorla and Korver's "Guidelines for Writing RFC Text on Security Considerations" (Rescorla and Korver 2003) offers some ideas on how to think about the security implications of software, firmware, and hardware features. Best Practices When you expect engineering staff to execute on security-related initiatives or to adhere to a security or privacy policy, it is imperative that you provide prescriptive guidance about how to achieve your goals. Don't just say, "This is bad." Instead, say, "This is the way you should do it." In our experience, engineering staff are happy to adhere to security and privacy policies as long as you explain how to attain the desired objectives. All products should follow appropriate secure-design best practices. These are not the same as threat modeling; threat modeling and secure design are different but complementary. Threat modeling determines appropriate mitigations based on threats to the system, and secure design best practices focus on "good security hygiene" within the application. For example, if you identify a threat to a system and then select mitigations, your mitigations could be compromised if the application's design is insecure. Secure-design principles can help prevent such potential errors. Another important best practice of the design phase is reducing a software product's attack surface, which is the sum of all code and functionality accessible to users and potential attackers. For example, a Transmission Control Protocol (TCP) socket opened by an application is part of the application's attack surface. Attack surface might appear to be an operating system characteristic only, but all applications have it, even if some applications measure it differently. A goal of any product should be to reduce the attack surface. Note Remember the two major goals for the Security Development Lifecycle (SDL): reduce the number of vulnerabilities in the software as you develop it, and reduce the severity of any undiscovered security bugs. The first principle is the high-level goal of Secure by Design, and the second is the high-level goal of Secure by Default. Securing the design and the code is paramount, but mistakes will be made, and research into new vulnerabilities that may affect the software continues long after a product has been shipped to customers. It is therefore imperative that the product have a minimal attack surface to reduce the severity of any security bugs in the code. This is what secure by default is all about; secure by design is about getting things right, and secure by default is recognizing you never will!