UNCENSORED Security “Salvation” for Struggling SABSA® Security Architects

A spinning view of the SABSA® Matrix overplayed on a graphic inspired by the movie

Dear Fellow Security Architect:

Like myself, you may have found one of the most frustrating things about being a security architect is trying to define what true enterprise security architecture is and to explain the value it will provide to your organization. And, after you’ve managed to finally solve that seemingly insurmountable problem, the very next problem you face…

…is how to actually go about delivering what you’ve promised.

In the course of trying to implement a viable security architecture program, you’ve probably seen SABSA—one of only 3 potential frameworks and methodologies focused specifically on building, communicating and leveraging enterprise security architectures.

Now, if you don’t already know SABSA, then you can probably stop reading right here. The rest of what I’m about to say probably won’t make any sense to you. Because you won’t have experienced first-hand the pain and frustration of wrapping your head around the best way to put nearly 40 hours of intense, in-person training to work in your organization…

…trying to justify the value of spending several thousand dollars and an entire week out of the office, “on holiday” sweating bullets to make sure you’ll be able to pass the grueling, 4-hour certification examination…

…and often inadvertently “force-feeding” security architecture to everyone in a way that causes organizational shockwaves, turf-wars and competing claims of either:

“We already do that,” or

“That kind of architecture doesn’t belong in security,” when…

…you’ve not only bought into the promises of what adopting a true, end-to-end view of security architecture that integrates and aligns with the business will bring…

…but you also know that at least half – if not many more – of the core challenges you and the rest of your security team face every day could be solved…

…if only there was a practical and pragmatic way to realize the the promises of enterprise security architecture pounded into you head…

…for the entirety of the official SABSA Foundation training program…

…and on each of the 608, acid-free pages of the revered (and sometimes reviled) “Blue Book” that first introduced the complete approach in 2005.

If you don’t “get” the promise of SABSA, you wouldn’t have ever had these problems.

However, you might’ve also come away from SABSA with a few mistaken ideas about what it is and how it works that can completely invalidate and undermine its potential to transform the way you and your team deliver security to the business.

Maybe you’ve decided that SABSA’s just too academic and “utopian” to ever implement in any organization—unless you have an army of security staff constantly creating and updating documentation…

…that will be obsolete by the time it’s complete…

…and that will never be used by anyone else beyond the core group of “SABSA zealots” committed to creating it in the first place.

Or, maybe…just maybe…you’ve picked up on one of the catch-phrases of the Foundation training: that the tools and techniques of SABSA as an architecture framework must be compatible with any methodology or framework, now and in the future…

…and taken it to mean that all SABSA actually provides is a “pick-a-mix” of tactics you can “lift and shift” from SABSA to TOGAF®…or ITIL®…or Agile…or DevOps…or even that “home grown” SDLC-ish beastie you suffer through every day trying valiantly to “shift security left”…

…instead of being overwhelmed in an onslaught of “security assurance” and “stage gate security” activities where you can never come out ahead, because…

…you’re always involved too late…

…you’re never given the time it would really take to do the job properly…

…and you’re constantly put in the unenviable position of being “Project Killer” and “The Department of NO”…

…when all you’d really like to do is be able to define a clear picture of what the security controls of the organization SHOULD be based on:

alignment with what the business is and what it’s tying to accomplish, and
a defensible estimation of the priorities and risk exposures of the true information and cyber security threats your organization faces today and in the foreseeable future.

And yet, after a few rounds of attempted Attributes Taxonomies and Two-way Traceability…

…you still find yourself not seeing the promised benefits AND you just feel like you’ve made your life more complicated, rather than moving towards a repeatable and reliable process that would allow you to once again remember you really DO enjoy being a security architect.

So, if you find yourself in one of those 3 camps, you’ve probably decided that it’s just not worth it, and…

You’ve Written Off SABSA Completely.

The rest of what I have to say here today certainly isn’t for you. Neither is it for a particular type of SABSA security architect – the “true believer” – who isn’t open to an alternative way to look at the core cannon of SABSA that more easily enables you to adopt and apply it—either individually or even across the whole of your organization.

The rest of what I have to say is for only those people who already know SABSA…who believe in it’s potential…who’ve tried to adopt it in their own work and their organizations…

…and who, for whatever reason, just haven’t been able to make it click. The people who find themselves focusing on the artifacts and cell contents of the SABSA Architecture Matrix, tying to make sense of it all…

…and who might feel as if – despite their best efforts – they’re one of the 7 blind men confronted with the elephant of SABSA…

…because they just can’t figure out a way to unlock the potential promised by a true, enterprise-wide approach to security architecture. To those people who are tired of killing snakes, being tied in knots and hitting the wall with your enterprise security architecture efforts because you just can’t crack it…

…I humbly offer an alternative take. Something that might just be the “salvation” that enables the blind architect to lift the veil of SABSA and see it clearly for the very first time.

My name is Andrew Townley, and I’m a practicing enterprise security architect who’s been using SABSA regularly for the past 15 years with organizations of all sizes around the world to help them move past all these problems and refocus on the essential value of security architecture and help them successfully apply the SABSA methodology and framework to do it.

