Skip to content

PW.1: Design Software to Meet Security Requirements and Mitigate Security Risks

Identify and evaluate the security requirements for the software; determine what security risks the software is likely to face during operation and how the software's design and architecture should mitigate those risks; and justify any cases for which risk-based analysis indicates that security requirements should be relaxed or waived. Addressing security requirements and risks during software design (i.e., secure by design) is key to improving software security and also helps improve development efficiency.

PW.1.1

Use forms of risk modeling (e.g., threat modeling, attack modeling, attack surface mapping) to help assess the security risk for the software.

Implementation Examples
  • Example 1: Train the development team (security champions, in particular) or collaborate with a risk modeling expert to create models and analyze how to use a risk-based approach to communicate the risks and determine how to address them, including implementing mitigations.\nExample 2: Perform more rigorous assessments for high-risk areas, such as protecting sensitive data and safeguarding identification, authentication, and access control, including credential management.\nExample 3: Review vulnerability reports and statistics for previous software to inform the security risk assessment.\nExample 4: Use data classification methods to identify and characterize each type of data that the software will interact with.\nExample 5: Consider processes for creating and sharing under controlled disclosure the risk and threat models used during software development to inform customer risk management decisions.
References
  • BSAFSS: SC.1
  • BSIMM: AM1.2, AM1.3, AM1.5, AM2.1, AM2.2, AM2.5, AM2.6, AM2.7, SFD2.2, AA1.1, AA1.2, AA1.3, AA2.1
  • IDASoar: 1
  • IEC62443: SM-4, SR-1, SR-2, SD-1
  • IR8397: 2.1
  • ISO27034: 7.3.3
  • MSSDL: 4
  • NISTCSF: ID.RA
  • OWASPASVS: 1.1.2, 1.2, 1.4, 1.6, 1.8, 1.9, 1.11, 2, 3, 4, 6, 8, 9, 11, 12, 13
  • OWASPMASVS: 1.6, 1.8, 2, 3, 4, 5, 6
  • OWASPSAMM: TA1-A, TA1-B, TA3-B, DR1-A
  • PCISSLC: 3.2, 3.3
  • SCAGILE: Tasks Requiring the Help of Security Experts 3
  • SCFPSSD: Threat Modeling
  • SCTTM: Entire guide
  • SP80053: AT-03, CA-02, CA-08, RA-03, SA-08, SA-11, SA-11(02), SA-11(06), SA-15, SA-15(05), SI-02
  • SP800160: 3.3.4, 3.4.5
  • SP800161: AT-03, CA-02, RA-03, RA-09
  • SP800181: T0038, T0062; K0005, K0009, K0038, K0039, K0070, K0080, K0119, K0147, K0149, K0151, K0152, K0160, K0161, K0162, K0165, K0297, K0310, K0344, K0362, K0487, K0624; S0006, S0009, S0022, S0078, S0171, S0229, S0248; A0092, A0093, A0107

PW.1.2

Track and maintain the software's security requirements, risks, and design decisions.

Implementation Examples
  • Example 1: Record the response to each risk, including how mitigations are to be achieved and what the rationales are for any approved exceptions to the security requirements. Add any mitigations to the software's security requirements.\nExample 2: Maintain records of design decisions, risk responses, and approved exceptions that can be used for auditing and maintenance purposes throughout the rest of the software life cycle.\nExample 3: Periodically re-evaluate all approved exceptions to the security requirements, and implement changes as needed.
References

PW.1.3

Where appropriate, build in support for using standardized security features and services (e.g., enabling software to integrate with existing log management, identity management, access control, and vulnerability management systems) instead of creating proprietary implementations of security features and services. [Formerly PW.4.3]

Implementation Examples
  • Example 1: Maintain one or more software repositories of modules for supporting standardized security features and services.\nExample 2: Determine secure configurations for modules for supporting standardized security features and services, and make these configurations available (e.g., as configuration-as-code) so developers can readily use them.\nExample 3: Define criteria for which security features and services must be supported by software to be developed.\nExample 4: Use common and secure logging formats and features.\nExample 5: Ensure that the software adheres to the principle of least privilege. Identify the minimal functionality needed when operating with elevated privileges (e.g., kernel space or admin privileges). Design software modules with the minimal functionality needed to run with elevated privileges, and ensure that all other capabilities and functionalities are run with lower privileges (e.g., user space or application privileges).
References