Security Development Lifecycle (SDL) Overview PowerPoint Presentation, PPT - DocSlides

Security Development Lifecycle (SDL) Overview

Ronald Tafoya,

CISSP, CE|H, PMP

Technologist In Residence, High Desert Discovery District (HD3)

AgendaOverview.Security Development Lifecycle (SDL)

2

3

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

4

Design Vectors

Lead in Security vs. React

Product developers

must recognize

The importance of Security

And add it as a design vector

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

6

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

7

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

8

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

9

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

10

EXample

SDL Product PLC Overlay

Security 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

S0 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.

S1 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

S2 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

S3 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.

S4 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.

Backup Material

17