If you’re someone who still believes in SABSA’s potential but hasn’t yet been able to practice it themselves, what I offer you is an opportunity to crawl inside the head of an experienced SABSA architect and take a fresh look at SABSA, and, in particular, the SABSA Architecture Framework so that you will…

Never Again Get Lost In The Matrix.

Because, in effect, that’s the biggest problem I hear people like you are having when they talk about their own experience with SABSA. You can easily get so focused on the details of the Matrix…

…that the value you’re hoping to deliver by actually producing an enterprise security architect gets somehow trapped in the 66 cells of the Architecture Matrix and its complementary companion overly, the Management Matrix.

While the structure of the Architecture Matrix provides a good way to enumerate the scope and completeness of the SABSA method, where it can suck you in is that it’s giving you a step-by-step approach and roadmap for successfully implementing the methodology. All you need to do is start at the top left, and then you just work your way through, layer-by-layer until suddenly, out of the ether, a fully-formed and perfectly aligned enterprise security architecture springs into being.

The reality is, it just doesn’t work that way. And, for the first time ever, I’ve put together a cell-by-cell walkthrough of the SABSA Architecture Matrix that – unlike the structure of the Foundation materials I presented to over 200 aspiring security architects win the past – relentlessly links them to what, after thousands of hours of focused security architecture practice, I’ve identified as...

The 3 Core Concepts of SABSA.

At over 600 pages and the better part of week to explain at a Foundational level, SABSA can easily appear overwhelmingly heavy and complex—descriptions I also often hear in the regular, weekly chats I have with qualified SABSA security architects from around the world. However, the blindingly obvious insight, once it’s explained to you, is that SABSA is actually very simple. It’s all about just 3 fundamental concepts: the Attribute, Domains and the SABSA Governance Model.

All the rest of the words – in either Foundation or the book – are really either about

how to identify, define and document those concepts, and
how to use them to ensure you’re delivering prioritized, value-driven security to the business.

It’s all just one thing. And the information in this program use the biggest hang-up and heartache of putting SABSA to work, the SABSA Architecture Matrix – as the basis for explaining the way SABSA actually works in practice, and why the information inside might be just the thing to…

…get clarity on where you’re getting stuck…

…figure out how to focus on what’s really important about SABSA when you use it to build security architectures…

…and leverage my own experience personally applying SABSA in the field, in the classroom, and helping hundreds of people unlock the power and potential of SABSA’s approach to developing business-driven security architectures so you race to the head of the class and avoid many of the pitfalls, traps and frustration faced by a large number of people who believe in the potential of SABSA…

…and yet still struggle to put it to work for them in their own organizations.

The tips, secrets and practical advice in this program have previously only been available to either students in our flagship learning experience, Building Effective Security Architectures, or CISOs, security leaders and architects I work with every week as part of Archistry’s intensive Effective Security Leadership coaching and mentoring program. Either of these requires an investment between $5,000 to over $100,000, depending on the program, but as of today, I’ve now pulled out “all the good bits” and collected them in one place to give you access to a one-of-a-kind “brain dump” of what I know about SABSA and putting it in practice inside global organizations across a dozen industries to transform the effectiveness of their entire security program.

And this information is raw, uncensored and – even occasionally – contradicts the “official” SABSA positioning and recommendations you’ve probably heard before. However, what I can tell you is that this is exactly how I’d explain SABSA today if I was still teaching the official SABSA Foundation program, because my goal was always to make sure anyone in my sessions had practical, actionable advice they could use the Monday following the course to start applying SABSA right away.

Here’s some of what you’ll discover as part of this unique audio course delivered directly to your phone via the brand-new Archistry Learning mobile app:

The “head-wreaking” power SABSA delivers as an architecture framework (and which starkly exposes the ugly, compromise-driven, design-by-committee monsters many other frameworks really truly are)
An “obvious” truth about architecture in general that many practicing security architects simply don’t know
Why it doesn’t really matter what architecture elements go with what architecture layer within a SABSA phase—as long as you’re clear about what you’re trying to find
What “governance” actually means from a security perspective (which probably isn’t the definition you know, but will probably be “obvious” once you hear it)
How to build effective attribute metrics, measurements and performance targets
How to identify the elements that should determine the scope and objectives of a SABSA architecture iteration
Why SABSA’s domain concept is not just critical; it’s fundamental to being able to create effective security architectures
What the Contextual Architecture is and how it relates to the organization—and security
A core “secret" of SABSA that most people don’t know behind the reason SABSA is much more than just a “toolbox” of techniques and artifacts organized by the Matrix
How “doing what you know” when you’re analyzing your organization’s business context for its operating locations can get you overwhelmed, exhausted and completely off-track from the actual locations that matter most
The little-known reason why RACI charts and COBIT® aren’t actually the best place to start when trying to understand the governance relationships of your organization
How to reliably identify the worlds of our customers we need to understand (including the rationale behind making this imperative the 2nd Principle of The Agile Security System™)
Why no matter what you might already think, the Conceptual Architecture can’t be all about you (if it is, it will fail in delivering on its intended purpose)
The crucial role of the Conceptual Architecture in communicating the value of the work we do in security to our security customers
A common reason many SABSA adoption efforts fail (and how to make sure yours doesn’t)
How to move beyond multi-tiered attributes in SABSA (It’s something more powerful, more useful and which ultimately leads to better security)
Overcoming the main problem technical security people have with accurately identifying the processes of the organization
The blueprint for conducting a risk assessment during SABSA’s Design phase (and how it does – and does not – relate to either of the two potential risk assessment types you might do during Strategy & Planning)
A magical “get out of jail card” that allows you to ignore attribute performance metrics (along with the price you pay for bucking canonical SABSA doctrine if you do it)
Describing the fundamental mechanism SABSA provides that virtually guarantees you don’t have to build “big bang” security architectures!
Don’t believe me? Then let’s “unpack” this item a bit more:In one case I heard about firsthand directly from the lead architect, they invested a 2-year effort applying SABSA just to develop a SABSA Attributes Profile. That’s right…2 whole YEARS just to complete of the major elements on which the rest of your security architecture depends. Who has time for that?
Unfortunately, many people think that you can’t “do SABSA” until you’ve analyzed the entirety of the whole organization, exhaustively interviewed all the stakeholders – those people who probably aren’t ready to talk to you anyway – and then spend days documenting and analyzing the results of all this work before you have anything of value.
The reality is…this just isn’t true.

