1. Security Development Lifecycle (SDL) Overview
Ronald Tafoya, CISSP, CE|H, PMP
Technologist In Residence, High Desert Discovery District (HD3)

2. Agenda
Overview.
Security Development Lifecycle (SDL)

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
Introduce concept of ‘Trustworthy’ product development

4. Design Vectors Power Performance Area Reliability Security
Product developers must recognize
The importance of Security
And add it as a design vector
Lead in Security vs. React

5. 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
The security profile of your product changes constantly due to changing assumptions, periodic decisions, and newly discovered information resulting from analysis.
SeCoE and SDL help you deal with this through prescriptive guidance (prevent), continual analysis (detect), regular checkpoints (review), and PSIR (survive).
Consistent security and privacy analysis is not being applied. SDL wants to change that.

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
The security profile of your product changes constantly due to changing assumptions, periodic decisions, and newly discovered information resulting from analysis.
SeCoE and SDL help you deal with this through prescriptive guidance (prevent), continual analysis (detect), regular checkpoints (review), and PSIR (survive).
Consistent security and privacy analysis is not being applied. SDL wants to change that.

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

10. EXample SDL Product PLC Overlay

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

12. S0 Assessment
Assessment S0
Architecture S1
Design S2
Early implementation S3
Deployment S4
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.

13. S1 Architecture
Concept S0
Architecture S1
Design S2
Early implementation S3
Deployment S4
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

14. S2 Design
Concept S0
Architecture S1
Design S2
Early implementation S3
Deployment S4
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

15. S3 Early implementation
Concept S0
Architecture S1
Design S2
Early implementation S3
Deployment S4
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.

16. S4 Deployment
Concept S0
Architecture S1
Design S2
Early implementation S3
Deployment S4
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.

17. Backup Material