Secure Development Lifecycle - MIS Laboratory

lumpysteerΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 10 μήνες)

89 εμφανίσεις

Process

+

Education

+

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
(not all methodologies do this)

It has shown itself to be highly effective at reducing vulnerabilities in
commercial software



A Security Framework

SD
3
+C

Threat modeling

Code inspection

Penetration testing

Unused features off by default

Reduce attack surface area

Least Privilege

Prescriptive Guidance

Security Tools

Training and Education

Community Engagement

Transparency

Clear policy

Requirements
Design
Implementation
Verification
Release
Support
&
Servicing
Functional
Specifications
Design
Specifications
Testing and Verification
Development of New Code
Bug fixes
Code Signing
&
Checkpoint
Express
Signoff
RTM
Alpha
&
Beta Pre releases
Feature Lists
Quality
Guidelines
Architecture Docs
Schedules
Product Support
Service Packs
/
QFEs
Security Updates
Final
Security
Review
Security
Servicing
&
Response
Execution
Prepare
Security
Response
Plan
Security
Push
Security Kickoff
&
Register
With SWI
Use Security
Development Tools
&
Security Best
Dev
&
Test Practices
Threat
Modeling
Security
Design
Best
Practices
Create
Security
Documentation
And Tools
For Product
Security Training
Pen Testing
Final Release
Candidate
Product Code
Complete
Security
Architecture
&
Attack Surface
Review
Threat Modeling
Complete and
Mitigations
Reflected in
Specifications
Security Development Lifecycle Tasks and Processes
Traditional Microsoft Software Product Development Lifecycle Tasks and Process
Sign off on
Security
Requirements
In
Checkpoint Express

Security Development Lifecycle

vs.

Traditional Development Lifecycle

Security Development Lifecycle
(SDL)

Product Development Timeline

Education

-
New Hire

-
Refresher

Design phase

-
Security plan complete

-
Security milestones understood

-
Design standards & guidelines identified

-
Security architecture complete

-
Threat models

& design review complete

-
Ship criteria agreed upon

Requirements phase

-
Security “buddy” assigned

Implementation phase

-
Secure coding
standards adhered to

-
Security testing
standards adhered to

-
Security tools use

Verification phase

-
Security push

Release phase

-
Final Security Review

RTM & deployment

-
PRS requires FSR sign
-
off

Security response

http://swi/sdl

Security Development Lifecycle

Drilldown

Education and Awareness

(Prior to Requirements)

All disciplines (Dev/QA/PM/UA/UE) must understand
security!


All disciplines must complete at least one

security training
class sometime in the last 12 months

All disciplines must complete the following reading:

Writing Secure Code, Version 2

(
ISBN:


0
-
7356
-
1722
-
8
)

Threat Modeling

(ISBN: 0
-
7356
-
1991
-
3

)


Exit criteria

Successful completion of requirements listed above

Required Reading

Phase 1: Requirements

Opportunity to consider security at the outset


Development team identifies security requirements

Who will use the application

Are security requirements equal for all users

Standalone, Intranet or Extranet availability

Internal or external usage

What are the assets

What are the implications if security fails

Who is responsible for operations



Project Inception

(Requirements)


Designate a security coordinator

Update Bug reporting tools

Security Bug Effect field

Security Cause field

Security bug bar document

Critical, Important & moderate bugs fixed before RTM
.

Project Inception

Configure the bug reporting tool


Add a Security Bug Effect field

Not a Security Bug

Spoofing

Tampering

Repudiation

Information Disclosure

Denial of Service

Elevation of Privilege

Attack Surface Reduction*


Project Inception

Configure the bug reporting tool

Add a Security Cause field

Cryptographic Weakness

Weak Authentication

Weak Authorization/Bad ACL

Ineffective Secret Hiding

Unlimited Resource
Consumption

Incorrect/No Error Messages

Bad/No Path Canonicalization

Other


Not a Security Bug

Buffer Overflow/Underflow

Arithmetic Error (int
overflow)

SQL/Script Injection

Directory Traversal

Race Condition

Cross
-
Site Scripting

Cryptographic Weakness

Project Inception

Deliverables


Security Plan Document

Outlines the processes and work items that a
product team will follow in order to integrate SDL
into their product development process


Security Bug Bar Definition

Project Inception

(Microsoft specific)


Secure Windows Initiative (SWI) team assigns
SWI Buddy

SWI Buddy reviews product plan, makes
recommendations, ensures resources allocated
by management

SWI Buddy assesses security milestones and
exit criteria

(NOTE: This SWI Buddy will stay with the project
through the Final Security Review)

Design

Define and document security architecture

Identify security critical components (“trusted base”)

Identify design techniques (e.g., layering, managed code,
least privilege, attack surface minimization)

Document attack surface and limit through default settings

Create threat models (e.g., identify assets, interfaces,
threats, risk) and mitigate threats through
countermeasures

Identify specialized test tools

Define supplemental ship criteria due to unique product
issues (e.g., cross
-
site scripting tests)

Design

Security section in design / functional spec.

Explaining the impact of security on the feature.


Security architecture document

Attack surface measurement

Product structure, emphasis on layering.


Exit criteria:
Design review complete and signed
off by development team and SWI Buddy

