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)

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

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

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

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.

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

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

EXample SDL Product PLC Overlay

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.

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.

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

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

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.

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.

Backup Material