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

2. Education + Process Improvement + Accountability
Security Development Lifecycle

3. 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

4. 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

5. Security Development Lifecycle (SDL)
This outline is described in more detail in “Security Development Lifecycle” by Michael Howard and Steve Lipner.

6. Security Development Lifecycle
Drilldown

7. Pre-SDL Requirement
Security Training

8. 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

9. Phase One
Requirements

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

11. 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.

12. 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?

13. Phase Two
Design

14. 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

15. 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

16. 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

17. Phase 4:
Implementaion

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

19. 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

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

21. Phase 4
Verification

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

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

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

25. Phase 5
Release

26. 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).

27. 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

28. 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

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

30. 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