[ISM] Secure-by-design:

Secure-by-design and secure-by-default principles, use of memory-safe programming languages where possible, and secure programming practices are used as part of application development.

[SSDF] Define and maintain security requirements for development infrastructures and processes (SSS-02-01-01)

Define and maintain comprehensive security requirements for software development infrastructures and processes. Regularly review and update these requirements to address emerging threats, and communicate changes to all relevant personnel. This ensures that the organization’s infrastructure remains aligned with secure-by-design and secure-by-default principles throughout the software development lifecycle.

[SAMM] Identify security requirements (SSS-02-01-01-01)

Identify security requirements for software projects by conducting a detailed review of functional requirements. Define relevant security objectives based on the desired confidentiality, integrity, or availability of the services or data provided by the software. For example, specify objectives like 'personal data should be securely stored and transmitted,' without mandating specific implementation measures upfront (e.g., 'use TLSv1.2'). Additionally, assess functionality from an attacker's perspective to identify potential misuse scenarios and determine additional protective measures. Security objectives can include specific functionality enhancements (e.g., 'Enable user identification at all times') or broader application quality goals (e.g., 'Ensure data is protected in transit'). Ensure all security requirements are specific, measurable, actionable, relevant, and time-bound (SMART). Avoid overly generic requirements (e.g., 'Protect against the OWASP Top 10') that lack actionable value or alignment with the application’s specific context. Regularly revisit and refine these requirements to address evolving threats, ensuring they remain relevant and effective throughout the development lifecycle.

Operations

ID Operation Description Phase Agent
SSS-02-01-01-01-01 Review functional requirements Analyze the functional requirements of the project to identify areas where confidentiality, integrity, or availability could be impacted. Preparation Security team, Business analysts, Development leads
SSS-02-01-01-01-02 Define security objectives Based on the review, identify security objectives for the project (e.g., protect personal data in transit or ensure secure user authentication). Preparation Security team, Business analysts
SSS-02-01-01-01-03 Perform threat modeling Analyze the system from an attacker’s perspective to identify misuse scenarios and define additional protective security requirements. Development Security team, Development teams
SSS-02-01-01-01-04 Write smart security requirements Document security requirements that are Specific, Measurable, Actionable, Relevant, and Time-bound (SMART) to ensure clarity and enforceability. Development Security team, Business analysts, Product owners
SSS-02-01-01-01-05 Validate and review requirements Conduct a review with stakeholders to validate the requirements and ensure they align with project goals and address identified risks. Development Security team, Development teams, Product owners

References

Industry framework Academic work Real-world case
Information Security Manual (ISM-0401)
NIST Secure Software Development Framework (PO.1.1)
OWASP SAMM: Software Assurance Maturity Model (D-SR-1-A)