Presentations text content in Security Development Lifecycle (SDL) Overview
Slide1
Security Development Lifecycle (SDL) Overview
Ronald Tafoya,
CISSP, CE|H, PMP
Technologist In Residence, High Desert Discovery District (HD3)
Slide2AgendaOverview.Security Development Lifecycle (SDL)
2
Slide33
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
Slide44
Design Vectors
Lead in Security vs. React
Product developers
must recognize
The importance of Security
And add it as a design vector
Slide5Security 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
Slide66
Need for a Security Development Lifecycle
Security is different
Security is a process, not a product or particular feature
Security of a product must be a system aspect
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
Slide77
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
Slide88
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
Slide99
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 3
rd
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 ManagerWho: 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
Slide1010
EXample
SDL Product PLC Overlay
Slide11Security ReviewsPotential 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 ReviewIn 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
Slide12S0 Assessment
12
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.
Slide13S1 Architecture
13
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.
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
Slide14S2 Design
14
The S2 - Design phase examines designs to verify the security and privacy models laid out in the requirements and architecture
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
Slide15S3 Early implementation
15
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.
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.
Early
implementation flaws and risks have been identified
and assigned to owners for closure prior to the next
phase S4 – Deployment.
A
revised security and privacy validation plan to reflect new findings in early security and privacy testing if needed.
Slide16S4 Deployment
16
The S4 - Deployment phase ensures the product is ready to ship from a security and privacy perspective
At the end of the phase the following should be achieved:
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.
Slide17Backup Material
17
Security Development Lifecycle (SDL) Overview
Download Presentation - The PPT/PDF document "Security Development Lifecycle (SDL) Ov..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.