It’s been said that complexity is the biggest problem we face in security, and I’ll argue that it’s doubly true when we’re talking about getting our cloud security architectures right. Because the biggest challenge we ultimately face is determining the answer to the question:
What’s really different about cloud than what I’m already doing?
To answer that simple question, we need to first subdivide cloud into at least 3 major *asS’s (although some have gone rather overboard with this part too)…and then we might need to figure out where those cloud services are actually located, either public, private or hybrid.
And then we have some permutations of those options…
…and then there’s the geographical locations of those options…
…and then we have a set of reference architecture models proposed to help make our lives easier when we talk about it, and the most vendor-neutral one gives us a canvas containing no less than 444 unique elements.
Now some of those elements are controls, and some of those controls might be in 1 to 3 layers of our architecture, and then there’s some things that aren’t controls so that we can help us organize the way we think about our technology infrastructure assets…and then the information and data those assets manipulate…
…and then the people that manage them.
As you can see – and you undoubtedly know from your own experience – it gets to be pretty complicated pretty quickly.
Once you throw your existing security policies and relevant regulatory requirements into the mix, you’d be forgiven for violently throwing it in the “too hard” box, slamming the lid, carrying it out into the back garden…
…and burying it all in the deepest, darkest hole you could dig before dinnertime.
Or…
You could look to find a way to simplify the way you looked at the problem so you could find the smallest set of moving parts you’d need to worry about whenever anyone brought up the word “cloud” in conversation.
Fortunately, you don’t really have to look too far to find that approach.
If you know anything about applying SABSA in practice, you can take the time to roll your own model so that you end up with your own, personally selected and validated set of domains and attributes that you need to worry about in your cloud security architecture efforts.
Now, depending on what else you’re doing, that might take you a bit of time—or it might not. I know it did for me, but then I’ve had 14 years of practice doing this, not to mention access to some super-secret tools that help me build these architectures of anything I like faster than most people.
Alternatively, you can leverage all my own practical work, research, analysis and experience and just read about it in the pages of the April edition of our print newsletter, Security Sanity™. Because in that issue, I talk about how you can cover your cloud *asS’s using between 34 and 42 SABSA attributes sprinkled across only 10-16 domains.
Maybe that sounds like a lot to you, but given that all this is grounded in the 23 predefined domains included in the Baseline Perspectives™ of The Agile Security System™, it means that a lot of the heavy lifting has already been done for you before you even think about cloud or no cloud.
Now, I know I’m a bit later than I’d have liked with this email, but I was a little busy so far this week as I’ve finally managed to clock some reasonable work time in and amongst the household chaos of #SAlockdown and 6 people under one roof with no place to go for over 2 weeks now. So I’m going to keep this one short (and there won’t be another one before the deadline either).
That means you only have just under 6 hours left to ensure you’re subscribed in time to get it delivered to your door after I send it to the printer later this week. And to do that, all you need to do is go right here:
May you have found a way to find some brief moments of calm amidst the pandemic storm and are managing to keep healthy and…
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
