Verification according to SAMM: Application Security Architecture Analysis

Software development organizations are constantly pressured to meet security standards [1]. Seeking to attend to this market demand, the OWASP, with the Framework Assurance Maturity Model (SAMM), provides the best practices for governance, design, implementation, verification, and operation. This article will explore the architecture analysis concepts present in the verification domain. We suggest you have a look at our previous articles within the SAMM series. 

You can also listen to this article:

Architecture Analysis

The verification domain seeks to verify and test the software products during the development process, ensuring that the established requirements have been reached and the security level is acceptable. It usually includes quality analysis, automatic and manual tests, and other verification and evaluation activities.

The architecture analysis practices seek to provide subsidies to ensure that the architecture and infrastructure properly attend to the security requirements to mitigate the identified threat. Such requirements must be raised during the threat modeling process present in the design domain, where, through the Application Security Verification Standards (ASVS), it’s possible to list different security requirements according to the necessary verification level, such as:

• Level 1 – directed to all the softwares;
• Level 2 – to the applications that store and handle confidential data;
• Level 3 – Application on the critical level.

Figure 1 shows a requirement definition example of ASVS automatically generated according to the identified threat. With Conviso Platform’s product Secure by Design, it’s possible to manage and monitor security requirements.

Image 1 – security requirements according to the threat (Conviso Platform)

The verification of compliance with security requirements can be performed ad hoc and then systematically for each system interface. Notice that the analysis must be performed for all the architecture components in a structured way, allowing the verification and tests of the applied requirements. After the architecture verification, it’s necessary to continuously assess the controls and their scalability according to the organization’s strategy. It enables identifying the weakness and possible improvements in the security architecture practices.

SAMM divides the architecture analysis topic into two subtopics, with recommended practices for each maturity level.

Architecture Validation

This topic seeks to indicate practices to facilitate the visualization and analysis of the high-level architecture in security measures.

• Level 1 – define a general architecture perspective and list the security mechanisms such as authentication, authorization, access management, etc. at this level, the analysis must be performed from the point of view of anonymous users, authorized users, and specific functions of the app.
• Level 2 – Format an architecture revision process for the whole organization. Regularly verify compliance with security requirements in inner and outer architecture layers.
•  Level 3 – ensure the efficiency of the implemented security controls concerning availability and scalability; at this level, it’s important to analyze whether the existing mechanisms will be enough for possible application evolutions.

In the architecture validation Process, it’s recommended to create defect registration strategies to enable the collection of metrics to evaluate existent limitations and controls.

Architecture Mitigation

The treatment of common threats must be practical and verified periodically by the information security team, together with the architecture team. Typical threats might emerge from excessive trust in automatic mechanisms. Therefore, the necessity to constantly verify the strategies used by the utilized tools.

• Level 1- verify whether the mitigations are sufficient for threats in critical solution components and structures.
• Level 2 – review each systematically each identified threat. Define a standard process for revising the architectural decisions’ records, taking into account each decision’s impact. 
• Level 3 – regularly analyze the appearance of new threats and good tactics to avoid that.

What can we conclude about architecture analysis ?

In this article, we approached the recommendations of the framework OWASP SAMM for implementing secure processes in the architectural analysis domain. It’s important to highlight that the effectiveness of implementing these processes is closely linked to the joint work of all parties involved, such as developers, designers, architects, and the security team. 

SAMM article series

1. Governance according to SAMM: Strategy and Metrics in Application Security
2. Governance according to SAMM: Policies and Conformities in Application Security
3. Governance According to SAMM: Application Security Education and Guidance
4. Design according to SAMM: Threat Modeling in Application Security
5. Design According to SAMM: Security Requirements in AppSec
6. Design according to SAMM – Secure Architecture in Application Security
7. Implementation according to SAMM: Secure Build in Application Security
8. Implementation according to SAMM: Secure Deployment in Application Security
9. Implementation According to SAMM: Defect Management in AppSec
10. Verification according to SAMM: Application Security Architecture Analysis
11. Verification according to SAMM: Requirements-Driven Testing in Application Security
12. Verification according to SAMM: Security Tests in Application Security
13. Operations according to SAMM: Application Security Incident Management
14. Operations according to SAMM: Environment Management and Application Security
15. Operations according to SAMM: Operational Management in Application Security