Chapter 5. Architectural Risk Analysis

Chapter 5. Architectural Risk Analysis^[1]

^[1] Parts of this chapter appeared in original form in IEEE Security & Privacy magazine co-authored with Denis Verdon [Verdon and McGraw 2004].

Architecture is the learned game, correct and magnificent, of forms assembled in the light.

Le Corbusier

Design flaws account for 50% of security problems. You can't find design defects by staring at codea higher-level understanding is required. That's why architectural risk analysis plays an essential role in any solid software security program. By explicitly identifying risk, you can create a good general-purpose measure of software security, especially if you track risk over time. Because quantifying impact is a critical step in any risk-based approach, risk analysis is a natural way to tie technology issues and concerns directly to the business. A superior risk analysis explicitly links system-level concerns to probability and impact measures that matter to the organization building the software.

The security community is unanimous in proclaiming the importance of a risk-based approach to security. "Security is risk management" is a mantra oft repeated and yet strangely not well understood. Nomenclature remains a persistent problem in the security community. The term risk management is applied to everything from threat modeling and architectural risk analysis to large-scale activities tied up in processes such as RMF (see Chapter 2).

As I describe in Chapter 1, a continuous risk management process is a necessity. This chapter is not about continuous risk management, but it does assume that a base process like the RMF exists and is in place.^[2] By teasing apart architectural risk analysis (the critical software security best practice described here) and an overall RMF, we can begin to make better sense of software security risk.

^[2] All of the other touchpoint chapters make this same assumption.