MICROSOFT SECURITY DEVELOPMENT LIFECYCLE amirhoseinaliakbarian com Education Process

MICROSOFT SECURITY DEVELOPMENT LIFECYCLE ﺍﻣیﺮﺣﺴیﻦ ﻋﻠی ﺍکﺒﺮیﺎﻥ ۱۳۸۹ آﺬﺭﻣﺎﻩ amirhosein@aliakbarian. com

Education + Process Improvment + 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 SD 3+C Threat modeling Code inspection Unused features off by default Reduce attack surface area Least Privilege Security Tools Training and Education Community Engagement Transparency Clear policy

SECURITY DEVELOPMENT LIFECYCLE (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

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

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

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

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