It’s not how SABSA works.

And this mechanism is the rarely-used way you can consistently build architecture without being overwhelmed, you can deliver value quickly, and you can finally deliver all the promises of SABSA you originally wanted to believe when you first heard about it or you attended Foundation. It’s the ultimate, critical mechanism required to build security architectures that won’t ever gather dust on a shelf—virtual or physical.
Which “what” do we mean by an “asset” (and the trick to reliably recognizing them once we know what to look for)
The reason I define attributes and domains as part of the Contextual Architecture (much to the surprise of David Lynas)
An essential prerequisite to being able to use SABSA effectively in your security program that not only do most people don’t do—they don’t even realize it’s possible, let alone necessary!
Alternative techniques you can use beyond PESTELIM to determine potential business risks your security architecture needs to consider
A way of thinking that helps us avoid “architecture indigestion”
What makes our security customers feel inclined to “help” us identify our information and cybersecurity risks? Easy. It’s because we’ve historically been too focused on dealing with controls rather than risks.
The single, most important thing to find when you’re looking for the definition of “business value” in your security architecture
The ultimate key to not “getting lost in the matrix” when you’re building SABSA architectures
A core “secret" of SABSA that most people don’t know behind the reason SABSA is much more than just a “toolbox” of techniques and artifacts organized by the Matrix
Why you don’t have to have something in all 66 cells of the SABSA matrix to deliver value with you security architecture
The reason governance is one of the things often break down—both in security, and even in business
A highly-controversial opinion as to why a large potion of the SABSA Architecture Matrix is “effectively commentary” once you’re clear about the purpose of security architecture
The “foolproof” strategy for developing effective security architectures
Why you only really two of the RACI roles to document governance relationships (including which ones they are and the keys to accurately assigning them)
The trouble with taking “business requirements” at face value when developing you security architecture
Why we really care about accurately relying the right locations during the creation of the Contextual architecture
Establishing effective governance in both “black box” and “grey box” governance models (and how to determine which one will work for you)
Never again be “straight-jacketed” into developing someone else’s architecture (because, after all, have they done the work to understand the nuances and needs of your individual organization?)
The exact approach necessary to plan a business risk assessment when developing your SABSA security architectures (including identifying what “assets” should be assessed and how to prioritize them)
Why you must take Emerson’s essay on Compensation with a proverbial “grain of salt” when thinking about your approach to doing risk assessments with SABSA or ISO31000.
Maybe you’re surprised to see a reference to Ralph Waldo Emerson mixed in with names like Sherwood, Lynas and Zachman…but you shouldn't be. Because the essence of what he wrote about in 1841 was “an inevitable dulasim” that bisected all of nature into two sides representing the likes of good and evil and gain and loss.
While I’m a big fan of Emerson, and there’s much wisdom in his essay, when it comes to looking at the world of our organizations, the objectives they seek and what might get in the way of obtaining them, it’s easy – and, in fact encouraged by both SABSA doctrine and ISO31000 that we should be always…

Taking a balanced view of risk.

