During the research I did last year reaching out to SABSA practitioners, one of the things that kept coming up over and over again was that people were having a really hard time trying to get started with SABSA in their own environments.
And this isn’t just with people who take the course and try to “fit it in” around the edges of what they’re trying to do. It’s also a very real problem I face every time I’m working with someone directly who wholeheartedly believes in the value of SABSA, but they just can’t get very far with it.
Despite the guidance of “use your own definitions” and “define your own attributes” you get during foundation, the reality is that most people don’t. They pick the ones from the handouts and try to apply them to their environments.
…or the opposite is true and you spend loads of time trying to build the “perfect” Attributes Profile, and then by that time, the organization’s lost interest, and even you might be burnt out and have forgotten the value you were hoping to get out of the exercise in the first place. In one extreme case I remember hearing about, someone worked 2 years on just attributes!
So here’s the thing about security architecture, SABSA or otherwise:
Architecture is there to help people make decisions, both about priorities and about what to do next. And no, they aren’t quite the same thing.
So, the measure of the value of the architecture is really a combination of two things:
- the time it takes before you have “enough” architecture to support decisions that guide the work that the security team does, and
- the quality of the decisions you’re able to make based on the architecture.
So, it’s clear that taking a long time to “map the world” isn’t going to fare very well in terms of those two metrics.
Now, last year at COSAC, I tried to help people understand that it was possible, and in fact recommended, that you should apply SABSA in an agile manner. And the best way to do this is in terms of well-defined iterations of scope you can control.
However, this is good as far as it goes, but the next questions are immediately about “what should go into an iteration’s scope?” and “what’s too big or too small?”
And, at the time, I didn’t really have a good answer for that. I mean, given a particular scenario or a particular environment, I had no problem answering. I just didn’t know how I did it.
Now I do.
And that system is what the August newsletter is all about. It is a system and a set of 7 principles that will make sure you are always focused on the right things and gives you a framework in which to ask the right questions to make those decisions.
But that only goes so far as well. It’s still not enough to get people who haven’t really practiced SABSA the boost they need to start getting value from it—and see that value quickly.
So the second thing I realized was that those recurring patterns I was talking about before were the key. Now, if you were at COSAC last year, or we’ve worked together directly, you’ve seen these. It’s a set of domains and attributes that I use as a starting point in all the architecture work I do.
However, they’re still somewhat complicated, and you still need to have a pretty good understanding of how things fit together to use them.
There needed to be an even more essential way to help people build SABSA security architectures “by happy accident” and without getting lost in all of the powerful, but potentially overwhelming, goodness that is the SABSA methodology in full.
Now, I know John and David aren’t going to like this approach very much because in a way, it’s a “reference architecture”, and that goes against what they recommend: that you build the attributes and domains according to your own understanding of your organization, because every organization is different. And, actually, I still agree with that.
But it’s a pretty steep hill to climb if you’ve never seen or used what you’re trying to build…
…and you’re trying to do it on the front lines of an understaffed and unappreciated security team.
So I put my stuff through the strainer again and came up with what I think are the most essential ways of looking at your organization that you need to think about when you build a security architecture. It’s like a skeleton.
It gives you an outline of where you’re supposed to go, but without being too prescriptive about what goes in the middle. The point of this was making sure it’s something you can literally pick up and transform the shape of your security architecture in as little as a week, depending on how much time you can allocate.
That’s why 25% of the August newsletter defines a set of baseline perspectives to give you a working domain framework out of the gate. That’s 10 pages of domains, ready to go. Today.
But don’t panic, there’s only 3 perspectives—and a whole lot of commonality between them.
The most important thing is that the whole thing fits together as a system: the principles, practices and the baseline perspectives you need to truly deliver Agile Security in your organization.
And that’s also why I’m never going to make this issue available again if I do ever decide to sell back issues. It’s that important, and, as I said yesterday, in my super-biased opinion, this is the best work I’ve ever done in my entire career to date.
So if you want to make sure you get it and can transform your security architecture in August, subscribe here before it goes to the printer at the end of the month:
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
P.S. Here’s something you can do if you liked today’s post: you can sign up for those daily emails that annoying pop-up keeps asking you about. Or, if you want to know more about what you’re going to get if you do and how it works, then just go knock on the front door: https://archistry.com and you’ll get the whole deal.
Or…you can just keep reading the blog, or ignore me and Archistry all together. I’m good either way.
