1. Implementing Trustworthiness – Building and Delivering Secure Software Glenn Pittaway – Trustworthy Computing (TwC), Microsoft Corporation MSSD-3 — третья по счету конференция, посвященная всестороннему обсуждению популярной и важной темы – минимизация уязвимостей программного обеспечения при его разработке.

2. Goals Provide an understanding of the Microsoft view of security “trustworthiness” Position Microsoft’s secure development efforts against its software integrity work Help you understand how to measure your current secure development stance, and how to improve it Provide an understanding of the “Simplified SDL” Provide an overview of resources available

3. What is “Trustworthiness”?

4. Trustworthiness Trustworthy, adj. Worthy of trust or confidence; reliable Oxford English Dictionary Military IT Financial Consumer Cybercrime Cyber Warfare Cyber Espionage Industrial The assurance needed to establish trust depends on the perception of threatThe priority given to different threats will also depend on that perceptionThe measures needed to address the predominant threats are wide ranging

5. Requirement: Trusted Products Concerns: Economic National Security Public Safety Dependence on Foreign Sources Reciprocity Government & Critical Infrastructure Supply Chain Complexity

6. Government & Critical Infrastructure Supply Chain Complexity

7. Where are you now, and how do you improve? The SDL Optimization Model

8. SDL Optimization Model A technical road map designed to help those responsible for implementing the Security Development Lifecycle understand the state of their current practices and move their organizations towards full adoption of the SDL Organizational Maturity

9. Simplified SDL

10. What is the Simplified SDL? A minimum threshold for SDL compliance at the “Advanced” maturity level as defined in the Optimization Model A concise statement of –The roles and responsibilities for individuals involved in the application development process –Mandatory security activities –Optional security activities –The application security verification process

11. SDL Applicability Applications exhibiting one or more of the following characteristics should be subject to the SDL: –Deployed in a business or enterprise environment –Processes personally identifiable information (PII) or other sensitive information –Communicates regularly over the Internet or other networks

12. SDL Roles and Responsibilities A centralized, internal advisory group is preferable Reviewer/Advisory Roles –Provide security and privacy oversight, have the authority to accept or reject security and privacy plans from a project team. –Security Advisor/Privacy Advisor - filled by subject-matter experts (SMEs) from outside the project team, fulfills two sub-roles: Auditor - monitoring each phase of the development process and attest to successful completion security requirements Expert - providing verifiable subject-matter expertise in security. –Combination of Advisory Roles - the security advisor role may be combined with the role of privacy advisor if possible Team Champions –Should be filled by SMEs from the project team –Responsible for negotiation, acceptance, and tracking of minimum security and privacy requirements and maintaining clear lines of communication with advisors and decision makers –Security Champion/Privacy Champion - responsible for coordinating and tracking security issues for the project, reporting it to the security advisor and to other relevant parties

13. Assess organizational knowledge – establish training program as necessary Establish training criteria –Content choices - 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) Pre-SDL Requirement: Security Training

14. Opportunity to consider security at the outset of a project Establish Security Requirements –One time, project wide requirements – security leads identified, security bug tracking process mandated, architectural requirements set given the planned operational environment Create Quality Gates / Bug Bars –Minimum performance and quality criteria for each stage and for the project as a whole, Security and Privacy Risk Assessment –Risk assessment performed to determine critical components for the purposes of deep security and privacy review Phase One: Requirements

15. Define and document security architecture, identify security critical components Establish Design Requirements –Required activities which include creation of design specifications, analysis of proposed security technologies (e.g. crypto requirements) and reconciliation of plans against functional specs. Analyze Attack Surface –Defense in depth strategies employed – use of layered defenses used to mitigate severity. Threat Modeling –Structured, component-level analysis of the security implications of a proposed design. Phase Two: Design

16. Determine processes, documentation and tools necessary to ensure secure development Use approved tools –Approved list for compilers, security test tools, switches and flags; enforced project wide. Deprecate Unsafe Functions –Prohibition of unsafe functions, APIs, when using native (C/C++) code. Static Code Analysis –Scalable in-depth code review, augmentation by other methods as necessary to address weaknesses in static analysis tools. Phase Three: Implementation

17. Verification of SDL security and privacy activities performed earlier in the process Dynamic Analysis –Runtime verification and analysis of programs to identify critical security problems Fuzz Testing –Specialized dynamic analysis technique used to deliberately cause program failure by injection of random, deliberately malformed inputs. Attack Surface / TM review –Re-review of attack surface and threat models when the program is “code complete” to ensure security assumptions and mitigations specified at design time are still relevant. Phase Four: Verification

18. Satisfaction of clearly defined release criteria – consistent with organizational policy Incident Response Plan –Creation of a response plan that outlines engineering, management and “on-call” contacts, security servicing plans for all code, including 3rd party artifacts. Final Security Review –Deliberate examination of all security and privacy activities conducted during development Release Archive –SDL compliance certification and archival of all information and data necessary for post-release servicing of the software. Phase Five: Release

19. “Plan the work, work the plan…” Execute Incident Response Plan –Performance of activities outlined in response plan created during Release phase Other non-development, post-release process requirements –Root cause analysis of found vulnerabilities: Is it a human, process, or automation failure? Addressed immediately and tagged for inclusion in next revision of SDL Post-SDL Requirement: Response

20. Security Development Lifecycle We evaluate threats within software development model and focus on areas of significant risk (e.g., people, process, technology) Resulting Control Categories –Proof of Identity –Access Management –Development Process Controls –Build Process Controls –Malware Scanning –Code Signing Software Integrity (Risk Based Approach) Software Integrity (Risk Based Approach)

21. SDL Portal http://www.microsoft.com/sdl SDL Blog http://blogs.msdn.com/sdl/ SDL Process on MSDN (Web) http://msdn.microsoft.com/en- us/library/cc307748.aspx Simplified Implementation of the Microsoft SDL http://go.microsoft.com/?linkid=970 8425 SAFECode http://www.safecode.org/publication s/SAFECode_Supply_Chain0709.p df Open Group OTTF http://www.opengroup.org/ottf Resources

22. Thank you Спасибо за внимание