And yet, when it comes right down to it, it’s even wiser than the advice in Emerson’s essay to resist the temptation of the “easy” yin and yang of risk and opportunity, and take a much closer look at whether “finding a balance” is really the best use of our time and architecture energy.
The keys to unlocking the definition of value in your security architecture (and exactly why it isn’t the cell labeled “Business Value”)
Why approaching the development of security architecture with a “traditional” reductionist mindset isn’t going to get you the results you really want
Understanding the true scope of our role as security architects (and how SABSA – applied properly – almost guarantees we don’t get it wrong)
Why the order of the interrogative columns of the SABSA matrix is different than in the Zachman Framework
The importance of being clear on your definition of a “capability” (and why our EA friends might be a bit confused when we talk about SABSA attributes)
How to avoid this credibility KILLER when you’re developing security architectures
6 value indicators you can use as “exit criteria” to evaluate whether the work you’ve done developing the Contextual and Conceptual architectures has been worthwhile
Wondering how many times you need to define your own Vitality Framework? Easy. You only do it once—unless something relevant in your organization makes it necessary to revisit in the future
Why basing your Conceptual Architecture on your organizational structure is a DEADLY mistake to be avoided at all costs
The right way to deal with “domain pivots” once the pop up in your domain models
The reason the labels on the SABSA Architecture matrix at times seem a bit vague and difficult to clearly define (especially based on what you know about the way the Architecture and the Management matrices are related)
Why the WHERE column of the Conceptual Architecture actually defines a “content free” cell in the Architecture Matrix (and a bit of commentary on what it’s doing there instead)
A frequently forgotten – yet fundamental – truth about SABSA that can immensely simplify and streamline your entire security program
The only “foolproof” way to understand the inherent relationships between SABSA attributes that would otherwise be hidden deep in the bowels of your security architecture documentation
Why the Baseline Perspectives™ of The Agile Security System™ give you a valid “shortcut” during the definition of your SABSA security architectures
Understanding the source of where our inventory of threats and opportunities for any SABSA iteration should come from
When the lure of “cute, nice and tidy” gets in the way of doing what needs to be done to develop effective security architecture (and how to avoid it happening to you)
How SABSA attributes drive architecture implementation decisions
The necessity of learning how to read – and listen – differently than you do today (but, depending on where you grew up, it might be harder for some than it is for others)
The case for NEVER using the sample standard SABSA Attribute Taxonomy from the Blue Book and Foundation materials
Let’s talk about this one a bit more, because it’s one of my personal pet peeves about the way people try and apply SABSA in practice, and this isn’t something that I put in the course.
When I learned Foundation from David many years ago, he explicitly told us that the Attributes of SABSA were a “happy accident” that came about entirely because of their publisher saying the book wasn’t technical enough. Based on David’s example, that’s what I said to the 200+ students I thought Foundation to myself over the next several years.
And yet…almost every “average Joe” person I meet who’s trying to apply SABSA on their own – whether they've been through Foundation or not – invariably wants to start borrowing the attributes from the sample taxonomy so they don’t have to go through the trouble of speaking with stakeholders and engineering their own. It isn’t a good way to do it – especially if you’re using it as a crutch – and you’re much better off…

Engineering your own damn attributes!

How organizational politics may hamstring one of the most important aspects of SABSA if you let it (and once you know about this problem, you can take whatever steps are necessary to prevent it from happening to you)
An important criteria for knowing you have the right processes (and even more tools you can use to find them)
How to identify the real customers of your security architecture (and the reason their approval is the only one that matters)
The surprising truth about domains, locations and people only experienced SABSA practitioners will know (but beware, it’ll almost be guaranteed to start arguments with any SABSA “purists” out there stuck in the Matrix themselves)
A foolproof way to identify and prioritize the governance relationships that matter most to your SABSA architecture iterations
The truth behind why your organizational chart doesn’t really tell you much about the governance relationships that matter for security (because it’s way beyond thinking in terms of “matrix” management)
How you figure out where you’re supposed to stop with your architecture development efforts (so you don’t get stuck doing a bunch of work nobody cares about and killing your security architecture program dead in its tracks)
The reason 50% of the “artifacts” in the TIME column of the Conceptual Architecture aren’t really artifacts at all (so, once you realize that, you’re going to need the following tips to make sure you can integrate SABSA successfully into you organization’s existing security delivery approach)
A step-by-step roadmap for identifying candidate domains you can rely on every time you use it
How to do a risk assessment even when you don’t have the “official” support of any designated risk function in your organization
The relationship between speed and architecture that must NEVER be violated
Unlocking the true purpose of attributes, domains and the governance model and how they work together to focus your entire security program
An end-to-end overview of what the end result of a fully-engineered strategy for process assurance is going to look like (again providing further proof that it’s all to easy to take the rigidity of the Matrix way too far in practice)
How to determine your own approach to process decomposition (regardless of whether you’re using a “canned” process framework or not)
The basis for my “heretical” and outright denial that we should always “take a balanced view of risk” (and why it’s a helluva lot harder to do correctly than you might initially think!)
Why the definition of a domain in SABSA is “a set of elements subject to a common security policy”
A catastrophic mistake people make when trying to apply SABSA that can result in you getting caught in the Matrix long enough to kill any support you might have for your security architecture program
How to correctly establish and define your approach for security assurance when you use SABSA in your security program
The only two roles you ever need to identify if you want a governance model you can actually understand, clearly communicate and effectively manage
How to identify the “exit criteria” for dealing with business risks during any SABSA architecture iteration
How the Conceptual Architecture provides an MIT-approved bridge to effectively engaging with our security customers (and doesn’t hurt us when we need to compare notes with our Enterprise Architecture colleagues either)
A fundamental relationship that simplifies SABSA’s defined governance roles
I mean, what could be simpler, right? There’s already the Owner, Trustee and Custodian roles, and they’re pretty straightforward as the individual who owns the domain, the designated Policy Authority other than the domain owner and the individual who does their work according to the domain’s established security policy.
Oh, then there's the Assurance – Compliance and the Assurance - Audit roles, which happen in different parts of the SABSA lifecycle, but might well be delivered by the same people using the same controls and tools...

And then, the RACI walked into the room…

