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