Microsoft SDL 한국마이크로소프트보안프로그램매니저김홍석부장. Security Development Lifecycle and Building Secure Applications

Transcription

1 Release Conception Microsoft SDL Security Development Lifecycle and Building Secure Applications KRnet 한국마이크로소프트보안프로그램매니저김홍석부장

2 Agenda Applications under Attack Origins of the Microsoft SDL What is Microsoft Doing about the Threat? Measurable Improvements at Microsoft Resources 2

3 APPLICATIONS UNDER ATTACK 3

4 Application Layer Attacks ~90% are remotely exploitable ~60% are in web applications Source: Microsoft Security Intelligence Report volume 8 (April 2010) 4

5 The Long Tail Vendors' Accountability for Vulnerabilities in 2007 Others 86% Top 5 ISVs 14% - Microsoft - Oracle - IBM - Cisco - Apple Sources: IBM X-Force 2007 Security Report 5

6 ORIGINS OF THE MICROSOFT SDL 6

7 Security Timeline at Microsoft Bill Gates writes Trustworthy Computing memo early 2002 Windows security push for Windows Server 2003 Microsoft Senior Leadership Team agrees to require SDL for all products that: Are exposed to meaningful risk and/or Process sensitive data SDL is enhanced Fuzz testing Code analysis Crypto design requirements Privacy Banned APIs and more Windows Vista is the first OS to go through full SDL cycle Optimize the process through feedback, analysis and automation Begin to evangelize the SDL to the software development community Security push and FSR extended to other products 7

8 Which applications are required to follow SDL? Any release commonly used or deployed within an enterprise, business, or organization Any release that regularly stores, processes, or communicates PII (as defined in Microsoft Privacy Guidelines for Developing Software Products and Services) or other sensitive customer information Any release that regularly touches or listens on the Internet or other networks Any release that accepts and/or processes data from an unauthenticated source Any functionality that parses any file type that is not protected, (i.e. not limited to system administrators) Any release that contains ActiveX and/or COM controls All Microsoft, MSN and Live.com online services that are used by external customers and hosted in the MSN environment 8

9 WHAT IS MICROSOFT DOING ABOUT THE THREAT? 9

10 Working to protect our users Education Process Accountability Administer and track security training Guide product teams to meet SDL requirements Establish release criteria and sign-off as part of FSR Incident Response (MSRC) Training Requirements Design Implementation Verification Release Response Sign up with SEC Define business owner Define security lead Define product-specific security measures Meet SDL requirements Meet release criteria Security engineering Feedback for SDL improvements Ongoing Process Improvements 10

11 Training Phase Training Requirements Design Implementation Verification Release Response Assess organizational knowledge on security and privacy establish training program as necessary Establish training criteria Content covering secure design, development, test and privacy Establish minimum training frequency Employees must attend n classes per year Establish minimum acceptable group training thresholds Organizational training targets (e.g. 80% of all technical personnel trained prior to product RTM) 11

12 Requirements Phase Training Requirements Design Implementation Verification Release Response Opportunity to consider security at the outset of a project Development team identifies security and privacy requirements Development team identifies lead security and privacy contacts Security Advisor assigned Security Advisor reviews product plan, makes recommendations, may set additional requirements Mandate the use of a bug tracking/job assignment system Define and document security and privacy bug bars 12

13 Design Phase Training Requirements Design Implementation Verification Release Response Define and document security architecture, identify security critical components Identify design techniques (layering, managed code, least privilege, attack surface minimization) Document attack surface and limit through default settings Define supplemental security ship criteria due to unique product issues Cross-site scripting tests Deprecation of weak crypto Threat Modeling Systematic review of features and product architecture from a security point of view Identify threats and mitigations 13

14 Implementation Phase Training Requirements Design Implementation Verification Release Response Full spectrum review used to determine processes, documentation and tools necessary to ensure secure deployment and operation Specification of approved build tools and options Static analysis (PREFix, /analyze (PREfast), FXCop) Banned APIs Use of operating system defense in depth protections (NX, ASLR and HeapTermination) Online services specific requirements (e.g., Cross-site scripting, SQL Injection etc) Consider other recommendations (e.g., Standard Annotation Language (SAL)) 14

15 Verification Phase Training Requirements Design Implementation Verification Release Response Started as early as possible conducted after code complete stage Start security response planning including response plans for vulnerability reports Re-evaluate attack surface Fuzz testing files, installable controls and network facing code Conduct security push (as necessary, increasingly rare) Not a substitute for security work done during development Code review Penetration testing and other security testing Review design and architecture in light of new threats 15

