logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo logo

SSDL Touchpoints: Architecture Analysis (AA)

The overall goal of the Architecture Analysis practice is quality control. Those performing architecture analysis must ensure the detection and correction of security flaws. Software architects must enforce adherence to standards and the reuse of approved security features.

SSDL TOUCHPOINTS: ARCHITECTURE ANALYSIS
Capturing software architecture diagrams, applying lists of risks and threats, adopting a process for review, building an assessment and remediation plan.
  Objective Activity Level
AA1.1 get started with AA perform security feature review 1
AA1.2 demonstrate value of AA with real data perform design review for high-risk applications
AA1.3 build internal capability on security architecture have SSG lead review efforts
AA1.4 have a lightweight approach to risk classification and prioritization use a risk questionnaire to rank applications
AA2.1 model objects define and use AA process 2
AA2.2 promote a common language for describing architecture standardize architectural descriptions (including data flow)
AA2.3 build capability organization-wide make SSG available as AA resource or mentor
AA3.1 build capabilities organization-wide have software architects lead review efforts 3
AA3.2 build proactive security architecture drive analysis results into standard architectural patterns (T: sec features/design)
one

AA Level 1: Perform risk-driven AA reviews, led by the SSG. The organization must provide a lightweight software risk classification. The SSG must begin leading architecture analysis efforts, particularly on high-risk applications, as a way to build internal capability and demonstrate value at the design level.

AA1.1

Perform security feature review. To get started with 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.) 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 system that stored unsalted password hashes would both be identified in this kind of review. At higher levels of maturity, this activity is eclipsed by a more thorough approach to architecture analysis not centered on features. In some cases, use of the firm's secure-by-design components can streamline this process.

AA1.2

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 architecture analysis and breaking the architecture being considered. 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 may be used here, though in the long run they do not scale.

AA1.3

Have SSG lead review efforts. The SSG takes a lead role in performing architecture analysis in order to begin building the organization's ability to uncover design flaws. Breaking an architecture is enough of an art that the SSG needs to 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—they will likely need help from the architects or implementers in order to understand the design. With a clear design in hand, the SSG might carry out the analysis with a minimum of interaction with the project team. At higher levels of maturity, the responsibility for leading review efforts shifts towards 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

Use a risk questionnaire to rank applications. To facilitate the architecture analysis and other 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 handle PII?" A qualified member of the application team completes the questionnaire. The questionnaire is short enough to be completed in a matter of hours. The SSG might use the answers to bucket the application as high, medium, or low risk. Because a risk questionnaire can be easy to game, it is important that some spot checking for validity and accuracy be put in place. An over-reliance on self-reporting or automation can render this activity impotent.

two

AA Level 2: Provide outreach on use of documented AA process. The SSG must facilitate organization-wide use of architecture analysis by making itself available as a resource and mentor. The SSG must define an architecture analysis process based on a common architecture description language and standard attack models.

AA2.1

Define and use AA process. The SSG defines and documents a process for performing architecture analysis and applies it in the design reviews it conducts. The process includes a standardized approach for thinking about attacks and security properties. 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 does not count as a defined process. Microsoft's STRIDE and Cigital's ARA are examples of such a 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 as many early publications are outdated and no longer apply.

AA2.2

Standardize architectural descriptions (including data flow). The organization uses 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. 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.

AA2.3

Make SSG available as AA resource or mentor. In order 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 conducting their own design review and proactively seek projects to get involved with. The SSG will answer architecture analysis questions during office hours and in some cases might assign someone to sit side-by-side with the architect for the duration of the analysis. In the case of high-risk applications or products, the SSG plays a more active mentorship role.

three

AA Level 3: Build review and remediation capability within the architecture group. Software architects must lead analysis efforts across the organization and must use analysis results to update and create standard architecture patterns that are secure.

AA3.1

Have software architects lead review efforts. Software architects throughout the organization lead the architecture analysis process most of the time. The SSG might still contribute to architecture analysis in an advisory capacity or under special circumstances. This activity requires a well understood and well documented architecture analysis process. Even in that case, consistency is very difficult to attain because breaking architectures requires so much experience.

AA3.2

Drive analysis results into standard architectural 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 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.