D487 - Secure Software Design

SDLC Phase 1

planning - a vision and next steps are created

SDLC Phase 2

requirements - necessary software requirements are determined

SDLC Phase 3

design - requirements are prepared for the technical design

SDLC Phase 4

implementation - the resources involved in the application from a known resource are determined

SDLC Phase 5

testing - software is tested to verify its functions through a known environment

SDLC Phase 6

deployment - security is pushed out

SDLC Phase 7

maintenance - ongoing security monitoring is implemented

SDLC Phase 8

end of life - the proper steps for removing software completely are considered

BSIMM

a study of real-world software security that allows you to develop your software security over time

OWASP SAMM

flexible framework for building security into a software development organization

Static Analysis

the analysis of computer software that is performed without executing programs

Dynamic Analysis

the analysis of computer software that is performed when executing programs on a real or virtual processor in real time

Fuzz Testing

automated or semi-automated testing that provides invalid, unexpected, or random data to the computer software program

Waterfall Development

software development methodology that breaks down development activities into linear sequential phases; each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks

Waterfall Phases (typical)

plan -> build -> test -> review -> deploy

Iterative Waterfall Development

each phase of a project is broken down into its own waterfall phases

Agile Development

software development methodology that delivers functionality in rapid iterations called timeboxes, requiring limited planning but frequent communication

Scrum

framework for Agile that prescribes for teams to break work into goals to be completed within sprints

Scrum Master (Scrum Role)

responsible for ensuring a Scrum team is operating as effectively as possible by keeping the team on track, planning and leading meetings, and working out any obstacles the team might face

Product Owner (Scrum Role)

ensures the Scrum team aligns with overall product goals by managing the product backlog by ordering work by priority, setting the product vision for the team, and communicating with external stakeholders to translate their needs to the team

Development Team (Scrum Role)

professionals who do the hands-on work of completing the tasks in a Scrum sprint by lending their expertise to program, design, or improve products

Lean Development

software development methodology that focuses on further isolating risk to the level of an individual feature

V-Model

a variation of the waterfall model, where the stage is turned back upwards after the coding phase

Extreme Programming (XP)

an Agile methodology that is intended to improve software quality and responsiveness

Software Security Architect

ensures that the stakeholder security requirements necessary to protect the organization's mission and business processes are adequately addressed

Software Security Champion

an expert on promoting security awareness, best practices, and simplifying software security

Software Security Evangelist

an expert to promote awareness of products to the wider software community

Functional Requirements

describe what the system will do and its core purpose

Non-Functional Requirements

describe any constraints or restrictions on a design but do not impact the core purpose of the system

Privacy Impact Assessment

process that evaluates issues and privacy impact rating in relation to the privacy of PII in the software

Product Risk Profile

helps to determine the actual cost of the product from different perspectives

Requirement Traceability Matrix

a table that lists all of the security requirements

DREAD model

damage, reproducibility, exploitability, affected users, discoverability

PASTA

the process for attack simulation and threat analysis; gives a software security team a repeatable framework for identifying threats

STRIDE

classifies threats into categories: spoofing, tampering, repudiation, information disclosed, denial of service, and elevation of privilege

Application Decomposition

determining the fundamental functions of an app

Trike

a unified conceptual framework for security auditing

Alpha Level Testing

testing done by the developers themselves

Beta Level Testing

testing done by those not familiar with the actual development of the system

Black Box Testing

tests from an external perspective with no prior knowledge of the software

Gray Box Testing

analyzes the source code for the software to help design the test cases

White Box Testing

tests from an internal perspective with full knowledge of the software

Abstract Syntax Tree (AST)

the basis for software metrics and issues to be generated at a later stage

Control Flow Analysis

the mechanism used to step through logical conditions in the code

Data Flow Analysis

the mechanism used to trace data from the points of input to the points of output

SonarQube

open-source platform for static code analysis that can detect bugs, code smells, vulnerabilities, and hotspots in over 25 programming languages

Spider

identifies inputs and supplies those to the scanning components of the security tool

PSIRT

the team that receives, investigates, and reports security vulnerabilities

Phase A1

Security Assessment - the project team identifies the product risks and creates a project outline for security milestones

Phase A2

Architecture - examines security from perspective of business risks

Phase A3

Design and Development - analyze and test software to determine security and privacy issues as you make informed decisions moving forward with your software

Phase A4

Design and Development - build onto the proper process of security testing and continue to analyze necessities at the security level

Phase A5

Ship - verifies that the product complies with security policies

Policy Compliance Analysis

done in A5 - final review of security and compliance requirements

Open-Source Licensing Review

done in A5 - final review of open-source software used in the stack

Final Security Review

done in A5 - final review of compliance against all security requirements identified during the SDL cycle - passed, passed with exceptions, not passed and requires escalation

Final Privacy Review

done in A5 - final review of compliance against all privacy requirements identified during the SDL cycle

Customer Engagement Framework

defines the process for sharing security-related information with customers

PRSA1

External Vulnerability Disclosure Response - stakeholders are clearly identified and a RACI matrix should be created

PRSA2

Third-Party Security Reviews - security assessment performed by groups other than internal testing teams

PRSA3

Post-Release Certifications - certifications from external parties to demonstrate the security posture of products or services

PRSA4 & PRSA5

Security Strategy for Legacy Code, M&A, and EOL Plans - strategy to mitigate security risk from legacy code and M&As

Governance (OpenSAMM function)

centered on how organizations manage overall software development activities

Construction (OpenSAMM function)

centered around how organizations define goals and create software within development projects

Verification (OpenSAMM function)

centered around how an organization checks and tests artifacts produced through software development

Deployment (OpenSAMM function)

centered around how an organization releases software

BSIMM Categories

governance, intelligence, software security development life cycle touchpoints, and deployment