What is SABSA Enterprise Security Architecture and why should you care ?
Those who work and have conversations with me, eventually hear me mutter the words “SABSA” at some point in time. It’s no secret I’m a huge fan of the SABSA framework but even among security professionals and though the framework has been around since 1996 (though evolved since), it doesn’t seem to be widely known.
And it’s a shame, because it’s a brilliant framework which ensures 2 main things:
- Completeness and justification for all components of your Enterprise Security architecture
- No hand-waving nor personal/professional bias towards what your security should look like
This blog post isn’t meant to be a thorough description of SABSA, but more an introductory view to what it is, what it includes and what it can do for you.
What is SABSA ?
SABSA is an Enterprise Security Architecture Framework. It stands for “Sherwood Applied Business Security Architecture” as it was first developed by John Sherwood.
The concept of architecture as the means by which we integrate different solutions and approaches to differing and complex needs, and provides a mechanism to manage such complexity.
Where SABSA differs from other approaches, is that it defines a conceptual layered model which enables the provision of an holistic, strategic architectural approach as opposed to the more typically seen application of technology and process stand-alone and point solutions to tactical security objectives. For those familiar with, it also leverages the Zachman Framework and is compatible with TOGAF, ISO 27001, Agile and other methodologies.
SABSA is the only approach I’m personally aware of (happy to be told there are others) which is effectively “business-driven” and “business-led”, and it is also the only approach I’m aware that aims to architect on both Control objectives (which is the more common approach to security, ie protecting your passwords or our web servers with hardening) but also Enablement objectives (how security can help the organisation be perceived as competent and having an appropriate time to market, as examples).
In the words of John Sherwood himself: “Architecture means taking a holistic, enterprise-wide view, and creating principles, policies and standards by which the system will be designed and built […] [ensuring] consistency of the design approach across a large complex system.”
This view is inspired by Kipling’s “I Keep Six Honest Serving Men” poem which you can find here
What does SABSA look like ?
SABSA ensures that different Views of security are taken in consideration through the layered model, as different stakeholders will need to be differently informed about what it means to them, whilst still allowing for traceability across the stack.
These related and layered requirements are then mapped through the chain to ensure architectural traceability and justification for the elements of the architecture.
This is related to a few other tables on how to overlay these concepts.
This is more the conceptual part on how SABSA ties everything together, however the last layer (Management Architecture) has it’s own Matrix which most security professionals will be more accustomed to in terms of artefacts or deliverables from security work.
So this this is why SABSA is so powerful. It ensures a) you don’t oversee aspects of your enterprise architecture and b) it enables traceability and the association of metrics to measure yourself against them.
In more practical terms on how to implement and visualise application of SABSA, the “SABSA mappings” as they’re sometimes referred to can be used. Here you can see an example I built:
What can SABSA do for you ?
That will depend on your preferred view, or where you would mostly contribute to in the stack.
For me, as an independent consultant and security architect, it allows to capture everyone’s input in a traceable way that I can associate the information between them.
If I’m talking to an exec or senior leader, I can focus on understanding the business attributes which are important to them (sample list below) and focus the conversation of any gaps to the business attributes they relate to. For instance, using my example mappings if the organisation has an ‘RBAC’ gap, I have a traceability in place to know I should frame it back to the exec as an issue relating to ‘reputability’ as we’re not ‘protecting’ the organisation by ensure access is appropriately ‘authenticated’.
In the same way, after understanding what are Exec control and enablement objectives, I can talk with Technical Managers or developers about their current capabilities and what’s missing to enact the business attributes important to the exec team, and both ensure completeness of the security architecture as well as the justification for the use of each component.
For me, more than anything, it allows me to focus my message according to “stakeholder view” I’m having a conversation with and that it stays relevant and focused for him/her, and also provide a mechanism to understand what’s missing and what needs to be worked on.
One of its main benefits is using SABSA as a communication mechanism, and open dialogue for discussion of options with stakeholders.
What I mean by this, is that instead of focusing on “you should implement this technology to achieve security goal X”, I can now engage in conversation with Engineers and Development teams as “There are these 3 mechanisms we should be using to assure business attribute Y. What’s the most efficient way to deploy a component to meet that requirement?”
Strategically, it is also a great way to identify duplication and bias in the security mechanisms and components used, to ensure consolidation of components and operational overhead related with it.
Closing thoughts
As I’m sure it was noted, I’m a big fan of SABSA as a framework due to everything it enables an organisation to map and provide a solution for.
I’d say it’s unfortunate it’s not an open standard so that hopefully more organisations and security professionals would become acquainted with it, and is currently mostly the space of high paid management consultants, but hopefully adoption will continue to grow and, within the limits of the licence imposed by SABSA institute, I shall try and do my bit in writing about its benefits.
Hope it helps
Mario Platt