Even if you’ve struggled to apply SABSA in practice for years, you can still

Start Building Business-Driven Security Architectures with SABSA® Today!

If you’ve ever sat in exasperation and wondered if it was humanly possible to apply SABSA® in an easy and practical way after being overwhelmed by all the official guidance and training out there, I can tell you for a fact:

You are not alone.

My name is Andrew S. Townley, and I’m a security architect. I’m also a security architect who uses SABSA each and every time I even so much as think about security architecture. And, nearly 20 years after I first met John Sherwood and discovered SABSA, I can tell you that at this point, I can create a SABSA security architecture of any organization, situation or problem…

…almost automatically, in my head, and without a whole lot of effort.

Of course, it wasn’t always this way. Like you, I thought I understood the basics of SABSA pretty easily, both after I read the “Blue Book” and going through the official Foundation training program.

But then the first time I actually tried to do it myself…

…I felt a little overwhelmed and lost.

I was left asking myself:

How does it all fit together?

How much of it do I actually need?

And even, does it really need to be this hard?

What I eventually figured out was not only the answers to all those questions. I also figured out what the “inner core” of SABSA was and what it was all about.

In the end, SABSA isn’t the iconic SABSA Matrix at all.

Instead, it boils down to just three things:

Domains to collect the things you care about…

…attributes to give you a way to measure the value those things provide…

…and a governance model of trust relationships that connect everything in your world together.

Everything else is just commentary about the way those three core concepts fit together. And, once you realize this too, it’s nothing short of…

A huge weight off your shoulders!

Almost everyone I’ve ever met who’s tried to apply SABSA at some point or another was overwhelmed. And many have even given up and tossed it in the bin as something that’s too big…

…too bloated…

…too old…

…too complex…

…too detailed…

…and just plain too slow to be useful.

This perceived weight has crushed the life out of more SABSA adoption projects than I can count, and who knows how many certified SABSA security architects. And then there’s the architects that just collect the initials to put after their name, don’t even try to use it, push it to the side, and ride off into the sunset of the next big thing, never again giving it even a second look.

But that’s a shame, because once you understand what SABSA’s really all about and how it fits together, you realize that all those frameworks and details are really there to show what’s possible, and for completeness. And they also just happen to be hooked together thanks to those three basic concepts I mentioned before.

The problem that you, me and most of the other architects out there trying to apply SABSA successfully to build business-driven security architectures face is that we just can’t see this simplicity. In fact, I’d applied SABSA for about a decade before it really clicked—and I’m not talking about just whipping up a few attributes, metrics and measures either. I’m talking about working deep in the trenches with security teams committed to adopting SABSA as part of what they were doing. It took me about a year of sitting down, digging through everything I could find about SABSA…

…and then pulling it apart, looking at all the pieces and trying to figure out what they really all meant…

…so I could come up with a way to put them back together into something integrated, coherent and articulated in a detailed process that also described each and every possible artifact you might ever want to create or associate with your security architecture within a global, multi-cultural organization.

The result was something I call the Cybersecurity Edition™ of the Archistry Execution Framework™ (AEF), or ACS for short. It unifies all of what’s available about SABSA into a coherent, integrated process, regardless if you’re trying to talk about using SABSA for security architecture or as a risk management framework. It doesn’t matter—because, in fact, you have to do the same work either way. That’s part of what’s really powerful about SABSA in the first place.

However, the problem with ACS was that it still hid the core of what was really important about SABSA – and security architecture in general – under all those process and artifact descriptions. Yes, they’re correct. And yes, they’re useful.

But, if you asked me how I did it, I didn’t follow the ACS process. I didn’t do a bunch of detailed steps. I had a more straightforward…more intuitive way of “feeling” my way to the right kind of architecture.

And, after trying to explain to many of my clients that a detailed architecture process was hardly a replacement for a good security architect…

I “rewrote the book” on how to apply SABSA to build security architecture.

The result wasn’t really a book though. It was the 2nd issue of the print Security Sanity™ newsletter, where I was trying to explain what I did to apply SABSA in an iterative and Agile way—without getting bogged down in the process. I did a deep-dive, introspective look at the way I really did security architecture myself, and I looked for what the “secret sauce” was that actually made it work. But I wanted to look deeper than that. I was also looking for what it was that allowed me to do it fast, accurately and in a way that delivered actionable results, regardless of what kind of organization, solution or environment I was dealing with.

The result was what I call The Agile Security System™, and since I first published it back in August of 2019, I’ve been using, teaching and refining it so that it continues to get even better doing what I claimed it could do back then:

Help you reliably, quickly and consistently build business-driven security architectures—even if you’d never been able to do that before.

Most people don’t have that opportunity. Most people I’ve talked to – and I’ve talked to several hundred people about their individual experiences with SABSA at this point – have a similar story to the one a security architect by the name of Terry has to tell about his experience before he found The Agile Security System and participated in the 7-week, intensive – and expensive – Building Effective Security Architectures (BESA) program.

Here’s what he told me about his experience with SABSA prior to using The Agile Security System:

"I took SABSA training, but you made me understand how to really apply SABSA and to do security architecture and security by design after struggling for 8 years after taking SABSA. I have had no regrets paying for what Archistry produces. I wish I had found you earlier in my career.

Andrew, you really made a difference. After working with you, I know I will be able to respond to any security question or discussion I may encounter.

I have become BOLD where security architecture is concerned.”

– Terry, Independent Enterprise Security Architect and Consultant

And those are his words, not mine. I’m just happy that he’s been able to get so much out of it. However, I also know that not everyone who wants to build security architectures – even with or without SABSA – is confident enough to invest $5,000 and 7 weeks of their life to do the deep-dive immersion into security architecture and understanding the basics of business that BESA requires.

