Architecture Analysis

Architecture Analysis encompasses capturing software architecture in concise diagrams, applying lists of risks and threats, adopting a process for review (such as STRIDE or Architecture Risk Analysis), and building an assessment and remediation plan for the organization.

Architecture Analysis Level 1

[AA1.1: 90] Perform security feature review.

To get started in architecture analysis, center the process on a review of security features. Security-aware reviewers first identify the security features in an application (authentication, access control, use of cryptography, etc.) and then study the design looking for problems that would cause these features to fail at their purpose or otherwise prove insufficient. For example, a system that was subject to escalation of privilege attacks because of broken access control or a mobile application that stashed away PII on local storage would both be identified in this kind of review. At higher levels of maturity, the activity of reviewing features is eclipsed by a more thorough approach to architecture analysis. In some cases, use of the firm’s secure-by- design components can streamline this process.

[AA1.2: 30] Perform design review for high-risk applications.

The organization learns about the benefits of architecture analysis by seeing real results for a few high-risk, high- profile applications. The reviewers must have some experience performing detailed design review and breaking the architecture being considered, especially for new platforms or environments. In all cases, design review produces a set of architecture flaws and a plan to mitigate them. If the SSG is not yet equipped to perform an in-depth architecture analysis, it uses consultants to do this work. Ad hoc review paradigms that rely heavily on expertise can be used here, although they do not scale in the long run. A review focused only on whether a software project has performed the right process steps will not generate expected results.

[AA1.3: 24] Have SSG lead design review efforts.

The SSG takes a lead role in architecture analysis by performing a design review to build the organization’s ability to uncover design flaws. Breaking down an architecture is enough of an art that the SSG must be proficient at it before they can turn the job over to the architects, and proficiency requires practice. The SSG cannot be successful on its own either—it’s likely they’ll need help from architects or implementers to understand the design. With a clear design in hand, the SSG might carry out the detailed review with a minimum of interaction with the project team. At higher levels of maturity, the responsibility for leading review efforts shifts toward software architects. Approaches to architecture analysis (and threat modeling) evolve over time. Do not expect to set a process and use it forever.

[AA1.4: 49] Use a risk questionnaire to rank applications.

To facilitate security feature and design review processes, the SSG uses a risk questionnaire to collect basic information about each application so that it can determine a risk classification and prioritization scheme. Questions might include, “Which programming languages is the application written in?”, “Who uses the application?”, and “Does the application have a mobile client?” A qualified member of the application team completes the questionnaire. The questionnaire should be short enough that it can be completed in a matter of hours. The SSG might use the answers to categorize the application as high, medium, or low risk. Because a risk questionnaire can be easy to game, it’s important to put into place some spot checking for validity and accuracy. An overreliance on self-reporting or automation can render this activity impotent.

Architecture Analysis Level 2

[AA2.1: 14] Define and use AA process.

The SSG defines and documents a process for architecture analysis and applies it in the design reviews it conducts to find flaws. The process includes a standardized approach for thinking about attacks, security properties, and the associated risk. The process is defined rigorously enough that people outside the SSG can be taught to carry it out. Particular attention should be paid to documentation of both the architecture under review and any security flaws uncovered. Tribal knowledge doesn’t count as a defined process. Microsoft’s STRIDE and Synopsys’ ARA are examples of this process. Note that even these two methodologies for architecture analysis have evolved greatly over time. Make sure to access up-to-date sources for architecture analysis information because many early publications are outdated and no longer apply.

[AA2.2: 12] Standardize architectural descriptions (including data flow).

Defined AA processes (see [AA2.1 Define and use AA process]) use an agreed-upon format for describing architecture, including a means for representing data flow. This format, combined with an architecture analysis process, makes architecture analysis tractable for people who are not security experts. In the case of cloud applications, data is likely to flow across the Internet. A network diagram is useful in this case, but the description should go into detail about how the software itself is structured. A standard architecture description can be enhanced to provide an explicit picture of information assets that require protection. Standardized icons that are consistently used in UML diagrams, Visio templates, and whiteboard squiggles are especially useful.

Architecture Analysis Level 3

[AA3.1: 2] Have software architects lead design review efforts.

Software architects throughout the organization lead the architecture analysis process most of the time. The SSG still might contribute to architecture analysis in an advisory capacity or under special circumstances. This activity requires a well-understood and well-documented architecture analysis process (see [AA2.1 Define and use AA process]). Even in that case, consistency is difficult to attain because breaking architectures requires so much experience.

[AA3.2: 0] Drive analysis results into standard architecture patterns.

Failures identified during architecture analysis are fed back to the security design committee so that similar mistakes can be prevented in the future through improved design patterns (see [SFD3.1 Form a review board or central committee to approve and maintain secure design patterns]). Security design patterns can interact in surprising ways that break security. The architecture analysis process should be applied even when vetted design patterns are in standard use.

[AA3.3: 2] Make the SSG available as an AA resource or mentor.

To build an architecture analysis capability outside of the SSG, the SSG advertises itself as a resource or mentor for teams who ask for help using the AA process (see [AA2.1 Define and use AA process]) to conduct their own design review. The SSG will answer architecture analysis questions during office hours and, in some cases, might assign someone to sit with the architect for the duration of the analysis. In the case of high-risk software, the SSG plays a more active mentorship role in applying the AA process.