Microsoft Security Development Lifecycle امیرحسین علی اکبریان

Education + Process Improvement + Accountability Security Development Lifecycle

Security Development Lifecycle A PROCESS by which Microsoft develops software, that defines security requirements and milestones MANDATORY for products that are exposed to meaningful security risk EVOLVING and new factors (such as privacy are being added COMPATIBLE with COTS product development processes EFFECTIVE at addressing security issues; designed to produce DEMONSTRATABLE RESULTS It has shown itself to be highly effective at reducing vulnerabilities in commercial software

A Security Framework SD3+C Threat modeling Code inspection Unused features off by default Reduce attack surface area Least Privilege Security Tools Training and Education Products go through our improved Trustworthy Computing release process, based upon the concepts of Secure by design, secure by default, secure in deployment and great communications. Microsoft is committed to enabling every customer to work, communicate, and transact business more securely. Behind the global security mobilization announced in October 2003, we will continue toward that goal by working closely with customers, partners, and the industry. We measure our efforts using the SD³+C framework. •Secure by Design. Implementing threat modeling and other key security considerations in design and development stages. These considerations include: mandatory training in writing secure code; code reviews and penetration testing; automated code diagnostic tools; and redesigned architecture to maximize software resilience. •Secure by Default. Maximizing security in default configurations of shipped software. To reduce risk of attack, Microsoft has changed default configurations so that service settings are not enabled at delivery. •Secure in Deployment. Promoting more secure deployment and management of our software. These efforts include scanning tools, services—including patch management with configuration verification functions, and localized versions of security bulletins and tools, such as Software Update Services and Baseline Security Analyzer. •Communications. Keeping customers informed. These efforts include timely communication about software update releases and our worldwide Security Response Process. In addition, we are working with government, partners, and academia to deliver security education, offer security certification programs for IT professionals, and conduct consumer protection campaigns worldwide. Community Engagement Transparency Clear policy

Security Development Lifecycle (SDL) This outline is described in more detail in “Security Development Lifecycle” by Michael Howard and Steve Lipner. http://swi/sdl http://swi/sdl

Security Development Lifecycle Drilldown

Pre-SDL Requirement Security Training

SDL Practice 1: Training Requirement Secure Design Threat Modeling Secure Coding Security Testing Privacy Secure design, including the following topics: Attack surface reduction Defense in depth Principle of least privilege Secure defaults Threat modeling, including the following topics: Overview of threat modeling Design implications of a threat model Coding constraints based on a threat model Secure coding, including the following topics: Buffer overruns (for applications using C and C++) Integer arithmetic errors (for applications using C and C++) Cross-site scripting (for managed code and Web applications) SQL injection (for managed code and Web applications) Weak cryptography Security testing, including the following topics: Differences between security testing and functional testing Risk assessment Security testing methods Privacy, including the following topics: Types of privacy-sensitive data Privacy design best practices Privacy development best practices Privacy testing best practices

Phase One Requirements

SDL Practice 2: Security Requirements The optimal point to define trustworthiness requirements Includes specification of minimum security requirements for the application

SDL Practice 3: Quality Gates/Bug Bars Establish minimum acceptable levels of security and privacy quality Improves the understanding of risks A bug bar is a quality gate that applies to the entire software development project. It is used to define the severity thresholds of security vulnerabilities—for example, no known vulnerabilities in the application with a “critical” or “important” rating at time of release. The bug bar, once set, should never be relaxed. A dynamic bug bar is a moving target that is likely to be poorly understood within the development organization.

SDL Practice 4: Security and Privacy Risk Assessment Identify functional aspects of the software that require deep review Include following information (Security) Which portions of the project will require threat models before release? (Security) Which portions of the project will require security design reviews before release? (Security) Which portions of the project (if any) will require penetration testing by a mutually agreed upon group that is external to the project team? (Security) Are there any additional testing or analysis requirements the security advisor deems necessary to mitigate security risks? (Security) What is the specific scope of the fuzz testing requirements? (Privacy) What is the Privacy Impact Rating?

Phase Two Design

SDL Practice 5: Design Requirements “Secure Features” vs. “Security Features” Creation of security and privacy design specifications design specifications against the application’s functional specification Specification review Specification of minimal cryptographic design requirements

SDL PRACTICE 6: ATTACK SURFACE REDUCTION reducing risk by giving attackers less opportunity to exploit a potential weak spot or vulnerability shutting off or restricting access to system services applying the principle of least privilege employing layered defenses

SDL PRACTICE 7: THREAT MODELING used in environments where there is meaningful security risk to consider, document, and discuss the security implications of designs STRIDE

Phase 4: Implementaion

SDL Practice 8: Use Approved Tools Define and publish a list of approved tools Use the latest version of approved tools

SDL Practice 9: Deprecate Unsafe Functions prohibit functions and APIs that are determined to be unsafe header files (such as banned.h and strsafe.h) newer compilers code scanning tools

SDL Practice 10: Static Analysis Can help ensure that secure coding policies are being followed other tools or human review as appropriate

Phase 4 Verification

SDL Practice 11: Dynamic Program Analysis Run-time verification of software

SDL Practice 12: Fuzz Testing a specialized form of dynamic analysis malformed or random data

SDL Practice 13: Threat Model and Attack Surface Review Check deviation from design and requirements

Phase 5 Release

SDL Practice 14: Incident Response Plan programs with no known vulnerabilities at the time of release can be subject to new threats that emerge over time An identified sustained engineering (SE) team, or if the team is too small to have SE resources, an emergency response plan (ERP) that identifies the appropriate engineering, marketing, communications, and management staff to act as points of first contact in a security emergency. On-call contacts with decision-making authority that are available 24 hours a day, seven days a week. Security servicing plans for code inherited from other groups within the organization. Security servicing plans for licensed third-party code, including file names, versions, source code, third-party contact information, and contractual permission to make changes (if appropriate).

SDL Practice 15: Final Security Review performed by the security advisor with assistance from the regular development staff and the security and privacy team leads not a “penetrate and patch” exercise, nor is it a chance to perform security activities that were previously ignored or forgotten Result Passed FSR Passed FSR with exceptions FSR with escalation

SDL Practice 16: Release/Archive Check that all Security and Privacy conditions are satisfied Archive data for post-release servicing of the software specifications, source code, binaries, private symbols, threat models, documentation, emergency response plans, license and servicing terms for any third-party software and any other data necessary to perform post-release servicing tasks

Optional Activities Depend on size and security impact Manual Code Review Penetration Testing Vulnerability Analysis of Similar Applications

Accountability for SDL You can’t manage what you can’t measure… Education Individual learning measurement Team training compliance Process implementation In-process metrics provide early warning Threat model completion Code reviewed Test coverage FSR results Post-release metrics assess final payoff Total and high severity vulnerabilities