…and all hell kinda breaks loose. Even though the use of RACI is pretty well explained and established, people still get it wrong, so in the work I’ve done over the years, I’ve found it easier to stick to something slightly more familiar, which is, in fact, also well covered in the core materials I used to teach in Foundation too.
Answering the potentially vexing question as to who our security customers actually are—with or without using SABSA
The primary reason why it’s not possible to “fill in” the SABSA matrix cell-by-cell and row-by-row if your objective is to create security architecture (and what your real approach should be)
Clarifying the distinctions between “Business Drivers” and Control & Enablement Objectives (including when you should be trying to create each one, what they’re for, and how they relate to each other)
4 different strategies to identify what your organization does (so we can focus our security architecture in the right place and make sure we connect with our stakeholders)
The most important thing to keep in mind as you develop your Conceptual security architecture using SABSA (and how you can inadvertently screw it up by forgetting this point)
When flipping burgers at McDonalds is a better use of your time than trying to apply SABSA in your organization
The “secret” relationship between people and locations baked into the SABSA matrix (which you’ll have a hard time finding if you’ve your nose stuck in only one cell at a time)
Why it’s ok for your security architecture to not necessarily line up with the structure of your security policy documentation
How the concept of “candidate” domains and attributes can help you build better security architectures (including what they are, what they’re for and when you need them)
John Zachman’s “secret” for developing stable architectures (that you can still apply even if you’ve never looked at the Zachman Framework in your entire life)
A fundamental and powerful aspect of domains that enable you to dramatically simplify your security architecture efforts (that most people tend to ignore—if they’re aware of it at all)
Why you need to think of attribute relationships in terms of graphs, not trees (and how this realization was the birth of the Attribute Patterns concept of the Cybersecurity Edition™ of the Archistry Execution Framework™)
The single greatest reason why “everything just works out” if you apply SABSA correctly (because if you don’t get this point, no matter what you do, SABSA will never live up to its full potential in your organization)
What to do with the output of your formal security risk assessments (so that you completely understand how they fit in with your architecture development efforts and you can provide some helpful “suggestions” and feedback to the risk team that will make everyone’s life easier AND do a better job keeping the organization safe)
The “rule of thumb” guideline I use in my own architecture work – and teach all my architecture coaching and mentoring clients – that helps streamline the “dreaded” process of defining metrics and performance targets for your SABSA attributes
The shocking reason the WHY cell in the Contextual Architecture of SABSA is often effectively a no-op—despite us telling you during foundation that this is the most important cell in the entire SABSA Architecture Matrix!
A priceless summary of the essential variations in 15 years’ worth of real-world SABSA Conceptual Architecture development
The key differences between wisdom, knowledge, information and data that’s baked in to the Assets column of the SABSA Matrix
Why I don’t agree with the common use of SABSA attributes as “proxy assets” (and why the concept of a “proxy asset” goes against the whole purpose of building a business-driven security architecture in the first place)
What it means to use SABSA for “architecture archaeology” and what that implies for the scope and objectives of you resulting architecture
In case “architecture archaeology” is a new term for you, here’s what it really means:
Architecture archaeology is the process of discovering an existing architecture, wherever it happens to be hiding. And the absolute truth about architecture is…

Everything has an architecture.