Design

Team members should complete threat modeling
training.

Threat models addressing all the functionality of
the product should be completed.

Functional specs / Design specs should
document mitigations

Threat models should be reviewed by architects,
dev, test and PM to ensure its
comprehensiveness.

Design

Threat modeling in detail

Development

Apply coding and testing standards (e.g.,
safe string handling)

Apply fuzz testing tools (structured invalid
inputs to network protocol and file parsers)

Apply static code analysis tools to find, e.g.,
buffer overruns, integer overruns,
uninitialized variables, etc (e.g. FxCop)

Conduct code reviews

Verification

Software functionality complete

and enters Beta

Because code complete, testing both new and
legacy code

Security Push

Security push is not a substitute for security work
during development

Security push provides an opportunity to focus on
security

Code reviews (especially legacy/unchanged code)

Penetration and other security testing

Review design, architecture, threat models in light of new
threats

Verification

Security Testing in detail

Final Security Review (FSR)

“From a security viewpoint, is this software ready to
deliver to customers?”

Two to six months prior to software completion

Software must be in a stable state with only minimal non
-
security
changes expected prior to release

FSR components

Completion of a questionnaire by the product team

Interview by a security team member assigned

to the FSR

Review of bugs that were initially identified as security bugs, but on
further analysis were determined not to have impact on security, to
ensure that the analysis was done correctly

Analysis of any newly reported vulnerabilities affecting similar
software to check for resiliency

Additional penetration testing, possibly by outside contractors to
supplement security team

Final Security Review (FSR)

FSR results: If the FSR finds a pattern of
remaining vulnerabilities, the proper
response is not just to fix the vulnerabilities
found, but to revisit the earlier phases and
take pointed actions to address root causes
(e.g., improve training, enhance tools)

FSR is NOT “penetrate and patch”

Response Phase

Patch Management in place

Team on standby to address security response
issues if necessary.

Post Mortems and feedback to the SDL

Reinitiate security push (or more of process)

Update code review guidelines

Update tools

Other corrective steps as needed

Requirements
Design
Implementation
Verification
Release
Support
&
Servicing
Functional
Specifications
Design
Specifications
Testing and Verification
Development of New Code
Bug fixes
Code Signing
&
Checkpoint
Express
Signoff
RTM
Alpha
&
Beta Pre releases
Feature Lists
Quality
Guidelines
Architecture Docs
Schedules
Product Support
Service Packs
/
QFEs
Security Updates
Final
Security
Review
Security
Servicing
&
Response
Execution
Prepare
Security
Response
Plan
Security
Push
Security Kickoff
&
Register
With SWI
Use Security
Development Tools
&
Security Best
Dev
&
Test Practices
Threat
Modeling
Security
Design
Best
Practices
Create
Security
Documentation
And Tools
For Product
Security Training
Pen Testing
Final Release
Candidate
Product Code
Complete
Security
Architecture
&
Attack Surface
Review
Threat Modeling
Complete and
Mitigations
Reflected in
Specifications
Security Development Lifecycle Tasks and Processes
Traditional Microsoft Software Product Development Lifecycle Tasks and Process
Sign off on
Security
Requirements
In
Checkpoint Express
Final
Safety
Review
(
Privacy
+
Security
)
Privacy
Servicing
&
Response
Execution
Prepare Privacy Response Plan
Privacy
Design
Best
Practices
Create Privacy GPO and Deployment Guides
Security Training with Privacy Added
Sign off on
Updated Privacy
Requirements
In
Checkpoint Express
Formal Privacy Reviews
(
FPR
)
of P
1
Products for EACH Public Release
(
Random FPR audits for P
2
)
Use Privacy
Development Tools
&
Privacy Best Dev
+
Test Practices
Privacy Additions to SDL

Security Development Lifecycle
(
with Privacy
)
Tasks
mapped against Traditional Microsoft Software Development Lifecycle
V
1
.
4
(
Jan
28
,
2005
)
Alpha
&
Beta Pre releases
Privacy
Design
Review
(
P
1
&
some P
2
)
Privacy
Initial
Assessment
Draft
Privacy
Policy
Stmt
FPR
*
FPR
*
Privacy
Detailed
Asmt
(
P
1
&
P
2
)
FPR
*
FPR
*
Privacy Added
To Threat Modeling
FPR needed for initial public pre
-
release
(
alpha or beta releases
)
,
and
subsequent releases if significant
changes happen after initial release
Consult with Privacy
SMEs as needed
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

Implications for Partners and Customers

As operating system security improves, attackers will
move “up the stack”

Be ready to meet the challenge

Take advantage of SDL lessons learned

Use available resources (Microsoft or other)

Tools

Books

Training

Process details less important than process

Try the process

Measure effectiveness

Update the process

Summary

Security is an evolving challenge

SDL process has proven effective at
improving software security

SDL can be emulated by other
organizations

Key component of SDL


and improving
security


is commitment to continuous
improvement

Threat Modeling Tool

http://www.microsoft.com/downloads/details
.aspx?familyid=59888078
-
9DAF
-
4E96
-
B7D1
-
944703479451&displaylang=en

© 2005 Microsoft Corporation. All rights reserved.

This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.