Having almost survived day one of #SAlockdown, I’m going to give the COVID kids a rest for today. Instead, I’m going to talk about something that I’d encountered before in some conversations with people who had/use SABSA, but which, honestly, I didn’t quite understand until I was working on the upcoming April issue of the newsletter. That “thing” is when people try to align a framework to another…something…instead of actually using the framework to solve problems.
In one particular conversation last year with someone who was familiar with SABSA, they mentioned that they weren’t going to go through the effort of aligning SABSA with whatever it was they were doing, because they couldn’t justify the extra effort in their client engagements. Now, a couple of things immediately jump out when someone is taking about aligning SABSA with anything else.
First, there’s a tendency to misinterpret what SABSA really is. Because if you think that SABSA is 66 cells of artifacts and activities, you’re kinda missing the point of the whole thing. Sure, those are two important frameworks of the whole kit of frameworks SABSA provides, but the artifacts – at least the way they’re often interpreted – aren’t really the point.
To me, at least, the point is actually applying the methodology so you can do a better job making sense of the world you’re trying to protect and be able to more easily justify the steps and investments you’ve made because they’re directly correlated with things the organization actually cares bout.
But…maybe that’s just me.
Second, it’s pretty clear that someone trying to “align” SABSA with something else hasn’t actually really done much with it in practice. If they had, they’d quickly realize that – at least in my experience – it’s generally better to reflect “the other thing” in terms of applying SABSA than it is the other way around.
Now, there are some things that you can align:
Pens.
Cars.
Control libraries.
And processes.
But if you try and mix and match what it is you’re aligning, then the results are going to be…
…let’s just say, “less than optimal.”
Unfortunately, that’s pretty-much what seems to have happened with one of the most widely used Cloud Security Architecture reference models, because it’s taken a process-based methodology…
…and tried to integrate and align it with “security stuff” and “enterprise architecture” concepts in a way that supposedly gives you a blueprint for…well, according to its authors:
“A comprehensive approach to cloud security.”
And it is indeed a noble effort, because people tend to get their knickers in a twist about the whole “cloud security” thing because they don’t have control, oversight and the ability to apply their internal controls in all the *ass’s of the cloud.
They think it’s different, and that it’s fundamentally more insecure than any internal infrastructure you might find yourself managing right now.
In reality, that perception is slightly misguided. Cloud is the same…to a point, but since most of our cybersecurity activities are focused on the lower levels of a layered architecture model, when we haven’t done the work required to define our security policies in the context of what the organization is trying to achieve…
…we’re somewhat adrift up a slightly brown creek without a paddle in sight when those lower layers suddenly get jerked out from under us.
So, it’s understandable that we’re anxious and lost when the best controls at our disposal are negotiated agreements, sensibly applied encryption mechanisms and the realization that if we somehow leave the barn door unlocked…
…it comes with a 400’ blinking, pink neon sign that lets the bad guys know we’ve slipped up.
But…if instead of trying to align apples to pears and dragon fruit, we actually try and use the framework to get more clarity and leverage over what we’re trying to protect, then our world looks rather dramatically different than the cloud reference architecture provided by the CSA.
We see the intersections.
We see the layers.
We understand what the controls (implemented across no less than 3 different layers of architecture) are actually trying to protect.
And that allows us to have some space to think. And it allows us to see the world just a wee bit differently…
And, most importantly…
It makes our jobs a helluva lot easier.
So if you’d like to know how to look at cloud reference architectures – security or otherwise – though a much better lens, and you’d like to know how you don’t just have to take my word for it, but you’ll learn how to do it yourself…for any reference architecture you might someday trip over in your security architecture travels…
…then time’s running out to make sure you’re subscribed in time to get the print edition of the Security Sanity™ newsletter shipped to your door next month. Because, if you’ve not already subscribed using this here link before the end of the month, you’re going to miss your chance to see SABSA applied properly to the problem the CSA, the Microsoft and the NIST cloud security architectures are trying to solve.
The link you need is:
And the deadline is the 31st of March to make sure it winds up on your doorstep next month.
If you don’t care about cloud security architectures, or you’re not using any of those models, then by all means, save your money. You’ll only get a bit of a primer on applying SABSA in terms of The Agile Security System™, which you may or may not find useful.
However, if you’re sick of overly complex, highly redundant and confusing reference architectures for what “cloud security” is supposed to be, then it might just be worth an hour or two of your time to flip through and digest.
As always, it’s your own choice. Most of you live in parts of the world where you’re able to buy something other than soap, medicine and food for the next 21 days, so there are plenty of other options for you. But if you’ve been debating about subscribing to the newsletterr, I’d highly recommend you don’t wait too long. This one’s a good one, and after it’s shipped to the printer, there won’t ever be back issues of this one either.
Stay safe, sane and healthy,
ast
—
Andrew S. Townley
Archistry Chief Executive
