Software Assurance - Design Review

This post continues my 12-part series about the Software Assurance Maturity Model (SAMM). Today we will be talking about Design Review, the first security practice in the Verification function.

The Design Review (also called Architecture Review) is a crucial milestone in the software assurance lifecycle, providing an opportunity to spot major high-level issues early in the process when they are still relatively inexpensive to fix. It is typically conducted by security-savvy staff who are either on the project team (for large projects) or in conjunction with the project architect(s) on smaller teams.

First Maturity Level

When first introducing the security-specific Design Review, an organization should focus on attack surface and ensuring that known security requirements are met. To identify attack surface, work from a one-page high-level architecture diagram that shows the interactions of the major components. Analyze the accessibility of each component, considering the following groups:

• Authorized users (authenticated)
  • Administrators/developers
  • Application-specific roles
• Anonymous users (unauthenticated)

As you analyze each component, group components with a similar accessibility profile together, ensuring they are secured in the same fashion. For example, if a system's main functionality can be accessed both via a standard web application and a mobile device app, then both interfaces should require the same level of security (for example, both a username/password and a security token code). Additionally, if an encrypted connection (SSL/TLS) is used for the web application, the same should be true for the mobile device app. Note any such discrepancies where interfaces have similar accessibility but different protection schemes; these are Design Review findings that must be addressed.

As part of the security requirements process, you've identified the security-specific requirements of the application. For each security requirement, ensure that it is being fulfilled by one or more design-level features of the system. Make a note of any requirements that are not currently being addressed by the design/architecture of the system--these are also part of the findings. This process should be repeated every time there are changes in the security requirements or in the system architecture.

Second Maturity Level

While a basic Design Review includes an attack surface analysis and a basic security requirements audit, a more advanced review should include an audit of all security mechanisms and a formalization of the Design Review process within the organization. For the security mechanisms audit, check each interface of the system for the presence of following security mechanisms, noting any missing features as findings: authentication (including cryptography and session management if these apply), authorization, input validation, output encoding, error handling and logging. For details on these mechanisms, take a look at my OWASP Top 10 blog series.

To ensure consistency in performing Design Reviews, your organization should institute a standard process and allow project managers to request Design Reviews as a service. Incoming requests should be reviewed by a designated team of senior managers and architects to ensure that the projects with the highest organizational risk profile get processed first.

Third Maturity Level

At the highest maturity level, the Design Review should include a data-flow analysis of the system's most sensitive resources. The analysis should focus on creation, access, update, and deletion of sensitive resources, along with critical (or even "top secret") business logic. For each data flow, look for bottlenecks and inconsistencies. For example, the same system component should not be handling both sensitive and non-sensitive data, nor should it be performing multiple functions of different business criticalities. While it is encouraged to use the same code base when the same functionality needs to be executed in different contexts, it is strongly encouraged to set up multiple instances of the code at each criticality or sensitivity level.

After having created a standard (optional) Design Review process at the second maturity level, the next step is to make the Design Review mandatory by establishing formal release requirements. Each project should be required to undergo a review towards the end of the design phase, and it will not be allowed to proceed until (for example) all high-severity findings are resolved. There can be special cases where it makes sense to approve exceptions (for example, legacy/inactive systems), but these should be carefully reviewed and only be issued for a limited amount of time until they have to be re-examined.

Summary

The Design Review is a critical milestone that allows security experts to review and modify (if needed) the system architecture to ensure consistency and adherence to best practices. An organization should strive towards setting up a formal internal process for performing Design Reviews in a repeatable and consistent fashion, eventually tying the review's results to project progress.

Next time, we will focus on Code Review, the second security practice in the Verification function and a crucial checkpoint that ensures the implementation is following the system design and its security requirements.