Download Implementing Trustworthiness – Building and Delivering

Implementing Trustworthiness – Building and Delivering Secure
Software
Glenn Pittaway – Trustworthy Computing (TwC), Microsoft Corporation
MSSD-3 — третья по счету
конференция, посвященная
всестороннему обсуждению
популярной и важной темы –
минимизация уязвимостей
программного обеспечения при его
разработке.
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
What is “Trustworthiness”?
Trustworthiness
Trustworthy, adj.
Worthy of trust or confidence; reliable
Military
Oxford English Dictionary
IT
Financial
Industrial
Consumer
The
The
Theassurance
measures
priority given
needed
to different
to establish
address
threats
the
trust
predominant
willdepends
also depend
onthreats
theonperception
that
are perception
wide of
ranging
threat
Supply Chain Complexity
•
•
•
•
•
Supply Chain Complexity
Where are you now, and how do you improve?
The SDL Optimization Model
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
Simplified SDL
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
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
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
Pre-SDL Requirement: Security Training
Assess organizational knowledge – establish training program as necessary
•
Establish training criteria
–
•
Establish minimum training frequency
–
•
Content choices - covering secure design, development, test and privacy
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)
Phase One: Requirements
Opportunity to consider security at the outset of a project
•
Establish Security Requirements
–
•
Create Quality Gates / Bug Bars
–
•
One time, project wide requirements – security leads identified, security bug tracking process mandated,
architectural requirements set given the planned operational environment
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 Two: Design
Define and document security architecture, identify security critical components
•
Establish Design Requirements
–
•
Analyze Attack Surface
–
•
Required activities which include creation of design specifications, analysis of proposed security technologies (e.g.
crypto requirements) and reconciliation of plans against functional specs.
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 Three: Implementation
Determine processes, documentation and tools necessary to ensure secure development
•
Use approved tools
–
•
Deprecate Unsafe Functions
–
•
Approved list for compilers, security test tools, switches and flags; enforced project wide.
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 Four: Verification
Verification of SDL security and privacy activities performed earlier in the process
•
Dynamic Analysis
–
•
Fuzz Testing
–
•
Runtime verification and analysis of programs to identify critical security problems
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 Five: Release
Satisfaction of clearly defined release criteria – consistent with organizational policy
•
Incident Response Plan
–
•
Final Security Review
–
•
Creation of a response plan that outlines engineering, management and “on-call” contacts, security servicing
plans for all code, including 3rd party artifacts.
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.
Post-SDL Requirement: Response
“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
Security
Lifecycle
SoftwareDevelopment
Integrity
Software Integrity
(Risk Based Approach)
•
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
Resources
SDL Portal
http://www.microsoft.com/sdl
SDL Blog
http://blogs.msdn.com/sdl/
SDL Process on MSDN (Web)
http://msdn.microsoft.com/enus/library/cc307748.aspx
Simplified Implementation of the
Microsoft SDL
http://go.microsoft.com/?linkid=970
8425
SAFECode
http://www.safecode.org/publications
/SAFECode_Supply_Chain0709.pdf
Open Group OTTF
http://www.opengroup.org/ottf
Thank you
Спасибо за внимание