+Verification
---+V-AA Architecture Assessment
------+V-AA-A Stream A: Architecture Validation
---------+V-AA-1-A Assess application architecture
---------+V-AA-2-A Verify the application architecture for security methodically
---------+V-AA-3-A Verify the effectiveness of security components
------+V-AA-B Stream B: Architecture Mitigation
---------+V-AA-1-B Evaluate architecture for typical threats
---------+V-AA-2-B Structurally verify the architecture for identified threats
---------+V-AA-3-B Feed review results back to improve reference architectures
---+V-RT Requirements-driven Testing
------+V-RT-A Stream A: Control Verification
---------+V-RT-1-A Test the effectiveness of security controls
---------+V-RT-2-A Define and run security test cases from requirements
---------+V-RT-3-A Automate security requirements testing
------+V-RT-B Stream B: Misuse/Abuse Testing
---------+V-RT-1-B Perform fuzz testing
---------+V-RT-2-B Define and run security abuse cases from requirements
---------+V-RT-3-B Perform security stress testing
---+V-ST Security Testing
------+V-ST-A Stream A: Scalable Baseline
---------+V-ST-1-A Perform automated security testing
---------+V-ST-2-A Develop application-specific security test cases
---------+V-ST-3-A Integrate security testing tools in the delivery pipeline
------+V-ST-B Stream B: Deep Understanding
---------+V-ST-1-B Test high risk application components manually
---------+V-ST-2-B Establish a penetration testing process
---------+V-ST-3-B Establish continuous, scalable security verification

Verification

Verification focuses on the processes and activities related to how an organization checks and tests artifacts produced throughout software development. This typically includes quality assurance work such as testing, but it can also include other review and evaluation activities.

1. Pārskats

V-AA Architecture Assessment

Short description: This practice focuses on validating the security and compliance of the software and supporting infrastructure architecture.

The Architecture Assessment (AA) practice ensures that the application and infrastructure architecture adequately meets all relevant security and compliance requirements, and sufficiently mitigates identified security threats. The first stream focuses on verifying that the security and compliance requirements identified in the Policy and Compliance, and Security Requirements, practices are met, first in an ad-hoc manner, then more systematically for each interface in the system. The second stream reviews the architecture, first for mitigations against typical threats, then against the specific threats identified in the Threat Assessment practice.

In its more advanced form, the practice formalizes the architecture security review process, continuously evaluates the effectiveness of the architecture's security controls, their scalability and strategic alignment. Identified weaknesses and possible improvements are fed back to the Secure Architecture practice to improve reference architectures.
V-RT Requirements-driven Testing

Short description: This practice focuses on using both positive (control verification) and negative (misuse/abuse testing) security tests based on requirements (user stories).

The goal of the Requirements-driven Testing (RT) practice is to ensure that the implemented security controls operate as expected and satisfy the project's stated security requirements. It does so by incrementally building a set of security test and regression cases and executing them regularly.

A key aspect of this practice is its attention to both positive and negative testing. The former verifies that the application's security controls satisfy stated security requirements and validates their correct functioning. These requirements are typically functional in nature. Negative testing addresses the quality of the implementation of the security controls and aims to detect unexpected design flaws and implementation bugs through misuse and abuse testing. In its more advanced forms, the practice promotes security stress testing, such as denial of service, and strives to continuously improve application security by consistently automating security unit tests and creating security regression tests for all bugs identified and fixed.

Although both the Requirements-driven Testing and Security Testing practices are concerned with security testing, the former focuses on verifying the correct implementation of security requirements, while the latter aims to uncover technical implementation weaknesses in an application, irrespective of requirements.
V-ST Security Testing

Short description: This practice focuses on the detection and resolution of basic security issues through automation, allowing manual testing to focus on more complex attack vectors.

The Security Testing (ST) practice leverages the fact that, while automated security testing is fast and scales well to numerous applications, in-depth testing based on good knowledge of an application and its business logic is often only possible via slower, manual expert security testing. Each stream therefore has one approach at its core.

The first stream focuses on establishing a common security baseline to automatically detect so-called "low-hanging fruit". Progressively customize the automated tests for each application and increase their frequency of execution to detect more bugs and regressions earlier, as close as possible to their inception. The more bugs the automated processes can detect, the more time experts have to use their knowledge and creativity to focus on more complex attack vectors and ensure in-depth application testing in the second stream. As manual review is slow and hard to scale, reviewers prioritize testing components based on their risk, recent relevant changes, or upcoming major releases. Organizations can also access external expertise by participating in bug bounty programs, for example.

Unlike the Requirements-driven Testing practice which focuses on verifying that applications correctly implement their requirements, the goal of this practice is to uncover technical and business-logic weaknesses in the application and make them visible to management and business stakeholders, irrespective of requirements.

1.1 Atsauces

1.2 Identificētās prasības

1.3 Saistītie tiesību akti

2. Identificētās prasības

Prasības

3. Saistītie tiesību akti

Tiesību akti
  • 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.