16 Release Phase Response Plan Training Requirements Design Implementation Verification Release Response Creation of a clearly defined support policy consistent with MS corporate policies Provide Software Security Incident Response Plan (SSIRP) Identify contacts for MSRC and resources to respond to events 24x7x365 contact information for 3-5 engineering, 3-5 marketing, and 1-2 management (PUM and higher) individuals Ensure ability to service all code including out of band releases and all licensed 3rd party code. 16

17 Release Phase Final Security Review (FSR) Training Requirements Design Implementation Verification Release Response Verify SDL requirements are met and there are no known security vulnerabilities Provides an independent view into security ship readiness The FSR is NOT: A penetration test no penetrate and patch allowed The first time security is reviewed A signoff process Key Concept: The tasks for this phase are used as a determining factor on whether or not to ship not used as a catchall phase for missed work in earlier phases 17

18 Release Phase - Archive Training Requirements Design Implementation Verification Release Response Security response plan complete Customer documentation up-to-date Archive RTM source code, symbols, threat models to a central location Complete final signoffs on Checkpoint Express validating security, privacy and corporate compliance policies 18

19 Response Phase - Execution Training Requirements Design Implementation Verification Release Response Plan the work, work the plan Execution on response tasks outlined during Security Response Planning and Release Phases 19

20 Secure Software Development Requires Process Improvement Simply looking for bugs doesn t make software secure Must reduce the chance vulnerabilities enter into design and code Requires executive commitment Requires ongoing process improvement Requires education & training Requires tools and automation Requires incentives and consequences 20

21 Simplified Implementation of the Microsoft SDL Released at February 2, pages Illustrates the core concepts of the Microsoft Security Development Lifecycle (SDL) and discusses the individual security activities that should be performed in order to claim compliance with the SDL process 21

22 MEASURABLE IMPROVEMENTS AT MICROSOFT 22

23 Microsoft s share of new vulnerability disclosures # 1 # 1 # 3 Source: Microsoft Security Intelligence Report 2008 Microsoft used to rank first Microsoft now ranks third with only 2.9% of new vulnerability disclosures Why try to chase a difficult overflow out of Vista when you have Acrobat Reader installed, some antivirus software with shoddy file parsing, and the latest itunes? Halvar Flake Security Researcher September

24 Microsoft SDL and SQL Server Total Vulnerabilities Disclosed 36 Months After Release SQL Server 2000 SQL Server 2005 Competing commercial DB Before SDL 91% reduction in Vulnerabilities After SDL Source: Microsoft TechNet security blog - Jeff Jones 24

25 Microsoft SDL and Windows Total Vulnerabilities Disclosed One Year After Release Windows XP Windows Vista RHAT Ubuntu Mac OSX Before SDL After SDL 45% reduction in Vulnerabilities Source: Windows Vista One Year Vulnerability Report, Microsoft TechNet security blog 25

26 Microsoft SDL and Internet Explorer Vulnerabilities Fixed One Year After Release Medium High Internet Explorer 6 Internet Explorer 7 Before SDL After SDL 35% reduction in vulnerabilities 63% reduction in high severity vulnerabilities Source: Browser Vulnerability Analysis, Microsoft TechNet security blog 26

27 Resources SDL Portal SDL Blog Microsoft Security Development Lifecycle Version Simplified Implementation of the Microsoft SDL 27

28 Microsoft SDL: Developer Starter Kit A compilation of baseline security developer training content items that provide guidance regarding several core Microsoft SDL topics. Each set of guidance contains PowerPoint slides speaker notes (.doc) When available, speaker notes include links to Microsoft Virtual Lab demonstrations on the topics discussed. train-the-trainer voiceovers (.wmv) comprehension questions (.doc) 28

29 Topics 01-Secure Design Principles 02-Secure Implementation Principles 03-Secure Verification Principles 04-SQL Injection Vulnerabilities 05-Cross-Site Scripting Vulnerabilities 06-Code Analysis 07-Banned APIs 08-Buffer Overflows 09-Source Code Annotation Language 10-Security Code Review 11-Compiler Defenses 12-Fuzz Testing 13-Threat Modeling Principles 14-Threat Modeling Tool Principles 29

30 Summary Attacks are moving to the application layer SDL = embedding security into software and culture Measurable results for Microsoft software Microsoft is committed to making SDL widely available and accessible 30

31 Questions? 31

32 Certified Secure Software Lifecycle Professional (ISC) 2 Secure Software Concepts - security implications in software development and for software supply chain integrity Secure Software Requirements - capturing security requirements in the requirements gathering phase Secure Software Design - translating security requirements into application design elements Secure Software Implementation/Coding - unit testing for security functionality and resiliency to attack, and developing secure code and exploit mitigation Secure Software Testing - integrated QA testing for security functionality and resiliency to attack Software Acceptance - security implication in the software acceptance phase Software Deployment, Operations, Maintenance and Disposal - security issues around steady state operations and management of software 32

33 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. 33