SD3: Secure by Design, by Default, and in Deployment

SD³: Secure by Design, by Default, and in Deployment

Our team, the Secure Windows Initiative team, has adopted a simple set of strategies called SD³ for secure by design, by default, and in deployment to help us achieve our short-term and long-term security goals. We've found that these concepts help shape the development process to deliver secure systems.

Secure by Design

If a system is secure by design, it means you have taken appropriate steps to make sure the overall design of the product is sound from the outset. The steps we recommend development groups take to achieve this include the following:

• Assign a go-to person for your security issues. This is the person who signs off on the product being secure. She gets the big bucks for doing so. She is not a scapegoat, but someone who can sit in a meeting and say whether the product is secure enough to ship and, if it's not, what needs to be done to rectify the situation.

• Require training for all personnel. See Chapter 2, The Proactive Security Development Process, for detailed coverage on this subject.

• Make sure threat models are in place by the time the design phase is complete. I'll discuss threat models in Chapter 4, Threat Modeling, but you should know that they are useful for determining the application's attack profile and which issues should be remedied.

• Adhere to design and coding guidelines. There are examples of secure design, coding, and testing guidelines in Appendix C, A Designer's Security Checklist, Appendix D, A Developer's Security Checklist, and Appendix E, A Tester's Security Checklist. Note that these are minimum guidelines; you should always strive to exceed them.

• Fix all bugs that deviate from the guidelines as soon as possible. Remember that attackers do not care if the code is old or new. If the code has a flaw, it is flawed, regardless of the code's age.

• Make sure the guidelines evolve. Security threats are not static; you should update the guidelines documents as you learn new vulnerabilities and learn new best practices for mitigating them.

• Develop regression tests for all previously fixed vulnerabilities. This is an example of learning from past mistakes, covered later in this chapter. When a security flaw is discovered, distill the attack code to its simplest form and go look for the other related bugs in other parts of your code.

• Simplify the code, and simplify your security model. This is hard to do, especially if you have a large client base that uses many of your features. However, you should have plans in place to simplify old code by shedding unused and insecure features over time. Code tends to be more chaotic and harder to maintain over time, so the time spent removing old code and making things simpler rather than adding features and fixing bugs is time well spent from a security perspective. Code degeneration is often called code rot.

• Perform penetration analysis before you ship. Have people try to break the application. Install test servers, and invite the team and external entities to break it. From my experience, unless the penetration team does nothing other than penetrations and are experts in their field, penetration testing will yield marginal results at best. In fact, it may have a negative effect if not done properly by giving the development team a false sense of security. The same holds true for hack-fests where you invite external people to attack your systems. Typically, they are a waste of time unless you are testing for denial of service issues (because most people attempting to compromise the systems are not too bright and resort to flooding attacks).

Secure by Default

The goal of secure by default is to ship a product that is secure enough out of the box. Some ways to achieve this include these:

• Do not install all features and capabilities by default. Apply only those features used by most of your users, and provide an easy mechanism to enable other features.

• Allow least privilege in your application; don't require your code be used by members of the local or domain administrators group when it does not require such elevated capabilities. This is explained in detail later in this chapter, and there's an entire chapter dedicated to the technical aspects of the subject (Chapter 7, Running with Least Privilege ).

• Apply appropriate protection for resources. Sensitive data and critical resources should be protected from attack. I'll cover this in detail in Chapter 6, Determining Appropriate Access Control.

Secure in Deployment

Secure in deployment means the system is maintainable once your users install the product. You might create a very well-designed and written application, but if it's hard to deploy and administer, it might be hard to keep the application secure as new threats arise. To achieve the secure in deployment goal, you should follow a few simple guidelines:

• Make sure the application offers a way to administer its security functionality. Obviously, without knowing the security settings and configuration of the application, the administrator cannot know whether the application is secure. This includes the ability to know what level of patching the system is at.

• Create good quality security patches as soon as feasible. If a security vulnerability is found in your code, you must turn around the fix as soon as possible but not too fast! If you create a fix rapidly, you might make a mistake and introduce more errors, so take care to get the fix right.

• Provide information to the user so that she can understand how to use the system in a secure manner. This could be through online help, documentation, or cues on-screen. This topic is discussed in detail in Chapter 24, Writing Security Documentation and Error Messages.