“The value proposition of security architecture is simple. If you have a security architecture and you’re able to understand how that architecture enables and supports achieving the objectives that you want, it gives you, as the owner of those objectives, confidence that you’re really going to get them. If you do it with a methodology like SABSA, where you have traceability and measuring your security capabilities versus the risk exposure, then you can show with confidence that you are likely to obtain the result.”
– Andrew S. Townley, Chief Executive Officer Archistry Incorporated
In our last post we discussed the importance of using architecture frameworks. In this post we’ll take a closer look at the Sherwood Applied Business Security Architecture (SABSA).
The SABSA framework provides a generic framework for security architecture efforts. As with many enterprise architecture frameworks, the philosophy of the approach stems from the belief that security architectures, like enterprise architecture generally, should map efforts back to underlying business goals and harmonize (that is, be aware of and synthesize) views and viewpoints from different stakeholders in the organization.
It’s founded on the recognition that security in an enterprise – and thereby the security architectures that support the security function of that enterprise – do not exist as an end goal in and of themselves. Instead, they exist solely in service of – and to enable – the business. This means that any security effort should map directly and concretely to some business driver, goal, or end state desired by the business.
Originally discussed at the COMPSEC 96 conference in London (called SALSA at the time), the model has been subsequently expanded in more detail over time (see SALSA: A method for developing the enterprise security architecture and strategy in Computer & Security vol 15, Issue 6, John Sherwood).
For those familiar with the Zachman Framework of enterprise architecture, there can sometimes be confusion about the relationship between SABSA and the Zachman Framework. Similar to SABSA, the Zachman Framework is also a matrix-based ontology with an X axis that uses interrogatives (who, what, when, where, why, and how) and a Y axis that uses architectural layers. Despite these superficial similarities though, the two models evolved independently. The confusion that arises is unfortunate because it distracts from a thorough and utility-based understanding of the models. Meaning, despite a superficial similarity in the ontology, the approach and philosophy of each extend well beyond just the visualized ontology.
Below is a version of the SABSA Matrix for Security Architecture Development
Image Source: https://en.wikipedia.org/wiki/Sherwood_Applied_Business_Security_Architecture
The ontology is constructed as a matrix, with intersection points between a Y axis describing the layers of abstraction (from the most general to the most specific). These layers, from the most general to the most specific under SABSA, are as follows:
- Conceptual Security Architecture
- Contextual Security Architecture
- Logical Security Architecture
- Physical Security Architecture
- Component Security Architecture
Running throughout and in parallel to each layer is the “Security Service Management Architecture” view. This layer is different in that it applies to all layers rather than applying to only one.
The X axis contains the 6 basic interrogatives:
- What (Assets)
- Why (Motivation)
- How (Process)
- Who (People)
- Where (Location)
- When (Time)
Laid out as a grid, each cell of the grid contains a unique point that the architecture process must address to be complete. For example, at the intersection of the Y-axis “Logical Security Architecture” abstraction layer and the X-axis interrogative “What,” you find considerations unique to that intersection point (in this case, “Information Assets”) and supporting artifacts (in this case, “Inventory of Information Assets”). Page 16 of the SABSA whitepaper entitled “SABSA: Enterprise Security Architecture” by John Sherwood, Andy Clark, and David Lynas spells each out in thorough detail. You can find it at https://sabsa.org/white-paper-requests/.
Note that our book adheres quite closely to the SABSA model in the philosophy and approach that we take to security architecture. In fact, we’ve provided viewpoints and perspectives from many of the luminary voices from the SABSA community (for example, SABSA co-founders, authors, and “power users”) to provide perspective on the topics we’ll cover (you’ve seen a few of these already). The reason that we’ve done so is that the model is lightweight, easily understandable by all with the addition of a minimal time investment, and for the curious is accompanied by detailed supporting materials to supplement the excellent source material. From a process standpoint though, while we attempt to maintain compatibility with SABSA, we recognize that all SABSA source materials may not be readily available to all readers (some being available only commercially). As such, we refer to SABSA where appropriate, but where we can, we draw primarily on freely available sources.
Hope this helped give you a better understanding of how SABSA can help you with your cybersecurity architecture work. Next time we’ll cover Open Enterprise Security Architecture (O-ESA) from the Open Group.
This post is part of a series excerpted from our book: Practical Cybersecurity Architecture: A guide to creating and implementing robust designs for cybersecurity architects, ISBN-13 : 978-1838989927 available at Amazon and published by Packt.