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: 113] Perform security feature review.

Security-aware reviewers identify the security features in an application and its deployment configuration (authentication, access control, use of cryptography, etc.), then inspect the design and runtime parameters for problems that would cause these features to fail at their purpose or otherwise prove insufficient. For example, this kind of review would identify both a system that was subject to escalation of privilege attacks because of broken access control as well as a mobile application that incorrectly puts PII in local storage. In some cases, use of the firm’s secure-by-design components can streamline this process (see [SFD2.1 Leverage secure-by-design components and services]). Organizations often carry out security feature review with checklist-driven analysis and procedural threat modeling efforts. Many modern applications are no longer simply “3-tier” but instead involve components architected to interact across a variety of tiers: browser/endpoint, embedded, web, microservices, orchestration engines, deployment pipelines, third-party SaaS, and so on. Some of these environments might provide robust security feature sets, whereas others might have key capability gaps that require careful consideration, so organizations should not consider the applicability and correct use of security features in just one tier of the application but across all tiers that constitute the architecture and operational environment.

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

The organization can learn the benefits of design review by seeing real results for a few high-risk, high-profile applications. Reviewers must have some experience performing detailed design reviews and breaking the design under consideration, especially for new platforms or environments. Even if the SSG isn’t yet equipped to perform an in-depth architecture analysis (see [AA2.1 Define and use AA process]), smart people with an adversarial mindset can find important design problems. In all cases, a design review should produce a set of flaws and a plan to mitigate them. An organization can use consultants to do this work, but it should participate actively. Ad hoc review paradigms that rely heavily on expertise can be used here, but they don’t tend to scale in the long run. A review focused only on whether a software project has performed the right process steps won’t generate useful results about flaws. Note that a sufficiently robust design review process can’t be executed at CI/CD speed.

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

The SSG takes a lead role in AA by performing a design review to uncover flaws. Breaking down an architecture is enough of an art that the SSG must be proficient at it before it can turn the job over to architects, and proficiency requires practice. The SSG can’t be successful on its own, either; it will likely need help from architects or implementers to understand the design. With a clear design in hand, the SSG might be able to carry out the detailed review with a minimum of interaction with the project team. Over time, the responsibility for leading review efforts should shift toward software security architects. Approaches to AA evolve over time, so it’s wise to not expect to set a process and use it forever.

[AA1.4: 62] Use a risk methodology to rank applications.

To facilitate security feature and design review processes, the SSG or other assigned groups use a defined risk methodology, which might be implemented via questionnaire or similar method—whether manual or automated—to collect information about each application in order to assign a risk classification and associated prioritization. Information needed for an assignment might include, “Which programming languages is the application written in?” or “Who uses the application?” or “Is the application’s deployment software-orchestrated?” Typically, a qualified member of the application team provides the information, where the process should be short enough to take only a few minutes. Some teams might use automation to gather the necessary data. The SSG can use the answers to categorize the application as, for example, 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 useless.

Architecture Analysis Level 2

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

The SSG defines and documents a process for AA and applies it in the design reviews it conducts to find flaws. This process includes a standardized approach for thinking about attacks, vulnerabilities, and various security properties. In addition to the technical impact discussions, the process includes a focus on the associated risk, such as through frequency or probability analysis, that gives stakeholders the information necessary to make decisions. The process is defined well enough that people outside the SSG can carry it out. It’s important to document both the architecture under review and any security flaws uncovered, as well as risk information people can understand and use. Microsoft’s STRIDE and Synopsys’s ARA are examples of such a process, although even these two methodologies for AA have evolved greatly over time. Individual ad hoc approaches to AA don’t count as a defined process.

[AA2.2: 28] Standardize architectural descriptions.

Defined AA processes use an agreed-upon format to describe architecture, including a means for representing data flow. Combining a documented process along with standardized architecture descriptions will make AA tractable for people who aren’t security experts. High-level network diagrams, data flow, and authorization flows are always useful, 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, including useful metadata. Standardized icons that are consistently used in diagrams, templates, and whiteboard squiggles are especially useful, too.

Architecture Analysis Level 3

[AA3.1: 16] Have engineering teams lead AA process.

Engineering teams lead the AA process most of the time. This effort requires a well-understood and well-documented process (see [AA2.1 Define and use AA process]), although the SSG still might contribute to AA in an advisory capacity or under special circumstances. Even with a good process, consistency is difficult to attain because breaking architecture requires experience, so provide architects with SSG or outside expertise on novel issues. In any given organization, the identified engineering team might normally have responsibilities such as development, DevOps, cloud security, operations security, security architecture, or a variety of similar roles.

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

Failures identified during AA are fed back to engineering teams 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]). Cloud service providers have learned a lot about how their platforms and services fail to resist attack and have codified this experience into patterns for secure use. Organizations who heavily rely on these services might base their application-layer patterns on those building blocks provided by the cloud service provider (for example, AWS CloudFormation and Azure Blueprints) in making their own. Note that security design patterns can interact in surprising ways that break security, so the AA process should be applied even when vetted design patterns are in standard use.

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

To build an AA capability outside of the SSG, the SSG advertises itself as a resource or mentor for teams that ask for help in using the AA process (see [AA2.1 Define and use AA process]) to conduct their own design reviews. The SSG might answer AA 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 should play a more active mentorship role in applying the AA process.