The question is whether it’s been exposed, analyzed, documented…or even planned. Far too many aspects of our organizations – including our technology landscape and our security controls have been allowed to “grow organically.” And when that happens, if we’re the ones tasked with keeping the lights on and everyone safe, then we have no choice but to roll up our sleeves, assemble our crew and dive in to the unknown mass of whatever it is we’re supposed to manage…
…only able to return once we’ve been able to organize and describe it enough that we’re confident we understand how it works and how it fits into the rest of the world.
Why many people are “missing the point” when they’re developing security architecture in the first place (because if you’re doing it for any other reason, you’ll be wasting everyone’s time—especially yours)
18 concrete examples of business time aspects you can potentially identify during your context analysis that will give you ideas, extend your thinking and help make sure you don’t miss anything important
A unique, 30-second summary of not only the entire purpose of SABSA, but also how it forever binds Governance, Risk and Assurance together using the glue of security architecture
How risk guides the decisions we make about the structure and content of our Conceptual Architecture
The cell where you start defining your candidate domains (and why you can’t possibly wait until you “get to” the WHERE column of SABSA’s Contextual Architecture)
Why you can’t screw up RACI roles if you understand the fundamentals of SABSA domains (because just like there’s only one way to Rock according to Sammy Hagar, there’s only one way to properly assign RACI roles)
The WORST knowledge gap you can have when you’re attempting to identify the temporal aspects of your organization (including why it’s so important for rooting out the “sneaky” ones people might otherwise miss)
Measuring the risk exposure of domain elements
Why going around in circles during the development of security architecture doesn’t phase an experienced SABSA architect (and why they’d even be surprised if it wasn’t necessary)
4 things we don’t tell you about how to do SWOT analysis in SABSA during the Foundation course
The definition of SABSA’s 3 fundamental concepts (and how they underpin every single cell of the matrix—no matter what layer you’re dealing with)
The problem “matrix fixation” really indicates with your approach to security architecture (and why it’s a disease that afflicts far too many organizations—even those who’ve never even heard of SABSA!)
Why common classifications of SABSA attributes into “Business Attributes” and “Security Attributes” don’t really matter (so you can focus on the real problem you need to solve instead)
What it really takes to be able to “build security architecture in your head”—and do it almost automatically, without even realizing you're doing it
The secret to creating a SABSA domain model even your business stakeholders will love (including how to sink it so deep into their brain, they can’t help but want to talk to you about security architecture)
A concise definition of the true purpose of the SABSA matrix
A “hidden truth” of architecture many people don’t know (and when you don’t understand why this is important, you will forever struggle trying to organize and process the information you gather and create in your architecture efforts
The straightforward explanation of the purpose of the Conceptual Architecture (which won’t leave you wondering what the difference is between it and the Logical one)
The factors that actually determine the level of assurance required for any given architecture effort (which will also be inherited by the operations of the security controls being defined)
The power – and the limits – of using the Attribute Patterns technique to develop SABSA security architectures
How the SABSA Vitality Framework (a.k.a., the “Through-Life Risk Management Framework) relates to the activities of the SABSA lifecycle
The only legitimate way to establish the scope and objectives of a SABSA security architecture iteration
So, what’s the big deal about scope and objectives anyway?
Funnily enough, one of the minor variations between the 3 official versions of how you might choose to implement SABSA is where the scope and objectives of the architecture effort are established. In some of them, it’s a part of Govern & Communicate, and in others, it’s part of Strategy & Planning.
Figuring out where to put it is certainly a big problem, but an even bigger problem I see with the work I do helping people apply SABSA in practice is that they don’t give enough thought to what the scope and objectives of their architecture should be, so they have a really hard time…

Figuring out where to stop.

So, if you want to avoid being an Architecture Alice lost in the wonderland of the SABSA matrix, it’s pretty important to make sure you establish a clear scope and objectives for the work you do…and then figure out a way to stick to it as you get on with building your architecture.
2 important reasons why your organizational structure has no place in your Conceptual architecture models
A cold, unflinching truth about why focusing on technical security controls can never effectively manage our organizations information and cyber risks
The one thing you must identify and establish if you want to truly untangle and understand the complex governance structures of you organization (and how to reliably find it each and every time)
One of the changes to the Contextual Architecture layer of the SABSA matrix from 2018 that highlights why it’s a framework, not a collection of cells
What experienced SABSA architects do when identifying “business geography” (that automatically avoids this common mistake guaranteed to add unnecessary complexity into their models or their documentation)
Understanding what DOMAs are and their relationship to n-tier SABSA attributes
My “secret sauce” starting point for developing customer-specific security architectures (that goes beyond the Baseline Perspectives of The Agile Security System—even though I’m still using the fundamentals of the system)
The truth about the process of engineering security assurance (It isn’t nearly as hard as people think, but that doesn’t stop people from wanting to leave it out)
A dangerous assumption about Risk and Assurance you might be tempted to make when trying to apply SABSA (It’s one that will not only lead you astray, wasting your time—it will also make your work a lot harder)
What to do when you’re “in the zone” of defining your security performance metrics that will save you a lot of headaches down the line
The reason you’re actually talking about SABSA domains when you’re talking about your approach to protecting your organization’s business processes and activities (which, even though it’s fairly straightforward, people still seem to fail to recognize)
Some “edge case” examples where you SHOULD be using SABSA to build out your security architecture (and yet, most people don’t even think of some of these as justifying the architecture effort)
Why you’re going to need to learn to “bend” the Conceptual Architecture layer if you think “doing SABSA” is a left-to-right, top-to-bottom kind of framework
A clear definition of the purpose and content of a Trust Modeling Framework (which will be exactly the same, every time you build a security architecture with SABSA)
The ultimate purpose of the Trustee governance role in SABSA (and why it actually isn’t all that special in terms of basic interdomain relationships)
One of the overlooked, yet subtly critical reasons your architecture efforts might be stalled, have started “turf wars” with other “architecture” functions in the organization, and have consistently failed to prove they deliver value
How an “unfortunate choice in naming” can completely skew the perceptions of SABSA in your organization and limit you from not only getting the support to adopt it, but also in how widely you try to apply it
The right way to build your inventory of operational processes during security architecture development (a key insight is knowing why it’s actually more closely related to the development of the Contextual Architecture than it is to creating Conceptual Architecture artifacts)
What “security” really requires you to do—both architecturally and operationally (going well beyond the definition of “security is a property of something else”; this is the next thing you need to understand after you eventually accept the SABSA definition of security)
A slightly different take on the difference between a SABSA Attribute Taxonomy and the SABSA Attribute Profile (that should help eliminate any confusion you might have between the two once and for all)
Why your actual security governance and risk ownership relationships “work themselves out”—even, or sometimes in spite of, establishing a RACI chart
How you’re supposed to build a set of architecture views highlighting a specific set of interactions intended to communicate with a particular set of stakeholders
And a whole lot more, including…
How the 3 fundamental concepts of SABSA are used to ensure we don’t confuse the piss out of everybody with our security architecture artifacts… How to practically use SABSA’s stakeholder abstractions and integrate them into your architecture models in the right place… A few things you probably didn’t know about using SABSA’s Through Life Risk Management Framework in your application of SABSA…The pitfalls of attempting to build SABSA security architectures without actually establishing metrics, performance targets and a reliable way to measure them…Why I had to invent a practical definition for a Domain Framework, and what you need to do to make sure you have one that enables your security program… Why you MUST have performance targets associated with your security architecture…and, perhaps the single biggest revelation of all…
How to apply SABSA in an “iterative and cyclical manner” if you want to end up building security architectures (instead of playing Security Bingo with the cells of the SABSA Architecture Matrix)!

What You Get

The content of the program contains the better part of 3 hours of insights, tips and implementation guidance on how to apply SABSA in practice structured as 44 individual audio files. Each set of 7 lessons walks you completely through one of the 6 layers of SABSA’s Architecture Framework, and each cell is individually indexed for easy reference once you’ve listened to the program for the first time.

Here’s a layer-by-layer overview of each lesson:

Contextual Architecture Layer

This module of the program starts the walk through he 36 cells of the SABSA Architecture Matrix providing 15 years’ worth of tips, tricks and practical implementation guidance, including:

The role of "assets" in the Contextual Architecture and why it's fundamentally impossible to complete all 66 cells of the two SABSA matrices.
How to identify and integrate business risk scenarios into your security architectures.
One of the main challenges security architects face when tying to understand what the business does and provides 4 different ways to avoid being stuck with this problem.
Key issues with standard RACI charts and the challenges and solutions to understanding the real governance relationships in your organization.
Why of domains are pervasive in all aspects of the SABSA architecture model and some hard-won tips on how to not be overwhelmed when trying to analyze the physical, logical and virtual locations relevant to your security architecture.
The contextual time aspects that are relevant to security architecture, including providing a list of 18 potential temporal aspects you might not have previously considered.

Conceptual Architecture Layer

This module of the program does an in-depth walkthrough of the cells of the Conceptual Architecture, including:

The scope and purpose of the Conceptual Architecture and how it relates to the other architecture layers.
A bit of a rant about "proxy assets" and their value in SABSA security architectures before talking a lot about SABSA attributes and how they're used in your security architectures.
Why the motivational aspects potentially cause confusion when people try to use the matrix to build security architectures.
Lots of practical tips and advice on the nature of risk in SABSA and how to make intelligent decisions about risk assessments in your own work.
Advice on choosing your approach for dealing with the activities and processes in your organization and the right way to move forward once that decision has been made.
The different governance roles and the importance of focusing on the simplest relationships when defining your security and risk governance models.
The challenges with the description of this cell in the SABSA Matrix and gives you some practical guidance and advice for defining and using SABSA domains.
Attribute Profiling, metrics, SABSA's Key Risk Indicators and the decisions you need to make to integrate SABSA practice into your organization.

Logical Architecture Layer

This module of the program describes the scope and purpose of the Logical Architecture and how it relates to the other architecture layers, including:

The difference between Logical architecture assets and the assets in the other architecture layers, including why the distinction between information and data is so important.
Common points of confusion about the elements of Logical risk motivation and which ones you need to create at what times.
A surprising aspect of domains that can simplify your security analysis and architecture development.
One of the fundamental components of SABSA security architectures: Trust Relationships, including what they are, how they're built, and how they relate to the other layers and cells.
SABSA's domain concept and why it's so critical to everything else in SABSA.
What Calendars and Timetables really mean in the context of a Security Service-Oriented Architecture.

Physical Architecture Layer

This module of the program describes the scope and purpose of the Physical Architecture and how it relates to the other architecture layers, including:

A deep dive on data and how data is stored and managed within your organization—including the implications your decisions will have on your domain framework.
The different potential ways to carve up you organizational security policies, depending on what you inherit and which battles you ultimately want to fight.
The different potential ways to carve up you organizational security policies, depending on what you inherit and which battles you ultimately want to fight.
What's required to map (and protect) organizational process activity steps into the right areas of your security architecture.
The similarities and differences between the named artifacts of Logical People and those of the Logical Assets.
Shining the light on some of the murkier aspects of the infrastructure elements within the SABSA model so you know where they should go and what's required to demonstrate you protect them.
Guidance on not getting lost in the "wobbly-wobbly, timey-wimey" aspects of SABSA's physical architecture by potentially leveraging work you've already done.

Component Architecture Layer

This module of the program describes the scope and purpose of the Component Architecture and how it relates to the other architecture layers, including:

What it takes to enumerate the moving parts we need to manage at the Component layer to ensure that we maintain SABSA's traceability requirements.
Guidance on how the layered Policy Architecture content model works in practice, including the overriding rationale for doing it the way SABSA describes.
Tackling the concept of "architecture blueprints" head on, highlighting that they're not quite as neatly defined as we'd often prefer—especially in SABSA.
What it takes to "connect the dots" between the organization and your security architecture.
The often overlooked, critical aspects of the Component Configurations artifact.
Expansion on the guidance from the Physical layer, focusing on specific "gotchas" you need to look out for at the Component layer.

Management Architecture Layer

This module of the program describes the scope and purpose of the Management Architecture and how it relates to the other architecture layers, including:

How to map the activities within Delivery and Continuity management to their real homes within the 6 core SABSA activities.
The overall relationship of SABSA to risk management as a whole (and what this means to using the Matrix in practice to develop your security architectures).
The importance of integrating architecture into your chosen delivery models—even when you use more than one across the organization.
What's really involved in "relationship management" across an organization and how this relates to internal and external personnel and the organization's ability to address 3rd-party risks.
The integration of facilities and infrastructure management into an end-to-end, risk-based architecture lifecycle.
The implications of the SABSA Vitality Framework on the way the organization operates, including what you need to make sure exists from a security and architecture perspective to make sure it's all gonna work.
Some final thoughts on SABSA, security architecture and making it all work, highlighting a few key points from the rest of the program in the process that are essential not to forget.

Since the lessons in the program are delivered on our brand-new, Archistry Learning app that leverages the Learnistic™ platform, you also have access to features to allow you to control the playback speed of each individual lesson as well capturing your own, content-keyed notes as you’re listening to the content on your phone’s speaker, headphones or connected Bluetooth speakers. And, if you’re going to be subject to spotty or unreliable wireless connectivity, you can optionally download each of the lessons for offline use, so you truly can listen anytime or anywhere you happen to go.

And, along with the audio content, you get a full, 54-page PDF transcript of the program that you can either access from the phone, or share with other devices for immediate reference or, if absolutely necessary, print it out so you can make your own “old school” handwritten notes in the margins of the content on the printed page.

Just remember, that in order to access this program, you’ll need to download and activate the Archistry Learning App to you mobile phone. There is no other way. But once you also download the app, you’ll also get access to…

Additional Bonus App-only Content

A few of the “hidden gems” inside the additional content you receive when you download the app are:

Extended definitions of almost 100 security architecture concepts and terms as part of the Archistry Dictionary
A quick reference to the SABSA Architecture Layers to help you remember the differences in scope and content between each of them—especially for the ones you might not use as often
Exclusive access to the SABSA In the Car informal tips and insights about aspects of SABSA you might not have thought deeply about—and some expansions and additional commentary on some of the ideas, tips and insights included in the core program content itself
Access to the brand new Archistry TV channel which will provide a video “best of” for the most important and most requested topics and security leadership tips covered by some of my daily emails

Are You Ready To Escape The Matrix?

To get INSTANT access to these and a wealth of other practical insights and experience, all you need to do is click the button below.

And not only will you get full access to the program above, you’ll also get immediate access to extensive additional information and videos on SABSA, security architecture, security governance, risk management – and even a glossary of over 90 security terms – that can help you be a better architect starting today—all of which I recorded just for you.

Simply click the button below to get started.

Stay safe,

Andrew S. Townley signature

—
Andrew S. Townley
Archistry Chief Executive

LISTEN NOW!

P.S. The only way to access the interview – and all the other additional content I mentioned above – is using the brand new Archistry Learning app. Once your order is confirmed, you will be instantly provisioned with the interview in the app, but you must download it using only the instructions you will get following you purchase.

If you have any problems accessing your content, please direct them to apphelp@archistry.com

What People Are Saying About Andrew

A True Thought Leader

“Andrew is a highly skilled and experienced architect and consultant. He is innovative in his thinking and a true Thought Leader in his specialist domains of knowledge—in particular the management of risk. Andrew has also been a significant contributor to expanding the SABSA body of knowledge.”

John Sherwood – SABSA® Creator and Chief Architect

Makes Things Work

“Fabulous person to work with. Very engaging and insightful. Extremely good technical knowledge with ability to relate concepts together and overcome differing opinions. Makes things work.”

Kevin Howe-Patterson – Chief Architect, Nortel - Wireless Data Services

Clarity, Depth and Breadth

“Andrew was able to bring clarity and great depth of knowledge to the table. His breadth of thinking and understanding of the business and technical issues along with a clear and effective communication style were of great benefit.”

Doug Reynolds – Product Manager, MobileAware

Fabulous Consultant

“Andrew is a fabulous consultant and presenter that you simply enjoy listening to as he manages to develop highly sophisticated subjects in a very understandable way. His experience is actually surprising!”

Biljana Cerin, Director, Information Security and Compliance

Interesting, Useful and Full of Ideas

“Found the link to the July issue and read through this afternoon. Think you’ve done a really good job with it and especially around the objective of it being interesting, useful and full of ideas—which the newsletter easily met. Really looking forward to the September issue. If, in the unlikely event an August addition become available, I would happily purchase!”

Andy Smith – Security Architect

More Value Than Anything Out There

"As you have mentioned before, it always all about controls and frameworks. The gap between where the industry is and where we should be seems to be about 180 degrees. Whenever someone asks the question, 'should we have a framework to align business to security?' well they need to look at what Archistry offers. I refuse to pay for any other training class out there. No value after taking BESA, and it's the reason why I spend my money on Security Sanity instead. Absolutely more value there."

Tereston Bertrand – Enterprise Security Architect

A Source of Sanity

“I have been working flat out the last 2-3 weeks on a very detailed program. The one thing that has kept me sane has been your daily emails about the Archistry training. Keep those great emails coming!”

Shane Tully – Enterprise Security Architect

Compelled to Subscribe

"Reading your blogs and content I was rolling at some of the references you make. You write like the frustration of the past guides your fingers across the keys. I was compelled to subscribe to the newsletter."

Vince Nalin – Enterprise Security Architect

Thought-Provoking, Practical Ideas

"Your thought-provoking messages about security, leadership … are welcome. I enjoy reading them. There are many ideas which can be applied to the work, even within the limits of a heavily-regulated organization like my employer."

Helvi Salminen – Information Security Manager

LISTEN NOW!