I also know that some people might not yet be confident enough to make the commitment to a subscription to the print Security Sanity™ newsletter or becoming a member of the Archistry Architect’s Club (the Club). It can be hard to “dive in” when you’re afraid you’re not ready yet, or you think that you don’t yet know enough to get the full benefit out of that kind of a regular monthly commitment.

So, finally, after far too long, I’ve decided to do something about it, and I’ve put together something you’re going to see popping up in more than a few places over the coming months. Because, at long last, I’ve cherry-picked the essentials from the expensive BESA program…and I’ve mined a few of the gems from the previous 44 issues of the print Security Sanity™ newsletter…and I’ve culled a few questions from the weekly live Club Calls within the Archistry Architect’s Club to give you a “quck-start” guide to…

Getting Started with The Agile Security System™

It’s short. It’s focused. And, if you’re determined enough, you can read the whole thing in about four hours. This was by design, because I wanted to come up with a way to introduce people unfamiliar with SABSA to the latent power within it few people get to experience themselves—let alone discover. I wanted to help people who’ve tried unsuccessfully to make SABSA work for them in the past and give them a new opportunity to focus on the most important parts…

…so they can finally be able to do the right kind of security architectures.

The kind of security architectures every organization needs. The kind of security architectures that aren’t focused on technology, threats and vulnerabilities.

The kind of security architectures that are focused on the essential elements and concepts of the organization you’re trying to enable and protect…

…and the important network of value-creating relationships that actually enable your organization to do whatever it is that it does to make it unique and viable in the marketplace.

The difference is that instead of trying to figure out SABSA all at once…

…you’re guided by the 7 Principles, 14 Practices and 3 Baseline Perspectives™ of The Agile Security System so you stay focused on what matters…

…aren’t overwhelmed by the complexity that often crushes architecture efforts under their own weight…

…and never again have to start from a blank sheet of paper, sitting there wondering not only where to start…

…but what’s actually most important to the organization.

It’s all covered – briefly, yet in enough detail – so that after reading this Getting Started guide, you’ll finally have a repeatable and reliable way to tackle any architecture work you’re asked to do—no matter what kind of work it is. Because not only does the Getting Started guide show you SABSA in a way you’ve likely never seen it before…

…it also gives you detailed descriptions of how to use those three core concepts to build security architecture…

…coverage of the Principles, Practices and Perspectives of The Agile Security System you’ll be using as you build it out, along with guidance on which architecture development approach you should use when it comes to choosing between…

The three ways you can apply SABSA to build security architecture.

If you’ve been through the official SABSA training – even when I was presenting it – you were told that there’s really only one way to build true architecture. What was that way?

From the top down.

And we told you that because it’s really the only way to make sure that you’re building the correct kind of security architecture that passes the “Goldilocks Test”—which is not too many security controls, not too few, but just the right amount, and in the right place.

Unfortunately, this also leads to one of the more common criticisms of SABSA I’ve heard from fellow security architects:

You can’t use SABSA on anything but new, “green field” projects.

Now, clearly, these people weren’t paying attention to the rest of what was covered in either the Blue Book or the Foundation program, because that simply couldn’t be further from the truth. However, this is still such a common misconception, that I not only call it out specifically on Page 69 of the book, but I devote a chapter each to using The Agile Security System to apply SABSA when you’re building architecture the only three ways I’ve ever done it:

1. Top-down,
2. Bottom-up and
3. Middle-out.

Now, if you’ve been reading my daily emails for awhile, you probably heard me talk a bit about these different approaches from time to time. And, even if you didn’t, I’m sure you’re familiar with the first two. Nearly everyone is.

However, the last one, the “middle-out” architecture is something I’ve found so essential to my work as a security architect over the years that I gave it a special name. I call it Architecture Archeology™, and I call it that because it’s all about “discovering” the architectures of the things around us we take for grated most days.

In fact, it’s about discovering the inherent and embedded architectures of everything from our entire organization…

…to the security policies we’re meant to be enforcing…

…and even to the control libraries and standards to which we’re supposed to comply!

All of them have an architecture—if you know how to find it. And, starting on Page 72, based on everything else you’ve read up to then in the book, I tell you all about how to go about doing exactly that so you too can…

Discover the architecture in anything!

I mean it. All it takes are a few SABSA “tricks” I show you in the book, and before you know it, it’s right there, in front of you. And not only that, but you’ll also be able to capture and reflect the architectures you “unearth” using the Architecture Archaeology approach using the pre-defined domain frameworks of the Baseline Perspectives™, the models that give you a consistent “architecture GPS” and lifeline so that no matter what you’re talking about, what you’re taking apart, or the kind of problem you’re trying to solve…

…you’ll never get “lost” as to what it all means in the “bigger picture.”

Because establishing – and using – that “big picture” view, even for a single security control deployment or software solution, is one of the most missed and under-used aspects of security architecture I’ve ever seen. People just don’t generally do it.

And if they don’t do it, then there’s no way that your security architecture can fulfill its ultimate purpose which is to help people make better risk-based decisions about the way they do whatever it is they’re trying to do.

That’s the point, and the sooner you can get there with your own architectures, the better. That’s the reason why I crammed so much into such a short little book. It’s not intended to replace any of the more in-depth materials you’ll find from me or anyone else.

But it does what it’s supposed to do by giving you a small, focused and easy-to-reference reminder of what the essential things are a security architect needs to do when they create or consume a security architecture.

Here’s just a sample of what you’ll find packed into this small, powerhouse of a book:

• The 3 sentence paragraph that tells you all you need to do as a security architect (without a multi-level matrix model or a 200-page process manual). See Page 51.
• Why most people miss the fundamental power of SABSA domains (and why it’s something you MUST stop doing if you want to be a successful security architect). See Page 33.
• The story behind the birth of The Agile Security System itself (including why the right set of principles beats a detailed process any day of the week). See Page 14.
• A better and more actionable – yet different – definition of “security” than you’ll find provided by the SABSA literature. See Page 16.
• The 9 essential aspects of security architecture you will need to define – whether you use SABSA or not – if you want to prove you’re doing the right things to protect your organization. See Page 61.
• Why SABSA is much more than “Zachman for Security” as it’s often called by Enterprise Architects (and why they’re both wrong and proving they don’t really understand all that much about either the Zachman Framework or SABSA in the process). See Page 21.
• How the Baseline Perspectives of The Agile Security System help you focus on what “security” really means to your organization (and it’s probably not what you’re thinking, if you’re thinking about what’s inside the box). See Page 52.
• The reason The Agile Security System only defines Principles, Practices and Perspectives. See Page 15.
• Why it’s perfectly acceptable for two different architects to model the same system in entirely different ways (even though doing so might otherwise start some knock-down, drag-out arguments between said architects!). See Page 32.
• The “secret” that puts the “Agile” in The Agile Security System. See Page 23.
• Why Practice 3, ask great questions, is such an important aspect of The Agile Security System. See Page 65.
• The fundamental reason most RACI charts don’t really solve governance problems—ever (it’s just not possible because of the way most people do it without doing this one thing first). See Page 43.
• A simple, yet rarely discussed technique to help you tell the security stories you want to tell (no matter what you have to work with in your domain models). See Page 50.
• The one, often overlooked aspect to architecture that is probably the single biggest cause of security failures in the entire history of security. See Page 66.
• Why using a tree to represent the relationships between SABSA attributes just won’t cut it. See Page 98.

What do I mean by this? Well, let’s take a break and talk a bit more about attributes. You see, what many people tend to forget is that John, David and Andy never really intended people to use the attributes from the Blue Book “as is.”

I know you probably know this already, but they were really just a big, running example. However, one of the first “tells” of a newbie SABSA architect is that they want to start from the standard taxonomy in the book and just apply the ones they think are relevant…

…rather than doing the work of engineering their own attributes straight from the real business requirements they get from the horse’s mouths. This is often seen as either too hard or even unattainable, so people like to just “cheat” and use the attribute tree.

The problem is that attributes don’t grow on trees—and there are a couple of other examples around the place – including one in the official Foundation materials – that are about as un-treelike as you can get. Unfortunately, the tree seems etched in people’s brains, and if they’d only take a bit of time to do it properly, it’s impossible to ignore the fact that…

It’s a GRAPH, not a tree.

However, to get this far normally requires a far deeper understanding of the role of attributes, the process of requirements engineering, and paying a lot more attention to the attributes they create themselves and how they’re used. Fortunately, that’s not a problem with The Agile Security System, because you’ll never, ever, see a simple attribute taxonomy tree as an example of anything relating to real architecture work in any of what I do.

• Why The Agile Security System is different than any other approach to building security architecture. See Page 27.
• A powerful and “automatic” way to define SABSA attributes most people don’t know (unless you’ve either been through SABSA Foundation with me, gone through a BESA cohort or been part of the Archistry world for a while). See Page 37.
• Why we’re often forced – kicking and screaming – into doing “bottom-up” architectures (including what we’re really supposed to be doing when we do it). See Page 69.
• The one simple “tweak” I had to make when I taught SABSA Foundation to make the power of SABSA’s standardized RACI really “click” for delegates (which worked so well, other instructors ended up stealing it too). See Page 45.
• How SABSA’s three core concepts are the foundation of the entire methodology. See Page 22
• A “hidden” truth about the nature of the “deliverables” defined by SABSA (something that both gets unsuspecting architects in hot water and nearly assures the ultimate destruction of many SABSA adoption efforts). See Page 22.
• The one thing you SHOULD do, no matter what kind of architecture you set out to build (and why this crucial step matters every time). See Page 71.
• How to decide when you’re “done” with your security architecture. See Page 68.
• Why not knowing all that much about SABSA might actually be the best way for you to start using SABSA both quickly and correctly. See Page 10.
• The “secret” reason your security customers are more important than your stakeholders. See Page 11.
• Why there’s not a single reference to a technical threat or vulnerability in this “cyber” security architecture book (along with a blatant reminder of where this stuff should really be in the documentation and deliverables of your security program instead). See Page 12.
• The only tool you’ll ever need to clearly, easily and quickly define the scope of the security architecture you’re working on. See Page 54.
• A possibly contrarian perspective on why your definition of “fast” might not be the same as mine. See Page 14.
• The 6 fundamental questions you must answer when you’re doing security architecture in any direction (and no, they’re not the WHAT, WHY, HOW, WHO, WHERE and WHEN of the SABSA Architecture Matrix). See Pages 64-65.
• Why complexity has a time dimension—because not everything matters to everyone the same way at the same time. See Page 18.

It’s true, and it’s something pretty easy to forget in the ongoing practice of being a security architect. Most of the time, we’re working in a “time free” zone. In fact, it’s one of the main reasons that the SABSA Architecture Matrix includes the Time column in the first place—because we get so focused on what we’re doing…

We forget about time completely.

Unfortunately, time has a nasty habit of reminding us of its importance—often in the most annoying, humiliating and dramatic ways. And this is even more true when you connect time with the complexity we battle each and every day. However, remembering the time dimension gives us one more fairly sharp knife to wield when we’re attempting to violently encapsulate and tame it so it doesn’t overwhelm us—or our security customers.

