Enterprise Security Architecture: A Business-Driven Approach

by John Sherwood, Andrew Clark, David Lynas

Security is too important to be left in the hands of just one department or employee―it’s a concern of an entire enterprise. Enterprise Security Architecture shows that having a comprehensive plan requires more than the purchase of security software―it requires a framework for developing and maintaining a system that is proactive. The book is based around the SABSA layered framework. It provides a structured approach to the steps and processes involved in developing security architectures. It also considers how some of the major business issues likely to be encountered can be resolved.

Genres: Technology

610 pages, Hardcover

First published September 1, 2004

Reviews

[Andre · Rating 3 out of 5]

Enterprise Security Architecture - A Business-Driven Approach (aka the SABSA “Blue Book”)

This book is old. First copywrited in 2005, and the edition I have was published in 2015. You can tell it’s pretty old just by the content, or in some cases lack of content. E.g. It refers to BS-7799 without mention of ISO-27001. This puts the content sometime before 2007. There is no mention of cloud computing, AI, etc. Not even SOA (service oriented architecture) or grid computing, what cloud computing was called before the term cloud computing was coined.

So if the book is effectively ancient from a technology perspective is it therefore worthless? Hardly. We still use ISO-27001 despite it originated back in 1995. We still use COBIT from 1996 (it’s been updated since then). How can I say this? Because it’s about the approach. An architectural approach is, and always will be relevant. I would go further and argue that in infosec ( cyber security ) today some of our problems stem from NOT approaching things architecturally.

So what is the SABSA (Sherwood Applied Business Security Architecture) approach?

Business-Driven Approach: The methodology emphasizes that security architecture must be derived from business requirements rather than technology considerations.

Layered Model: SABSA employs a six-layer model that mirrors traditional building architecture:

Contextual (Business View) - Focuses on business requirements
Conceptual (Architect’s View) - Defines principles and concepts
Logical (Designer’s View) - Creates logical security services
Physical (Builder’s View) - Specifies actual technology solutions
Component (Tradesman’s View) - Selects specific products
Service Management (Service Manager’s View) - Handles operations and maintenance

SABSA Matrix: The framework utilizes a 6×6 matrix that combines the horizontal layers with six vertical “architectural elements” answering:
What are you trying to do? (Assets)
Why are you doing it? (Motivation/Risk)
How are you doing it? (Process)
Who is involved? (People)
Where are you doing it? (Location)
When are you doing it? (Time)

Business Attributes Profile: At the heart of SABSA is a method to translate business requirements into standardized, measurable attributes that can be used to create metrics (KPIs) for gauging security performance. This is a critical conceptualization of the real business. It forms the core part of the Conceptual Security Architecture layer. By directly linking security requirements to business attributes, this profile ensures that security architecture remains firmly grounded in business value rather than technology considerations. I’ve seen some attempts to do this with value stream mappings, or business impact analyses.

Risk Management: SABSA takes a balanced approach to risk, emphasizing both threats (negative outcomes) and opportunities (positive outcomes). This mirrors the approach emphasized by ISO-27001 (and other frameworks) in that your information security program (not just the architecture) should be risk based. However the approach to risk management is very dated, leveraging qualitative approach from ISO-31000. This could be updated to incorporate more modern approaches such as FAIR.

Development Process & Lifecycle: The methodology outlines a development process that follows four stages: Strategy & Planning, Design, Implement, and Manage & Measure, creating a continuous improvement cycle. This is part of the two-way traceability that SABSA emphasizes. Top-down: ensures that no business requirement is overlooked or left unaddressed in the implementation. Bottom-Up: Every component, control, or mechanism can be traced upward to the business requirements that necessitate it.

Governance and Assurance: The framework includes models for governance and different levels of security assurance that can be customized based on business needs. The governance model also recognizes the importance of external entities such as regulators, stakeholders (BoD, senior mgmt), internal auditors and external auditors. Remember this is 2005; it’s way ahead of the NIST CSF which only added governance in it’s latest revision in 2024!

I do have my quibbles with this book. There is a lot of external referencing to things. There are sometimes entire chapters devoted to listing external references and providing a cursory summary of them. Granted this is done with an eye to how those references fit into the overall picture of the SABSA model. But it definitely feels like the authors were trying to pad the book so they could get it up to 600-ish pages so it could be a text book. This is especially unfortunate considering the “listicle” content has not aged particularly well. Some things are still around (ISO27001, COBIT) but some of it is no longer relevant (the Rainbow books and Common Criteria).

One other obvious shortcoming is that the approach in general is very waterfall-like. You do things “left to right” and while there are feedback loops they aren’t like what we’ve come to expect with Agile approaches used in today’s enterprises. I think you could adapt the SABSA approach to today’s Agile world, but you won’t find that in this book. Agile emerged about the same time as this book, but didn’t see widespread adoption until later in the 2000s. So it’s not reasonable to expect this book would incorporate Agile concepts.

Another obvious shortcoming is the lack of any reference to cloud computing. The forerunners of cloud computing (virtualization, grid computing, service oriented architecture) where all in place by 2005, but cloud computing, as such, was still in it’s infancy. It was certainly not something a business would seriously consider for deploying business critical applications. The complete lack of reference to cloud computing is understandable as it really wasn’t on the radar. However, because this is an architectural approach it can easily be adapted to the world of cloud computing.

The last omission is Zero Trust. Zero Trust has it’s origination with the Jericho Forum in the early days of cloud computing as deperimeterization i.e. that security domains should not rely upon network boundaries. It didn’t become a thing in it’s own right until 2010, well after the publication of this book. Can the approach be modified to incorporate Zero Trust? Yes. The Zero Trust approach maps nicely to the SABSA 6x6 matrix. Particularly since Zero Trust uses a similar Who, What, Where, Why, When, How model just like SABSA

So do I recommend reading this book? No, not cover to cover. I do recommend reading the introductory content that outlines the model. I also recommend reading the core of the model that addresses business attribute profiles. Rather you should read the excellent SABSA White Paper that condenses the essence of SABSA into 25 pages without much loss of fidelity.

Bottom line is the information security profession needs some more rigor in how we build things. SABSA, even as old as it is, is a very good start.

[Chris Mewett · Rating 4 out of 5]

A thorough and comprehensive treatment of the topic. There are a number of typographic and format errors in the text. Hopefully these will be corrected in the next edition.