I’m gonna go out on a limb here, but to me, there’s one specific thing that sets a security leader (head of function, manager or architect) apart from the rest of security professionals, that that one thing is…
…the ability to actually think.
What that means is having the ability to move beyond blind reliance on “best practice” or someone else’s tools and models and be able to customize or create your own solutions to the problems you face.
Now, I realize that doing so takes time, and is sometimes pretty hard.
Nor am I suggesting that you do it for every decision you need to make or every problem you have to solve. However, as a profession, we seem to have a tendency to try and turn every good model into a pick-a-mix of a control library. And in the process – because we’re so focused on “getting to the security stuff”…the controls – we lose sight of the value of the model and the power that model might give us to think about the problem differently, or…dare I say it:
More simply.
As you might now, the upcoming issue of the April edition of our print newsletter Security Sanity™ is all about trying to find a good way to integrate cloud security into the rest of your security program. And in doing that, I’m going to look at some common models people like to use to help them with their security architecture efforts: the CSA Enterprise Architecture (nee Trusted Cloud model), the NIST cloud reference architecture(s), and the Microsoft model.
The Microsoft model kinda stands alone in the mix simply because it’s really focused on showing where the various components and solutions of the Microsoft offerings fit in to many of the concepts formalized by the NIST Cloud Computing Reference Architecture (SP500-292). It’s in the mix primarily because there are hardly any organizations of scale that don’t, at some level, use Microsoft technology solutions. That means, it’s gonna be very relevant to many of you.
However, as effectively a component-based solution blueprint, it’s subject to the same issues we have with “getting to the controls” I mentioned above. However, in this case, we’re so used to talking about the products and solutions, it’s very hard to come up for air and tie those investments to things the organization actually cares about.
Well…beyond kinda the simple view of, “If we didn’t have our Microsoft kit, the organization would grind to a halt.”
The harsh reality is that the business value of your security program – or the things that will connect and integrate your cloud approach to your existing security policies and risk appetite – don’t come from the bottom layers of the SABSA architecture stack: the physical mechanisms and the components that implement them. The way you can connect and understand what’s really required for your cloud security architecture…
…also requires that you have a clear view of the upper 3 layers.
And it’s really difficult to think about the upper 3 layers, when all you’re focusing on is the control mechanisms you might possibly need and the solution components you can buy to implement them.
Maybe you haven’t noticed, but about 50% of the CSA model is focused on the bottom two layers of the architecture. Those bottom two layers that are the most volatile, most dependent on the current technology…and most dependent on whoever your organization decides to do business with.
As a result, they’re some of the least important things to talk about when we talk about policy and we talk about value.
And yet…we can’t wait to get down to those layers, so we have a clear picture of exactly what we like to work with. Because it’s what we know, and because it’s what we know, it’s where we feel comfortable.
It’s also what most people mistakenly believe is the focus of security architecture.
What I’m telling you is that you can simplify the way you think about what’s really required – and the business value it provides – by ABSOLUTELY IGNORING almost 50% of one of the most widely used cloud security reference architectures.
You can throw it away…at least for a while…
…and you won’t even miss it.
In fact, it’ll make your job easier.
Because the controls themselves have no value. The value that matters to your organization is what the controls actually protect. But in our race to get to the “security” and make sure we have a “completely specified” model of controls, we get distracted by the 50% that doesn’t matter.
And when we’re distracted, we don’t think straight.
We don’t communicate effectively.
And if we can’t do those two things, then how likely do you think we are to make the right security decisions?
The challenge, of course, is knowing which 50% of the model you can ignore…and for how long.
Fortunately, that’s exactly what I’m going to illustrate in the April issue of the newsletter. But you’ll only get it delivered to your door next month (COVID-19 and printing and post willing)…
If you make sure you’re subscribed by 11:59pm US/Eastern tomorrow night. If you’re not, then you’ll forever wonder if this is something that might make your job easier…
…or if I’m just a raving lunatic that’s got it all wrong and doesn’t know what they’re talking about.
Maybe that’s ok with you, and, if it is, then that’s perfectly fine with me. However, if you want to know more about what I’m talking about, why I think it matters, and a better way to use and abuse the 3 models (well…4 counting the draft NIST security overlay for SP500-292), you’re running out of time, and you should get ye over to yonder link immediately to rectify the situation:
Our world has changed pretty dramatically in the last 3 months, and I think it’ll continue changing for at least 3 more. And being able to do a better job – and have more confidence in our cloud solutions – will play a big part. What you do with that is up to you.
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
