+Design
---+D-TA Threat Assessment
------+D-TA-A Stream A: Application Risk Profile
---------+D-TA-1-A Perform application risk assessments
---------+D-TA-2-A Inventory risk profiles
---------+D-TA-3-A Periodic review of risk profiles
------+D-TA-B Stream B: Threat Modeling
---------+D-TA-1-B Perform basic threat modeling
---------+D-TA-2-B Standardize and scale threat modeling
---------+D-TA-3-B Optimize threat modeling
---+D-SR Security Requirements
------+D-SR-A Stream A: Software Requirements
---------+D-SR-1-A Identify security requirements
---------+D-SR-2-A Standardize and integrate security requirements
---------+D-SR-3-A Develop a security requirements framework
------+D-SR-B Stream B: Supplier Security
---------+D-SR-1-B Perform vendor assessments
---------+D-SR-2-B Discuss security responsibilities with suppliers
---------+D-SR-3-B Align security methodology with suppliers
---+D-SA Secure Architecture
------+D-SA-A Stream A: Architecture Design
---------+D-SA-1-A Adhere to basic security principles
---------+D-SA-2-A Provide preferred security solutions
---------+D-SA-3-A Build reference architectures
------+D-SA-B Stream B: Technology Management
---------+D-SA-1-B Identify tools and technologies
---------+D-SA-2-B Promote preferred tools and technologies
---------+D-SA-3-B Enforce the use of recommended technologies

Design

Design concerns the processes and activities related to how an organization defines goals and creates software within development projects. In general, this will include requirements gathering, high-level architecture specification and detailed design.

1. Przegląd

D-TA Threat Assessment

Short description: This practice focuses on identifying potential threats in applications.

The Threat Assessment (TA) practice focuses on identifying and understanding project-level risks based on the functionality of the software being developed and characteristics of the runtime environment. From details about threats and likely attacks against each project, the organization as a whole operates more effectively through better decisions about prioritization of initiatives for security. Additionally, decisions about risk acceptance are more informed and therefore better aligned with the business.

By starting with simple threat models and building application risk profiles, an organization improves over time. Ultimately, a sophisticated organization would maintain this information in a way that is tightly coupled to the compensating factors and pass-through risks from external entities. This provides greater breadth of understanding for potential downstream impacts from security issues, tradeoffs, or flaws, while keeping a close watch on the organization’s current performance against known threats.
D-SR Security Requirements

Short description: This practice focuses on defining appropriate security requirements for your software and your software suppliers.

The Security Requirements (SR) practice focuses on security requirements that are important in the context of secure software. A first type deals with typical software-related requirements, to specify objectives and expectations to protect the service and data at the core of the application. A second type deals with requirements relative to supplier organizations that are part of the development context of the application, in particular for outsourced development. It is important to streamline the expectations in terms of secure development because outsourced development can have a significant impact on the security of the application. The security of 3rd party (technical) libraries is part of the software supply chain stream (see Secure Build), and it is not included in this practice.
D-SA Secure Architecture

Short description: The secure architecture practice focuses on managing architectural risks for the software solution.

The Secure Architecture (SA) practice focuses on the security linked to components and technology you deal with during the architectural design of your software. Secure Architecture Design looks at the selection and composition of components that form the foundation of your solution, focusing on its security properties. Technology Management looks at the security of supporting technologies used during development, deployment and operations, such as development stacks and tooling, deployment tooling, and operating systems and tooling.

1.1 Odwołania

1.2 Zidentyfikowane wymagania

1.3 Powiązane regulacje

2. Zidentyfikowane wymagania

Wymagania

3. Powiązane regulacje

Regulacje
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.