SECURITY DEVELOPMENT LIFECYCLE (SDL) OVERVIEW
RONALD TAFOYA, CISSP, CE|H, PMP
TECHNOLOGIST IN RESIDENCE, HIGH DESERT DISCOVERY DISTRICT (HD3)
AGENDA
• Overview.
• Security Development Lifecycle (SDL)
2
BASIC TERMINOLOGY
•
Security
condition of a system that results from the establishment and maintenance of measures to protect
the system. Security is an aspect of a product, not a feature
•
Privacy
The right of an entity (normally a person), acting in its own behalf, to determine the degree to
which it will interact with its environment, including the degree to which the entity is willing to share
information about itself with others
•
Trustworthy
built to meet security and privacy goals; worthy of customer trust with respect to privacy and
security
3
Design Vectors
Power
Area
Performance
Reliability
Product developers must recognize
The importance of Security
And add it as a design vector
Security
Lead in Security vs. React
4
SECURITY DESIGN VECTOR
• Establishing security as a design vector requires:
• Individuals are empowered and accountable owners for each product
• Organizations to build the required development capabilities (this is
Design for Security – DFS)
• Projects to follow the appropriate steps throughout execution (this is
Security Development Life Cycle –SDL)
• Products show results by delivering to security and privacy
requirements
NEED FOR A SECURITY DEVELOPMENT LIFECYCLE
•
•
Security is different
•
Security of a product must be a
system aspect
Security is a process, not a product
or particular feature
•
•
Attackers find the path of
least resistance, even if it’s
outside the scope of your
product
To get it right, Security must be
part of all stages of development
6
NEED FOR A SECURITY DEVELOPMENT LIFECYCLE
Building trustworthy products requires continuous effort throughout the development
lifecycle
•
•
•
Trust issues discovered and created as product matures
Trust assumptions often change during lifecycle
Trust decisions made throughout lifecycle, sometimes accidentally
Trustworthy product development is not happening consistently in the industry today
7
SDL – ROLES AND RESPONSIBILITIES
PROJECT TEAM
Project Security SDL Lead
•
•
Who: Someone in the development team
Responsibility: Owns managing the SDL Tasks to see that the appropriate resources are
assigned to each and that the tasks are completed on schedule
Security Champion
•
•
Who: The designated Security Champion for the product
Responsibility: Owns delivering product that meets security goals (person ultimately
accountable for shipping a secure product). Provides security consulting to the product team
All project development and deployment team members
•
•
Who: Everyone who takes part in definition, development, or deployment of the product
Responsibility: Follow the SDL, get trained in product security issues relevant to your role,
take product security seriously
8
SDL ROLES AND RESPONSIBILITIES (2)
SECURITY ANALYSIS TEAM
Security Analyst Team
•
Responsibility: Review trust aspects of the product throughout the lifecycle; provide analysis
results at SDL checkpoints
•
Security Champion can help you find solutions.
Security consultant
•
Who: there are many 3rd party consultants that can provides security consulting or a
separate team in the company
•
Responsibility: work with the project team to help & teach with the SDL implementation and
tasks.
SDL Program Manager
•
•
Who: The Security Champion should provide this resource company-wide
Responsibility: helps teams follow the SDL; facilitates periodic reviews of trust aspects of
product with experts as needed
9
EXAMPLE SDL PRODUCT PLC OVERLAY
10
SECURITY REVIEWS
POTENTIAL INDEPENDENT 3RD PARTY REVIEWS
•
G0 Review
• The Product Overview presentation allows the product team to familiarize Review Team with the product, and provides the product team
an opportunity to gather initial feedback from the Review Team. This review is appropriate for more complicated technologies and in
cases when early security guidance from the Review Team is necessary.
•
G1 Review
• This review allows the product team to familiarize the Review Team with the early security objectives and security requirements and to
seek additional guidance from the Review Team.
•
S1 Review
• In this review the product teams are expected to discuss their Security Objectives, Security Architecture and Threat Model, and how these
address the security concerns that the product team has already examined. The team should clearly show how the product architecture
meets the defined Security Objectives and what security gaps exist.
11
S0 ASSESSMENT
S0
Assessment
This first phase of the SDL Helps the project team identify the needed SDL activities.
The first interaction with the SDL is the SDL assessment
(doesn’t mater in what phase the project is) following
the assessment the project team will be able to clearly
identify the needed SDL activities.
S4
Deployment
S3
Early
implementation
S1
Architecture
S2
Design
12
S1 ARCHITECTURE
S0
Concept
The S1- Architecture phase ensures that product architecture, requirements, and usage
models for security and privacy meet the security and privacy goals and requirements
identified at the S0 - Concept phase.
S4
Deployment
At the end of the S1- Architecture, the following should be achieved:
• Product architecture identifies the security model
• Product architecture defines an approach for the security and privacy requirements
• Architectural analysis for security and privacy has been completed on identified risk areas
• Security and privacy risks have been closed or assigned to an owner for follow-up
• A preliminary security and privacy validation plan has been drafted and reviewed
S3
Early
implementation
S1
Architecture
S2
Design
13
S2 DESIGN
S0
Concept
The S2 - Design phase examines designs to verify the security and privacy models laid out in
the requirements and architecture
S4
Deployment
At the end of this phase, the following should be achieved:
• Design analysis for security and privacy has been completed
• Survivability mechanisms included in architecture have supporting design in place
• The design delivers on the expectations from the market and product requirement documents.
• Evaluation plans appropriate to security and privacy risk areas approved
• Gaps in design analysis identified and accepted or assigned for follow-up
S3
Early
implementation
S1
Architecture
S2
Design
14
S3 EARLY IMPLEMENTATION
The S3 - Early Implementation phase examines early implementation such as alpha code
hardware emulations etc. This ensures that the product maintains the trust models laid out in
the architecture and designs It also ensures implementation is on track for delivery of a
trustworthy product.
S4
Deployment
At the end of this phase, the following should be achieved:
• Product implementation is on track to meet the requirements architecture and design
security and privacy requirements
• Product implementation areas for further security and privacy evaluation have been
identified.
S3
• Early implementation flaws and risks have been identified
Early
and assigned to owners for closure prior to the next
implementation
phase S4 – Deployment.
• A revised security and privacy validation plan to reflect new findings in early security and
privacy testing if needed.
S0
Concept
S1
Architecture
S2
Design
15
S4 DEPLOYMENT
S0
Concept
The S4 - Deployment phase ensures the product is ready to ship from a security and privacy
perspective
S4
At the end of the phase the following should be achieved:
Deployment
• Any planned security analysis of the product is complete
• Survivability mechanisms checked that they are implemented as designed.
• The implementation delivers on security and privacy requirements as noted in the
architecture documents.
• Security evaluation plans have been completed.
• Any gaps in the security and privacy of the product identified and accepted.
S3
Early
implementation
S1
Architecture
S2
Design
16
BACKUP MATERIAL
17