Security Best Practices

Editor's Notes

• #3: So you’ve decided to get serious about security…Photo credits: http://www.flickr.com/photos/declanjewell/2472470758/
• #4: Maybe you need someheavy securityPhoto credits: http://www.flickr.com/photos/anonymouscollective/2291896028/
• #5: This elegant system allows more than one person to open the gate, each using their own key.Photo credit:http://www.flickr.com/photos/psd/
• #6: Overdone security can kill a system.If there is too much impedance, smart users will do their best to get around all the locks Too much security leads to systems that are hard to administer and maintainPhoto credit: http://www.flickr.com/photos/sunshinecity/
• #7: In this presentation we will complete a high-level overview of the SDL and the important role it fulfills in the design stage of an application’s software development lifecycle. We will also review the secure design principles employed within the SDL that has helped Microsoft better deliver safer and more trusted applications to its customers since the inception of the SDL in 2004.
• #12: After the requirements for a solution has been identified in the early stages of an application’s software development lifecycle, the next step is to design and architect a solution that satisfies those identified requirements. Developing trusted applications requires that sound security and privacy decisions be made early in the design phase because decisions made at this stage will highly influence subsequent efforts in the latter stages of the software development lifecycle and the final state of the application. Microsoft has found that by adopting this approach, application development costs (such as those required to address and resolve security and privacy issues) are significantly reduced compared to if security and privacy were considered later in the SDLC or not at all. This is because applications developed against more secure and privacy aware designs tend to be exposed to fewer threats and contain less vulnerabilities. Microsoft helps ensure that security and privacy considerations are incorporated into its application design efforts through the SDL by applying the following secure design principles.In the remainder of this presentation, I will briefly review each of these principles and mention how they can be applied to better ensure that application designs consist of sufficient and effective security and privacy best practices.
• #13: The attack surface of an application is the portion of the program (code and functionality) that is exposed to a particular person or another program. For example, an open network port and a user-interface are examples of an application’s attack surface. One of the most effective secure design principles that can be used to protect an application from malicious acts is attack surface reduction (ASR). The principle of ASR is to minimize the attack surface while still satisfying the functional requirements of the application. Secure coding will reduce, but not eliminate all vulnerabilities in your application; however, by reducing the attack surface, you minimize the number of vulnerabilities that the attacker can discover and attempt to exploit.
• #14: Here’s an example of attack surface. Let’s pretend we are a home security company and we want to protect this home from a burglar breaking in the home and stealing the valuables inside. What is our attack surface?(Mouse click)At the front of the house we have several windows and doors that a burglar could use or exploit.(Mouse click)At the side of the house we also have a couple windows a burglar could use or exploit.(Mouse click)And then finally, don not forget the chimney!Like this house, our applications have various points that are exposed to people or other programs and computers. Each one of these can be exploited by a malicious, and with attack surface reduction our goal is to minimize the number of potential vulnerabilities a malicious person could exploit.
• #15: In order to reduce the attack surface of an application, application designers need to first know how to measure the attack surface.The attack surface is defined by the set of interfaces, or entry points, to the program. Attack surface analysis (ASA) is the process of identifying and understanding all of the entry points that comprise the attack surface, and is successfully performed by enumerating all of the interfaces, protocols, and code execution paths. Another important element of ASA is understanding the trust levels required to access each entry point.For each entry point, you must consider the importance of the feature that it enables. For features that are not important to a vast majority of the users, turn the feature off, disable it by default, or do not even install it by default; force the users that really want or need the feature to take explicit action to obtain that feature. This way, any vulnerability related to that specific feature will affect a very small percentage of the product’s user base.Next consider which specific classes of users require that feature, and then restrict its use to those classes. For example, do not default to making the feature remotely accessible, do not default to allowing anonymous access, do not default to running with more privilege than is needed, etc.A significant aspect of ASR is restricting who has access to a particular product feature, and how such users may obtain and use that access.
• #16: ASA is an iterative process: for each feature that you analyze, you must also analyze all of its sub-features. And again, you want to restrict access to features as much as possible.For example, if your application in general processes files, configure it to read only the most common file types that it accepts; force the user to explicitly configure it to process the less commonly used file types. Also ensure that when the program writes files that it sets the proper ownership and rights on the file; do not create executable files unless those files must be executable.Disable older, faulty, and less used protocols, such as SSL V2 and PCT. Force users to use more robust alternatives, such as SSL V3 and TLS, or force them to explicitly configure applications to accept those older protocols.If your application provides a service or implements a protocol, restrict the commands that it accepts by default to those that are most commonly needed and used. Force the administrator to explicitly configure other commands if they want to accept them.
• #17: While ASR focuses on restricting access, it is not strictly about disabling or not installing features. For instance, instead of using UDP as a network protocol, use TCP which can be more easily secured. Or instead of making a network service Internet accessible, make it local network accessible only until unless needed.You can also use ASR to enforce the principle of least privilege, which will be discussed later, by designing the program to run with the lowest set of privileges required to perform its function.
• #18: Here are some examples of how ASR has been applied in the latest versions of Microsoft products that have previously encountered security complications:Authentication before interaction achieves ASR by disallowing anonymous access by default;Firewall on by default closes all but specifically required ports;Many services are now off by default, and when turned on are running as low privileged network services;When services are necessary out-of-the-box, they are restricted to localhost access; andFunctions or features that have been proven to introduce unnecessary and undesirable risk in the past are also now turned off by default.Note: “Network service” refers to the lesser privileged account running the service. Therefore an attacker that defeats the security of IIS 6 obtains relatively few and weak privileges, whereas that attacker defeating the security of IIS 4 or 5 was rewarded with Admin privileges.
• #19: In addition to the SDL design principle of attack surface reduction, another core principle that needs to be considered when developing trusted software is that of privacy. Privacy, like security, is another key factor when developing trusted applications; however, they are not the same.Privacy focuses on the control and choices users have regarding the use, collection and distribution of their personal information. Security, on the other hand, is applied to protect assets, including personal information, from threats.Again, when designing trusted applications, both privacy and security together need to be evaluated. The SDL helps application designers create more privacy-aware applications by establishing during the design phase privacy best practices, standards, and guidelines.
• #20: A common myth regarding the relationship between security and privacy is that if a system is sufficiently secure then privacy is also preserved. However, this may not always be the case. A security breach can certainly result in a loss of privacy (for instance, credit card information may be accessed by unauthorized users), but it is also possible for a secure system to cause a loss of privacy without a breach.Consider this secure, but privacy-violating scenario: Securely storing personal information and then sending that information using a securely encrypted communication channel to third parties without properly notifying and receiving consent from the user may be securely implemented but obviously does not take into consideration the rights of the user- some rights may have legal implications! In this scenario, the user’s privacy is compromised due to the inappropriate act of a user / application vs. due to a security breach.
• #21: In the previous slide I presented the primary privacy objectives associated with developing trusted applications. I mentioned how certain behaviors of an application could create legal obligations that need to be met and how those behaviors could also block the deployment of an application. The table on this slide shows some of the common application behaviors and the legal obligations and blocked deployment scenarios that could arise because of those behaviors. For example, if an application is designed for users under 13 years of age, then legal obligations, such as those described in the Children Online Privacy Protection Act (COPPA), must be met. As another example, if an application transfers personal information, then satisfying legal obligations from the Gramm-Leach-Bliley Act (GLBA) and the Health Insurance Portability and Accountability Act could be required.Application designers need to understand the behavior of the applications and corresponding privacy concerns implied by those behaviors. Microsoft has developed the Microsoft Privacy Guidelines for Developing Products and Services to help application development teams better understand privacy implications associated with application behavior.
• #22: In order to help application development teams better develop privacy-compliant products and services, Microsoft has released the Microsoft Privacy Guidelines for Developing Products and Services. This document provides common definitions and rules for developing better privacy-compliant products and services. The document is divided into two sections: The first section contains definitions and key concepts including data types, notice, consent, etc. The second section contains rules categorized by specific development scenarios, such as collection and transfer of personally identifiable information (pii), storage of data on the customer’s system, and onward transfer of pii to third parties. There are also specific scenarios for products or services that collect age or are attractive to children, and for products that are deployed in enterprises. Products deployed in enterprises are a special case, because the developers’ obligation transitions from the user to the enterprise administrator—you need to enable to enterprise administrator to fulfill their company’s privacy policies.At Microsoft, our goal is that our customers will be empowered to control the collection, use and distribution of their personal information through our products and services, and so any externally released application or Web site must comply with the clearly defined rules and guidelines set forth in the Microsoft Privacy Guidelines for Developing Products and Services. Within the SDL, a privacy bug bar is defined and is used to measure the impact of non-compliance with the rules of the Microsoft Privacy Guidelines for Developing Products and Services. Downloading the Microsoft Privacy GuidelinesThe current version (version 2.1a released 04/26/2007) of the Microsoft Privacy Guidelines for Developing Product and Services can be downloaded from:http://www.microsoft.com/downloads/details.aspx?FamilyId=C48CF80F-6E87-48F5-83EC-A18D1AD2FC1F&displaylang=en.A link to the most current version of this document can be found under the privacy section of the SDL training and resources link, located at: http://msdn.microsoft.com/en-us/security/cc448120.aspx.
• #23: In this section of the presentation, I will briefly explain the process called threat modeling, which Microsoft uses through the SDL process to understand and address any and all threats to an application. It is important not to confuse threats with vulnerabilities. A threat is simply what an adversary might try to do to compromise a protected resource in the system. A vulnerability is a specific way that a threat is exploitable based on an unmitigated attack path.A person in an application design group with security expertise typically leads the threat modeling activities, which begin with identification of all potential threats to the system and the assets accessed by the system. Threat models must be revisited periodically to account for new threats resulting from new and evolving attack techniques.Please recall that this portion of the presentation is meant only to provide you with a brief introduction to the threat modeling process.
• #24: At a high level, threat modeling consists of a number of activities conducted during the design phase of the application development process. These activities begin by envisioning the application as it will be used by typical users in a typical environment, and continue by identifying all of the potential threats to the application and to assets accessed via the application. During this process all security-related assumptions and external dependencies are documented, as are the “external security notes” – notes to help users and administrators understand the security boundaries of the application currently being developed.The threat modeling process continues by creating a number of data flow diagrams (DFDs), which model the trust boundaries of the application and its components and the flow of data between the application and its environment, as well as the flow of data between components within the application. Now that you have a completed model, the next step in the threat modeling process is to determine the types of threats facing the application (from the malicious user’s perspective) and list all of the DFD elements. The DFD elements represent the application assets that need to be protected from attack.Knowing what needs to be protected, and how they will be attacked, enables you to choose appropriate mitigations for each threat. Note that we are still in the design stage of application development! We are now designing security controls into the product based upon the most likely threats; the most cost-effective juncture to address such considerations.At this point, we need to review the threat model, the DFD elements (a.k.a. ‘assets’) that need protection, and the mitigations or defenses/countermeasures, to ensure that the mitigations do indeed protect the assets from the threats. If anything is found to be amiss, this is the time to start from the beginning of the threat-modeling process once again.
• #25: Microsoft has published the threat modeling tool it uses internally to help automate aspects of the threat modeling process. The tool is available for download at http://www.microsoft.com/downloads/details.aspx?FamilyID=62830f95-0e61-4f87-88a6-e7c663444ac1&displaylang=en.
• #26: In addition to attack surface reduction, privacy and threat modeling, another key design principle that should be leveraged to create trusted applications is the principle of defense in depth. A key perspective of defense in depth is beginning the application design process with the mindset that all applications and hardware will ultimately fail. If you go back to the burglar breaking into a house scenario, all the doors and windows to the house could be locked to keep the burglar out. Those might fail, so an alarm system could also be installed. The alarm system might fail, so the valuables inside the house could be placed inside a safe and so on. In the context of designing and developing trusted applications, this means that privacy  (e.g., cryptographic algorithms used to protect sensitive or personal data) and security (e.g., firewalls) features or mechanisms defending our applications will inevitably fail. Unfortunately most applications today are designed and implemented in such a way that the application can be compromised when a single, and often only, layer of defense fails or is breached.With the defense in depth principle, applications are built in such a way that if one defense layer fails, there are additional layers of defense that can provide protection to the application. Think about it this way, if a malicious user is going to compromise our application then we should make their job as difficult as possible by implementing multiple layers of defense that they need to breach vs. just one. That is defense in depth! 
• #27: The easiest way application designers can get started with this powerful principle is to evaluate their application designs and ask themselves if one layer of defense is breached, what other layers can provide additional protection to the application and the assets that it is protecting.Here is an example of defense in depth and how this principle can be leveraged to make trusted applications more difficult to compromise. Consider a malicious user who wants to gain unauthorized access to sensitive data stored in a server, such as credit numbers or other personally identifiable information (PII).(Mouse click)Again most applications today are designed and developed with a single layer of defense in mind – typically a firewall.(Mouse click)If a malicious user is able to breach this single layer of defense, then that user is able to compromise the application. (Mouse click) On the other hand, an application designed with the defense in depth principle has multiple layers of defense protecting it. For instance, defense layers like input validation (application-level), smart card (host-level) access, and IP security (network-level) are examples of additional layers of defense that could protect an application.(Mouse click)So now, even if one layer of defense fails, there are additional layers of defense that can provide protection to the application and the attack is halted. In our example, while both the firewall and the second defense layer failed, the 3rd and 4th layers of defense were still able to halt the attack, thereby protecting the sensitive data.
• #29: The previous SDL secure design principle of defense in depth started with the notion that all software and hardware would fail at some point. With the least privilege principle, we assume that all applications will be compromised. However, thru employing the principle of least privilege, should a malicious user compromise an application the amount of damage that may be inflicted is limited.
• #30: Pretend that we have a malicious user and an application running on a system that the user is hoping to compromise.(Mouse click)In this example, the application is running in an administrative or local system state. That is, the application has the same rights as any administrative user on the system.(Mouse click)When our malicious user here compromises the application, because that application is running in an administrative state, the malicious user can now use the application to perform malicious actions, such as changing system passwords, reading users’ files, and accessing any data on that system. In fact, because the malicious user is essentially an administrator on that system through the compromised application, the user can do whatever is desired.(Mouse click)Now see what happens when a malicious user compromises the same application, but this time the application is running using the least privilege principle. That is, it is running in a lower privileged state, such as a network service.(Mouse click)Now when the malicious user compromises the application, the malicious user cannot perform malicious actions, such as changing system passwords, reading user files, etc., because the application that the malicious user is using to perform those nefarious actions does not have the privileges (i.e., access) to do so. In applying the least privilege principle, we have greatly limited the potential damage a malicious user can apply to a compromised system. It is still not an ideal situation; we would rather the malicious user not be able to compromise the application at all, but if the malicious user does compromise the application, then at least we can limit the amount of damage that may be inflicted.
• #31: Here are a few tips when using least privilege to design applications that are to be more resilient to malicious attack.Think minimally. Ask yourself, what is the minimum access your application needs to function correctly?If your application requires higher privileges, elevate those privileges only when required and release those privileges immediately after the purposes of those privileges have been satisfied.
• #32: In the previous section I provided an overview of the principle of least privilege. In this section, I will present another important and last principle known as, “secure defaults.” Recall that with the attack surface reduction principle, any non-critical part of an application that was exposed to a human or system was removed or disabled by default to reduce the number of exposed vulnerabilities a malicious user could use to compromise an application. The secure defaults principle considers the situation where part of an application needs to be exposed to a human or system by default and how this may be conducted more safely and securely. Microsoft, through the SDL process, has used this principle to better ensure that customers have safer experiences with our applications out-of-the-box, rather than after extensive and often manual configuration activities must be performed. With this principle, it is left to the user to reduce the security and privacy of an application, and not left to Microsoft / the manufacturer of the software.Malicious users commonly scan networks for applications or devices that are known to be insecure by default, such as wireless routers and web servers. These applications are easy to compromise. With secure defaults, this ability is taken away from malicious users and helps keeps your customers safer.
• #33: Regarding the secure defaults principle, designers need to evaluate the various parts of their application from the perspective of what is the most secure or privacy-aware manner in which this part may be configured. Here are some examples:Firewall. Microsoft Windows can be configured with the firewall on or off. By default, the latest and future versions of Windows come with the firewall turned on by default.SSL Socket. If your application can read data through an SSL socket, then by default it should be configured to use only the latest secure protocol versions, such as v3, TLS, etc., and avoid insecure versions, such as v2.User Access Over Anonymous or Authenticated Channels. If your application has the option of allowing users to access it over anonymous or authenticated channels, then by default it should use authenticated.Password Complexity. If your application can require users to have complex passwords, then that feature should be enabled by default.Storing User Passwords as Hashes. If your application can store user passwords as hashes or clear text, then it should store passwords as hashes by default.
• #36: This concludes our discussion on the SDL Secure Design Principles. In this presentation we completed a high-level overview of the SDL and the important role it fulfills in the design stage of an application’s software development lifecycle. We noted that when security and privacy considerations are sufficiently and effectively incorporated early into an application’s software development lifecycle, such as in the design phase, the overall number of threats an application is exposed to and the number of vulnerabilities an application may contains will be substantially reduced. Additionally, the overall cost of maintaining trusted applications will be reduced due to the number of remediation efforts required to address post-deployment security and privacy issues will most likely be reduced.Finally, we explored the core secure design principles leveraged by the SDL, which are:Attack Surface Reduction. This principle emphasizes the importance of reducing the overall number of possible points in an application that malicious users can use to attack that application.Basic Privacy. This principle concentrates on the importance of fulfilling certain legal obligations, increasing customer trust and unblocking deployments based on an application’s behavior.Threat Modeling. This technique gives application designers a structured and methodical way of understanding and analyzing threats to an application.Defense in Depth. This principle focuses on how the use of multiple layers of defense for an application greatly reduces the likelihood that a malicious user will be able to exploit it.Least Privilege. This principle emphasizes the importance of limiting the amount of damage a malicious user can inflict in the event an application is compromised.Secure Defaults. Finally, this principle concentrates on better ensuring customers’ safe experiences with an application out-of-the-box rather than being required to perform an extensive series of custom configurations.
• #39: This diagram compares the security engineering steps of the SDL to the software engineering steps of the classic SDLC (software development lifecycle). The blue outer ring represents traditional software development and the orange inner circle represents the SDL. Notice that the security engineering steps are incorporated into the existing software engineering steps and that any engineering task can be supplemented with a security engineering task.Both of these development lifecycles, or collections of engineering steps, apply to the software development lifecycle regardless of the particular development model you use (for example waterfall, Agile, etc.) The small pewter colored circles represent the various milestones in your model and are an excellent time for ensuring that the steps in both the security and software development lifecycles have been adequately addressed.The SDL process has been documented and published in The Security Development Lifecycle book (Microsoft Press 2006, ISBN: 9780735622142), and the official Web site can be accessed at http://www.microsoft.com/sdl.
• #40: This slide provides additional information and links if you would like to learn more about Microsoft’s threat modeling process.
• #41: Microsoft also has a security developer center located at http://msdn.microsoft.com/security where developers can find a wealth of resources, including guidance and tools, to help them build safer applications using Microsoft technologies and platforms.
• #42: Visit the SDL Blog to get the most current ideas and thoughts from Microsoft SDL team members.Visit Michael Howard’s Blog to read all about how security can be effectively incorporated into the software development process from the author of the popular book, Writing Secure Code (Howard, Michael and David LeBlanc, Microsoft Press, Redmond, Washington, 2003).
• #45: This section provides additional slides, materials and information to supplement the main contents of the presentation.