• Why most people think of “top-down” as the only way to really do architecture—and why they’re wrong. See Page 64.
• Discover one of the most overlooked architectural vulnerabilities – the domain decomposition rabbit hole – and how to avoid getting sucked into it yourself. See Page 33.
• Why you need a “system” to help you navigate the process of developing security architecture (so that it’s useful, gets read and people actually care about what you’ve done and why you did it). See Page 15.
• The surprising reason that a principle isn’t just a fancy version of a goal. See Page 16.
• How you can apply Principle #5, violently encapsulate complexity, to the domains you’re likely to want to define in your security architecture (so you don’t end up overwhelmed in stuff you’re not only not gonna need, but that you’ll also end up being stuck maintaining for years). See Page 35.
• The only legitimate way to achieve – and maintain – true “business alignment” with a security program of any kind. See Page 17.
• How to reliably and repeatedly be able to communicate the value of your security program—without needing to “measure a negative” or “prove” nothing happened. See Page 39.
• The true – and most accurate – test of how good an architect you really are (and why it’s something that no Autopilot Architect is ever going to do—especially if they know what it is). See Page 72.
• Why I did a complete 180º on the value of most tooling when it comes to creating security architecture. See Page 81.
• The uncomfortable truth about why you can’t build a security architecture without doing a risk assessment. It’s just not possible, and you’ll find out why on Page 37.
• Want a more effective security program? Just do this. See Page 18.
• Meet the ultimate “mother” model of most of the domain relationships in SABSA (that isn't highlighted much unless you’re really paying attention – and still have any brain capacity left – by the time you dig into the details of Module F2 of Foundation). See Page 47.
• The true purpose of an architecture model, picture, diagram – or even a quick sketch on a whiteboard – finally revealed! See Page 17.
• Why there’s really no such thing as either “top-down” or “bottom-up” when it comes to doing security architecture. See Page 72.
• An often overlooked reason why assurance is so important in security (so we make sure that we don’t miss this part in our own security architectures). See Page 18.

This one’s worth taking a bit of a break to talk about in more detail, because of all the SABSA concepts I’ve taught, somehow assurance seems the hardest one for people to really understand—especially when it’s lumped under the “compliance” umbrella as it often is.

Let’s think a minute. What’s the point of assurance at all? Yes, SABSA tells us that it has two faces, that of both Compliance and Audit, depending on the context of where it’s done and who it’s done for. But what’s it all about? The simple answer is the best answer. The point of assurance is…

Making sure you’re doing the right things.

However, a whole lot of time and effort in security is spent on making sure things are done right, a.k.a., optimizing the performance of what it is we’re already doing. Hardly ever do we stop and think about whether what we’re doing is actually the right thing. One of my favorite Russell Ackoff quotes – and there are many – is this one:

“Doing the wrong things right just makes you wronger.”

Because, fundamentally, as he says, it’s better to do the right things wrong than to do the wrong things right. So, if we’re interested in making sure we do the right things…

…we’ve gotta have a way to both validate they’re right and evaluate how well we’re doing them so we can target the improvements we’re trying to make in exactly the right place.

• The most important 8 attributes you’ll ever meet as a security architect (along with why that’s true, where they came from and the right way to define and use them). See Page 41.
• While SABSA tells you your security architecture needs to “live and breathe,” The Agile Security System tells you how to make that happen (and it turns out it’s far, far easier than most people think). See Page 83.
• The real “secret” to building “automatic” RACIs that really work. See Page 45.
• A critical point we don’t tell you about systems – or domains – in SABSA Foundation that will make or break your security architectures. See Page 50.
• The surprising “secret” as to why “being curious” is one of the most important habits a security architect can have. See Page 19.
• Why attributes aren’t the most important of the three core elements of SABSA (and what’s really unique about them in context of security). See Page 36.
• The 6 critical “deliverables” of a security program most people fail to adequately deliver (and when they do, this is the real reason security becomes The Department of No). See Page 11.
• When you should build custom models (and when that’s just a stupid waste of time and energy). See Page 80.
• The one crazy “trick” to making sure every question you ask is a “great question” (and it’s not whether they are “open” or “closed” questions either. You actually need both if you understand what a “great question” really is). See Page 65.
• How to get a truly shared agreement between two parties (something most people don’t even know they’re forgetting about, and then wonder why somewhere – at some point down the line – things go pear shaped). See Page 19.
• Unlock the critical relationships between domains and the systems of “systems thinking” or synthetic thinking. See Page 31.
• The important difference between the two – and only two – parts of a system. See Page 57.
• How the connection with our security customers helps us manage the one constant we can never escape (no matter how much we wish it were true or want to fight against it). See Page 20.
• Why it’s a really bad idea to conflate the concepts of value, price and cost when you’re talking about security architecture—or anything, for that matter. See Page 49.
• How SABSA makes the RACI model “right” (and where it still leaves a few gaps that need to be addressed by ACS and The Agile Security System). See Pages 43-46.

Oh, boy, RACIs, or RASCIs, depending on where you “grew up,” are one of the most used – yet most confused – tools I’ve ever seen that end up doing the exact opposite of what they’re supposed to do the vast majority of the time you try and use them!

That’s actually the real reason I was so excited when I first saw what the SABSA Governance Model can do to make sure you avoid the most classic mistake people make when trying to untangle the complex governance relationships that exist in the modern organization. We’re a long, long way from Taylor’s pice work factory where one person did one job – and only one job – and they were reporting to the guy who was the best at that job because he was the best.

But, give a manager an organizational accountability problem to solve, and the first thing they want to see is a RACI. And the next thing they do is do it wrong, because…

Governance roles are context-specific!

Now, if you think about this for more than two seconds, you understand this implicitly. It’s just that this context gets lost because it’s really hard to represent the required context correctly. Believe me, I know. I’ve gone so far as to flat-out refuse to make a classic RACI for a client because I told them that it wouldn’t help them. They didn’t really like my answer, so they ended up getting someone else who would give them what they wanted.

However, do you think it solved the problem? Nope. Not at all.

Even armed with their shiny new RACI model…

…people were still as confused about who did what, when and why as they ever were.

Eventually, I finally figured out a way to look like I give people the RACI they expect, but it’s not. Because it embeds all the context implied by SABSA’s Governance Model, and it leaves out all the bits that confuse people and cause internal conflict. I even went so far as to go through the entirety of COBIT® 5 and “fix” their RACI models—which was a really fun edition of the Security Sanity newsletter to write, because, as you might remember, the whole point of COBIT is to give you a “governance” framework. It turns out COBIT can't legitimately govern anything once you map it out and apply the SABSA Governance Model to it, showing where it comes up not only short…but sometimes microscopic in terms of delivering what it says on the tin.

• The single biggest mistake people make that ultimately leads to SABSA ending up on the scrap heap of your security program. See Page 22.
• How you’ll never again need to start your security architecture work from a blank sheet of paper (saving a whole lot of time, and making it much easier for both you and your security customers at once). See Page 52.
• The ultimate purpose of what being a security architect is all about. It’s a helluva lot more than just being able to draw models or break into things. See Page 78.
• Finally! A simple way to define the concepts of risk appetite vs. risk tolerance in a way that will resonate with our friends in Enterprise Risk. See Pages 39-40.
• The often missing – yet fundamental foundation – to any security program (and why most security programs aren’t delivering the value we expect for the investments we make). See Page 22.
• What’s CRUD got to do with it? It’s probably not what you think, and it has nothing at all to do with databases. See Page 33.
• How to present our security architectures almost automatically (based on the work we’ve already done before writing the document or pulling together the presentation). See Page 80.
• A detailed guide to building out a physical Architecture Wall™ that will beg to be updated, foster engagement across your team and help you stay focused on what’s really important about your organization’s security architecture. See Pages 83-84.
• The unfortunate reason that most organizations end up with “headless” security architectures (and what to make sure you do to prevent this deadly decapitation in your own organization). See Page 24.
• Why you can easily model interpersonal trust relationships and business agreements using SABSA domains (meaning that you don’t have to worry about a bunch of “special cases” in your architecture, and that some of the distinctions often included in “architecture” are no longer necessary thanks to this particular AEF extension of the SABSA domain concept). See Page 48.
• A clever “trick” to manage the monotony and boredom often inherent in doing “bottom-up” security architecture (that doesn’t involve booze or expensive automation). See Page 70.
• The 3 things to look for to measure your progress and development as a security architect—with or without SABSA and The Agile Security System. See Page 86.
• How The Agile Security System extends the core SABSA domain concept to make it even more powerful than it already was. See Pages 30-35.
• The name – and the function – of the most critical “layer” of architecture you’re probably not yet creating (and how The Agile Security System literally “forces” you to focus here instead of where you’re probably spending most of your time today). See Page 24.
• How you can realistically apply SABSA successfully while ignoring the rest of the 20+ frameworks it defines (illustrating that it’s no wonder you were a bit lost after the 5-day firehose of SABSA Foundation). See Page 25.

I get it. I really do. SABSA is a big, hairy beast once you go through the whole thing in detail, and I still remember my own feeling when I sat down to take the SABSA Foundation exam on Friday afternoon after drinking from the firehose of David’s delivery all week.

And I was lucky, because I was better prepared than a lot of my fellow delegates, because I’d been doing what I call technology architecture of all kinds for many years before I’d ever met David.

However, one of the biggest problems I saw when I was teaching people SABSA was simply related to the sheer amount of material you take in. And, unfortunately, most of the really important stuff is in the first two days…

…but most of what people tend to remember is the last thing they heard or learned—which, in the case of SABSA can unintentionally leave you…

Locked in the lower layers of your security architecture.

A place where, if you truly believe in the value proposition of SABSA, is the exact opposite of where you want to be. That’s why it’s important to step back and really prioritize the frameworks and elements of SABSA so you can stay focused on what’s important, and it’s one of the biggest reasons I focus on what I do as part of what I cover in this Getting Started guide.

• How the “building block” approach to security architecture can quickly and easily build you the exact WRONG architecture to what your organization really needs. See Page 64.
• The definitive answer to why it’s impossible to do SABSA “right” without linking attributes to your domain models. See Page 40.
• Why I renamed the iconic SABSA lifecycle activities when I created the Archistry Execution Framework. See Page 26.
• The noose that will hang you if you’re doing Architecture Archaeology. See Page 73.
• How The Agile Security System is related to both SABSA and the Archistry Execution Framework. See Page 28.
• The #1 fallacy people have about security architecture that undermines everything else your security program is trying to do. See Page 56.
• Why the layered architecture model of SABSA is far more important than the iconic SABSA Architecture Matrix as a whole. See Page 23.
• The critical difference between SABSA domains and the original concept of a Security Domain defined by ISO back in 1996 (and it’s also one of the main reasons most of what people mean when they say “domain” isn’t the most powerful way to think about them in your security architecture). See Pages 29-30.
• Understanding the power of the veto when building your security architectures (something most people don’t think about this way, much to their detriment and extra, unnecessary work). See Page 48.
• Why you should never underestimate the importance – and power – of “drawing boxes” as an architect of any kind—security or otherwise. See Page 30.
• The best – and fastest – way to identify true gaps, redundancy and excessive control deployments in your security architecture (relying on brainpower, not automation).  See Page 76.
• Unlocking the powerful “secret” relationship between domains and SABSA’s architecture layers that most people never actually discover, let alone use to make their life easier as a security architect. See Page 54.
• The drop-dead-obvious relationship between the discovery of the domains in your architecture – new or already there – that allows you to begin to start “seeing” architecture in your head. See Page 35.
• Why there’s no way to get a correct architecture using a rigid process (no matter whose it is, how good it is, and how “flexible” it might be). See Page 68.
• How SABSA’s attributes refine and revitalize Donn B. Parker’s control guide principles from way back in 1985. See Page 36.

Believe it or not, I hadn’t consciously come across the work of Donn B. Parker until sometime a  couple of years ago when I was doing some research for an issue of the Security Sanity print newsletter. I was both amazed and surprised by all he’d done and the contributions he made. Actually, he damn near defined the entirety of what most of us do in security every day—single-handedly through his energy and influence. However, as I read more and more of his work, what really resonated with me was the fact that…

He seemed even more stubborn and contrarian in his approach to security than I am!

Now, those similarities only go so far, however. Because I don’t necessarily agree with some of his fundamental positions on security, “best practice” controls (he basically invented this approach), and the relevance and applicability of risk management to the practice of security—even though I do understand where he was coming from and why he felt this way. But still, it’s impossible to argue with what he accomplished, and it was both refreshing and surprising to discover his control guide principles as a common connection point between his work and the way I approach security architecture with SABSA.

• What a 150 year old “poisoned spring” theory can do to help us build more robust security architectures today—including getting the right kind of controls in the right place for the right reasons. See Page 49.
• Why diversity is a great characteristic in your architecture team (far beyond anything political or social you might initially imagine these days when you see that word).  See Page 76.
• The one simple thing you need to define a domain that can unleash the power of your architecture efforts and reveal the most important things your organization needs to you to actually protect (instead of faffing around with security standards, control libraries and all those “assets” you can kick). See Page 31.
• Why we need attributes as a security architect. See Page 36.
• A subtle – yet sometimes surprising – difference between SABSA’s Business Drivers for Security and its Control and Enablement Objectives that often confuses people (but which is starkly simple to get right once you know the right “trick”). See Page 37.
• Finally revealed: the “elusive” definition of what SABSA means by a “domain framework.” See Page 53.
• The right order to do the two fundamental types of thinking as an architect (and it’s the exact opposite of what most people do—even architects). See Page 66.
• How applying SABSA properly will “automatically” write your security strategy for you (without doing any more work than is otherwise required to create whatever architecture “deliverables” you’re on the hook to create). See Page 38.
• Who our 7 basic types of security customers are (and how to figure out what they’re expecting from us). See Page 79.
• How to discover the network of attribute relationships in any architecture (just use this one simple tip, and you’ll have more connections between attributes than you’d imagined were possible). See Page 98.
• The “secret” answer to why control performance and risk exposure are measured in opposite directions and what this means when defining your organizational risk appetite for cybersecurity. See Page 39.
• Uncover the fundamental systems relationships embedded within both SABSA and security architecture. See Page 59.
• The single, biggest problem you’ll face doing security architecture from the bottom up (and a few practical ideas to keep from grinding to a halt or producing a bunch of stuff nobody really cares about). See Page 70.
• Why it’s important to be able to surface the architecture of anything. See Page 73.
• How a “handful of paper” just may well be the only kind of security architecture documentation you really need. See Page 82.

Ok, I’m sure you’re a bit skeptical about this one—especially if you’ve only seen some of the stuff I’ve written about this before, so let me explain this issue a bit more.

Most security architecture documentation falls decidedly into one of two camps. Either it’s delivered in a convoy of 18-wheelers piled high with paper…

…or it’s basically nonexistent—or worse than nonexistent because it looks like a chicken walked through some black ink and then jumped all over a blank sheet of paper.

Nobody has a clue what the hell it’s supposed to mean.

And there’s only one thing worse than documentation that nobody understands, and that’s documentation that’s just flat-out wrong. No documentation is better than worthless documentation, and so, when I was thinking deeply about what I do myself when I build security architectures – and with some fresh “war stories” in mind from some recent client engagements – I decided that it was time to throw out the rulebook most people used when it comes to creating architecture documentation and start over. The results of this exercise are what you’ll find both described and shown via example in the pages of this book.

• The single, simple step you need to master in order to watch attributes literally JUMP off the page in front of you (something so simple, a middle-schooler can probably do it quicker than you can now). See Page 38.
• Why “standard templates” for security architecture are the Devil you actually never want sitting on your shoulder (and what to do instead). See Page 81.
• One skill that will make you become truly “fearless” as a security architect (and how this skill is the ultimate way to lay the groundwork for an unbreakable foundation of credibility and trust with your security customers). See Page 74. 
• How to know if “middle out” is the right architecture approach to take. See Page 73.
• The reason there’s always “another box” anytime you’re talking about the way two domains interact—even if they’re already peer domains of a common superdomain. See Page 47.
• Discover the 2 most important things we need to know as a security architect. See Page 51.
• The previously untold origin story of my “crazy spider diagrams” that have scared the piss out of conference attendees and clients alike (and what I do now instead, almost all the time). See Page 52.
• A fundamental “gut check” provided by The Agile Security System you can depend on to help you detect when you’re doing things you shouldn’t be doing when you’re developing security architecture. See Page 53.
• The “secret” to developing and using Attribute Patterns—another extension of SABSA that I created some time ago as I developed the Archistry Execution Framework (you’ll also get the full set of “reference patterns” I use in my own work too). See Pages 98-99.
• How to develop the critical skill that can instantly establish a connection between ourselves as a security architect and the variety of security customers we serve. See Page 67.
• The basic business fundamentals of why security customers are better for us than security stakeholders. See Page 78.
• What two types of thinking are required to be a successful architect (and why, while we might sometimes do it intuitively, we don’t really do enough of the one that matters most). See Page  58.
• Uncover the critical relationship between design and architecture that most people misunderstand, misapply and miscommunicate. See Page 59.
• The exact “process” required to “fill in the blanks” of your security architecture when you’re not able to start at the top. See Page 70.
• Why electronic architecture documentation and a bunch of fancy tools are often far less effective than building the physical Architecture Wall defined by The Agile Security System. See Page 83. 
• The true origin story of the DOMA (including why it matters and how to capture them). See Page 74.
• How to apply “middle out” architecture to expose the architecture of the NIST CSF (or any other control library, framework or security policy you’ll ever trip over). See Page 75.
• Why asking about the “deliverables” of security architecture demonstrates someone doesn’t really get the point of security architecture. See Page 80.
• The real reason people could care less about security (and it’s the same reason we should care more about it too). See Page 50.
• What you should create when you MUST create architecture “deliverables” (HINT: you generally need a whole lot less than people think). See Page 81.
• …and much, much more!

What’s Inside the Book

Even though I said it’s a small book, it packs 15 chapters and 7 different appendices into just 105 pages. So, in case you want to get a structured breakdown of what you’ll find in the book instead of just a glimpse of the highlights I’ve covered above, here’s what you’ll find inside.

Chapter 1 gives you an overall introduction to the purpose and structure of the book. It tells you what it is, and what it isn’t. And one of the things it isn’t is a replacement for a deeper introduction and education on SABSA and The Agile Security System like you’ll find in the flagship Building Effective Security Architectures (BESA) program or the official SABSA training.

Chapter 2 introduces you to The Agile Security System itself. It talks about where it came from, why it’s necessary, and some immortal caveats about what it takes to build effective architectures fast. You also get a bit of an overview of my own personal journey from where I started as a fresh graduate with a degree in Computer Science to where I am now—including some of the major milestones and influences that got me from there to here.

Chapter 3 provides the quickest, most condensed and up-to-date introduction I’ve ever given to SABSA—including where it came from, what it is (and isn’t), and what it does to add to the discipline of security architecture. I provide my current definition of what security architecture is, and then I talk about the three core concepts of SABSA and why they’re so important.

Chapter 4 talks about my own journey and evolution in the way I understand and apply SABSA. It talks about my first generalization and integration of the core SABSA materials into a unified framework, and describes what I was trying to accomplish by doing it. I then talk about swinging back, full circle, to SABSA’s security roots and how everything that’s in SABSA is inherently a part of The Agile Security System too—all in one handy, easy to remember diagram.

Chapter 5 walks you through the most important part of SABSA—both to me and to The Agile Security System and to the discipline and practice of security architecture as a whole. I talk about how SABSA embraced and clarified the then current state-of-the-art, and then I describe how I’ve both relaxed and extended the domain concept in my own work and evolution as an architect.

Chapter 6 brings us to attributes, probably the second most commonly recognized aspect of SABSA behind the iconic Architecture Matrix. In this chapter, I talk about how attributes work, how they relate to prior art, and, most importantly, how you can learn to create attributes almost effortlessly, no matter what you happen to be working with. Also, since you can’t talk about attributes without talking about how you measure how much of them you have, I summarize the essentials of SABSA’s Performance Management Framework (PMF) and talk about the way attributes are used to express your organizational risk appetite.

Chapter 7 ties everything together by introducing you to the SABSA Governance Model. Now, if you’ve been through the Blue Book or the SABSA Foundation training, you’ll see some things that are familiar. However, you’ll also probably see some things that you might not expect too—because there’s a whole lot more to the SABSA Governance Model than just defining the relationships between the core phases of the SABSA Lifecycle. I don’t even mention that at all in the book, actually.

Chapter 8 introduces what I believe is the most fundamental domain relationship, that between a customer and a supplier. However, these aren’t fixed entities. In fact, and fully in accordance with the SABSA Governance Model and the Entity and Trust Framework, each of these are roles that get assigned to the right actors at the right time so you can truly unpack and uncover what is really happening to deliver value in your organization.

Chapter 9 presents the core domain framework I defined with The Agile Security System based on literally decades of architecture work in the field. I got tired of always drawing almost the same domain models every time, so I defined the Baseline Perspectives™ as a way to short-circuit that work and help me stay focused on what’s really important “inside” the lines. And, if it works for me, it’ll work for you too—especially based on the comments and feedback I’ve gotten from the many people using them every day as part of their own architecture work.

Chapter 10 cuts to the chase about what’s important to capture as part of developing and documenting a security architecture at any scope or scale. It connects the dots between what we’re trying to do as we're capturing and defining security architectures with general systems theory, so that we can have an over-arching formalization to help us do what we’re trying to do without getting stuck in the weeds and overwhelmed with detail. Most importantly, this chapter talks about the two essential modes of thinking every architect must use—and which one is actually the most important and relevant for creating successful architectures.

Chapter 11 provides a high-level overview of what’s required to do architecture the “right” way—starting from the top, as close to the business as possible and working our way down through SABSA’s architecture layers. In the process, it gives some fundamental questions every architecture must answer and then talks through how the Principles, Practices and Perspectives are used to make sure you don’t miss anything important.

Chapter 12 starts at the bottom and talks about what’s involved in doing “bottom-up” architecture. Whether we like it or not, there’s still a time and a place to do it—whether it’s “proper” architecture or not. It’s still useful, and there’s still valid reasons for doing it. This chapter talks about what it’s for, why you’d do it and what to do to make sure the tedium and overwhelming boredom often involved in doing this kind of exercise doesn’t suck the life out of you as a high-value security architect.

Chapter 13 presents what I call the “middle out” or Architecture Archaeology approach to discovering the architecture inherent in anything you’ll ever encounter. It’s fair to say that it’s potentially a superset of the other two, but the purpose of doing it this way vs. the others is very clear, and something I talk about extensively in this chapter. I also tell you why once you start, it might be the only kind of architecture you’ll do from now on too.

Chapter 14 dives into the heart of what many people think is where the whole “security architecture” thing starts and stops. It tells you how to effectively communicate the architectures you build, because going to all that trouble to do it isn’t going to make much sense if nobody but you is able to use it. This chapter talks about the importance of matching your message to your audience, and I present the most important groups of security customers  we normally need to address, along with some tips and guidance on exactly what to say to them when we do it.

Chapter 15 closes the book with some ways to measure your own progress as a security architect and gives you several options and potential “next steps” to continue your skill development and evolution.

Appendix A presents the Enterprise Baseline Perspective™ model, including the domains and core relationships that describe the value delivery network of your entire organization, whether it’s large, small and whether it’s for-profit, non-profit or public sector. I’ve successfully used these models in all of those environments.

Appendix B presents the Service Baseline Perspective™ model. This perspective is one of two ways you can take a “slice” through your organization at any scope to match your architecture iteration and ensure that you’re not overwhelmed with excessive or irrelevant details. At the same time, everything you reference in this model automatically has a “home” in the Enterprise Perspective, so it’s impossible for you – or your security customers – to ever get “lost” when talking about something you’re working on.

Appendix C presents the Value Stream Baseline Perspective™ model. Like the Service Perspective, the point of this model is to allow you to “slice and dice” your organization to focus on what’s relevant and important. In particular, this model covers all aspects of your organization, where the Service Perspective may not always be the perfect fit, depending on the nature of the project or problem you’re working on. This way, you have everything you need to deal with the normal architecture iterations that are most commonly done by security architects in one or the other of the two Perspectives.

Appendix D presents the External Baseline Perspective™ model. The purpose of this perspective is to allow you to model the way your organization interacts with the outside world. Not all aspects of your organization do this directly, so this Perspective helps you “zoom in” on the parts that do so you can delve in to the nature of those interactions and identify their implications from a security perspective.

Appendix E defines a set of 55 attributes that repeatedly come up in my own security architecture work. These attributes intersect with the attributes defined by the Blue Book and the official SABSA materials in their names, but the definitions are different to reflect the way I use the three core concepts of SABSA in my own architecture work. These attributes are part of the Reference Architecture I built for the Archistry Execution Framework, but they’re so common that I find it almost impossible not to need them in almost every engagement.

Appendix F provides a set of default Attribute Patterns – recurring relationships between attributes that are inherent in the attributes themselves – that I’ve defined over the course of my architecture work. Sometimes these patterns are the perfect fit for helping you prioritize and place the relevant attributes in your own architecture models, and sometimes they’re close, but they’re definitely not the droids you’re looking for every time. That’s ok, because this appendix also talks about how to use, extend and transform these patterns to make them fit your own architecture projects too.

Appendix G defines each of the core domains included in any of the Baseline Perspective models. While simply drawing a box can potentially define a new domain, they aren’t much good to you if you can’t describe what’s inside them—so you can know what isn’t. These definitions also provide a starting point for you to use as the basis of your own domain definitions so there’s no confusion as to what you’re talking about in your security architecture and why it’s important to the organization.

How to Get Your Copy

Now that you know what you’ll find inside and what the book is supposed to do for you as a current or aspiring security architect, you should have enough information to decide whether it’s a good fit for you or not. However, I must caution you that while I know the right audience will get a lot of benefit from this book…

…there’s still a chance that this book might not be right for you.

So, if you’re looking for an up-to-date and in-depth way to learn SABSA or attain your official SABSA Certification, then this book probably isn’t going to be what you want. In fact, because some of the stuff I talk about is not only a whole lot more advanced than you’ll get in other sources of SABSA, but because it also downright deviates and contradicts certain elements of core SABSA canon…

…it just might make it HARDER to learn “proper” SABSA for you than if you’d never laid hands on this book before.

Also, while I’ve been using SABSA “live” and in the field since I first discovered it in 2005, I’m not – in any way – associated with the SABSA Institute, I no longer teach the official SABSA Foundation program…

…and I am not certified as anything higher than a SABSA Chartered Foundation (SCF) architect. If you’re looking for an official SABSA guru or duly ordained SABSA Chartered Master (SCM) as a requirement for being qualified to teach you anything of value…

…you’re looking at the wrong guy.

I know what I know about SABSA from years of practice, mistakes, study, in-depth-analysis, discovery, direct personal mentorship from David Lynas and John Sherwood, working side-by-side with David in the field and from doing what it took to stand in front of over 200 SABSA Foundation delegates for 4 years without coming up short. I’ve taken it apart, and I’ve put it back together—and then I’ve transcended the official stuff to blaze a new trail.

It’s a trail that’s not necessarily incompatible with the well-trodden and official one…

…but it’s bound to raise some questions and challenge some expectations along those lines—which, again, is just another reason why learning from me might make it harder to achieve your SABSA certification goals.

However, if you want to build the most business-driven, effective and relevant security architectures at any scope you could ever encounter…

…and you want to learn how to do it as reliably, repeatably and as fast as humanly possible…

…then it’s time to claim your copy of Getting Started with The Agile Security System right now using the big yellow button below.

I look forward to welcoming you into a brave new world of security architecture.

Stay safe,

Andrew S. Townley
Archistry Chief Executive