Slide 1

Microsoft Security Development Lifecycle

Education +Process Improvement+AccountabilitySecurity Development Lifecycle2Security Development LifecycleA PROCESS by which Microsoft develops software, that defines security requirements and milestones

MANDATORY for products that are exposed to meaningful security riskEVOLVING and new factors (such as privacy are being addedCOMPATIBLE with COTS product development processesEFFECTIVE at addressing security issues; designed to produce DEMONSTRATABLE RESULTSIt has shown itself to be highly effective at reducing vulnerabilities in commercial software

3

A Security FrameworkSD3+CThreat modelingCode inspectionUnused features off by defaultReduce attack surface areaLeast PrivilegeSecurity Tools Training and EducationCommunity EngagementTransparencyClear policy

4Products 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, servicesincluding 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.Security Development Lifecycle (SDL)http://swi/sdl

5This outline is described in more detail in Security Development Lifecycle by Michael Howard and Steve Lipner. http://swi/sdlSecurity Development LifecycleDrilldownSecurity TrainingPre-SDL RequirementSDL Practice 1: Training RequirementSecure DesignThreat ModelingSecure CodingSecurity TestingPrivacySecure design, including the following topics:Attack surface reductionDefense in depthPrinciple of least privilegeSecure defaultsThreat modeling, including the following topics:Overview of threat modelingDesign implications of a threat modelCoding constraints based on a threat modelSecure 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 cryptographySecurity testing, including the following topics:Differences between security testing and functional testingRisk assessmentSecurity testing methodsPrivacy, including the following topics:Types of privacy-sensitive dataPrivacy design best practicesRisk assessmentPrivacy development best practicesPrivacy testing best practices

8RequirementsPhase OneSDL Practice 2: Security RequirementsThe optimal point to define trustworthiness requirementsIncludes specification of minimum security requirements for the applicationSDL Practice 3: Quality Gates/Bug BarsEstablish minimum acceptable levels of security and privacy qualityImproves the understanding of risksA bug bar is a quality gate that applies to the entire software development project. It is used to define the severity thresholds of security vulnerabilitiesfor 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.

11SDL Practice 4: Security and Privacy Risk AssessmentIdentify functional aspects of the software that require deep reviewInclude 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? 12DesignPhase TwoSDL Practice 5: Design RequirementsSecure Features vs. Security Features Creation of security and privacy design specificationsdesign specifications against the applications functional specificationSpecification reviewSpecification of minimal cryptographic design requirementsSDL PRACTICE 6: ATTACK SURFACE REDUCTIONreducing risk by giving attackers less opportunity to exploit a potential weak spot or vulnerabilityshutting off or restricting access to system servicesapplying the principle of least privilegeemploying layered defenses SDL PRACTICE 7: THREAT MODELINGused in environments where there is meaningful security riskto consider, document, and discuss the security implications of designsSTRIDEImplementaionPhase 4:SDL Practice 8: Use Approved ToolsDefine and publish a list of approved toolsUse the latest version of approved toolsSDL Practice 9: Deprecate Unsafe Functionsprohibit functions and APIs that are determined to be unsafeheader files (such as banned.h and strsafe.h)newer compilerscode scanning tools SDL Practice 10: Static AnalysisCan help ensure that secure coding policies are being followedother tools or human review as appropriateVerificationPhase 4SDL Practice 11: Dynamic Program AnalysisRun-time verification of softwareSDL Practice 12: Fuzz Testinga specialized form of dynamic analysismalformed or random data

SDL Practice 13: Threat Model and Attack Surface ReviewCheck deviation from design and requirementsReleasePhase 5SDL Practice 14: Incident Response Planprograms 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).

26SDL Practice 15: Final Security Reviewperformed by the security advisor with assistance from the regular development staff and the security and privacy team leadsnot a penetrate and patch exercise, nor is it a chance to perform security activities that were previously ignored or forgottenResultPassed FSRPassed FSR with exceptionsFSR with escalationSDL Practice 16: Release/ArchiveCheck that all Security and Privacy conditions are satisfiedArchive data for post-release servicing of the softwarespecifications, 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 tasks28Optional ActivitiesDepend on size and security impact

Manual Code ReviewPenetration TestingVulnerability Analysis of Similar ApplicationsAccountability for SDLYou cant manage what you cant measureEducationIndividual learning measurementTeam training complianceProcess implementationIn-process metrics provide early warningThreat model completionCode reviewedTest coverageFSR resultsPost-release metrics assess final payoffTotal and high severity vulnerabilities30