Desktop version

Home arrow Computer Science arrow Securing Systems Applied Security Architecture and Threat Models

Source

References

1. Ramachandran, J. (2002). Designing Security Architecture Solutions, p. 12. John Wiley & Sons.

eCommerce Website

In this chapter, we will pick up where we left off with the AppMaker Web-Sock-A- Rama web store architecture in Chapter 5. This architecture is reprised in Figure 6.1. We will factor the architecture further into its constituent parts. And we will examine the architecture from different views. We will also complete the ATASM process (Architecture, Threats, Attack Surfaces, Mitigations).

Decompose the System

Ultimately, the point of the architecture factoring exercise isn’t to document a perfect architecture view, but rather, to find those points in the system that are susceptible to likely attack. An appropriate set of defenses can be built from the attack surfaces. In addition, residual risk can be raised for appropriate decision making. As noted above, I will often have multiple views of the same architecture that I consult in order to threat model particular aspects of the system. Security is built at many levels, top-to-bottom, side-to-side, and front-to-back. Security is the architecture domain that interacts with every other domain; it is the “matrix” domain[1] and must permeate a system in order to build a defense-in-depth.

Looking at Figure 6.1, do you see anything missing? In the chapter about the ATASM process, there were several views of Web-Sock-A-Rama, adding data types, trust boundaries, and an attack surface. Still, in that series of discussions, it was intimated that there must be more; the discussion was purposely kept simple in order to concentrate on the process, in order not to get bogged down in attack details.

AppMaker web architecture

Figure 6.1 AppMaker web architecture.

Over the next series of figures, we will not proceed through the process stepwise, as we did in Chapter 5. Instead, we will proceed in a manner suggestive of an actual assessment. We will analyze what we see and then move on to greater detail. Always, we are looking for ATASM: architecture understanding, followed by credible attack vectors: those qualified threats whose methods have vulnerabilities exposed to them.

When an assessment proceeds stepwise, as in Chapter 5, we try to map a sufficient level of detail during the architecture phase. However, for complex systems found in the real world, a stepwise, strictly linear approach causes diagrams to be overly busy and difficult to understand. As you may see through the following discussions, it often makes more sense to perform a series of mini ATASM assessments, each focused on the level of detail in a particular architecture view showing some workable portion of the system. The mini assessments will often be recursive, as consideration of an attack surface then exposes more components through flows originating at the component under analysis. The summation of risks and requirements then pulls the results from the series of ATASM assessments together into a whole and complete analysis.

  • [1] I believe that I fi rst heard the phrase, “security is a matrix domain,” stated by my formerworkmate, Richard Puckett (Executive CTO, Enterprise & Security Architecture, at GE).
 
Source
Found a mistake? Please highlight the word and press Shift + Enter  
< Prev   CONTENTS   Next >

Related topics