Here’s an interesting question for you to think about:
What’s the relationship between security policy and security architecture in your organization?
I mean, how related and/or connected do you think they are?
True story: In one of the organizations I work with, they actually had a fairly good structure and scope to their information security policies. There weren’t too many of them, and the structure was pretty clear overall.
The problem was: apart from select members of the security team who’d been there for years and had created their own mental models of what those policies actually said in their heads…
…it was hard for anyone else to really know what was in them.
The general approach for using them was pretty similar to what I’ve seen in most organizations. Security would say, “Here are our security policies. Make sure you comply with them.”
The IT development teams would go develop their solutions, and when they were done, they’d get to the “Security” stage gate in the process. They’d reach out to their security team colleagues, and say, “Can you please give my project a security approval so we can deploy it?”
Security would ask them, “Did you follow the policies?”
IT would say, “…”
Security would then do a risk assessment on the project and deployed solution, come up with a list of findings, reference the appropriate security policy sections IT hadn’t bothered to follow, and then say, “Until you either accept these risks (using a hand-written signature, mind you—though not in blood) or you implement fixes and show how you follow the policy, your measly little project ain’t a goin’ nowhere, Mister.”
Which, of course, went over oh, so well…
When I started working with them, we all agreed that this approach had to change, and we did some ESA work to figure out what the real enterprise security architecture should be. Then we worked on changing the process to make sure security was involved earlier and we were doing SABSA iterations in the right way at the right time.
However, we still had a problem.
53,426 words of security policies.
Policies that were there, formally approved by basically an act of God, printed, signed and re-scanned to prove that these were the “real-deal” security policies, and then placed on an enterprise knowledge management system for everyone to read, memorize and incorporate into their daily behavior.
But what the hell did they really say? And how close was what we already had (which was, of course, the basis of the operational control environment) to what we’d engineered as the “proper” security requirements and controls that would support the business?
What would you do?
How would you solve this problem?
Oh, and…did I mention that while they did have an “enterprise security architecture” in name, it was not only effectively locked in a drawer that nobody had done much to put into actual daily use, the “bottom” of the scope stopped some 60,000’ above where the day-to-day security and IT decisions needed to be made?
Oops. Sorry about that. At least, now you know.
You might remember me talking about “middle out” architecture – or what I define as “architecture archaeology” in Module 3’s Lesson 9 of the Building Effective Security Architectures program – at some point before. Basically, this is the process of digging up fossils, pottery, poop and clues from historical artifacts – just like a real Archaeologist does when they’re digging for Diplodocus bones – so you can use whatever it is you find to try and reconstruct the skeleton…the architecture that was present when those artifacts were created.
Sometimes this is a tough job, because that architecture wasn’t ever formalized, and, as a result, there’s a damn good chance whatever you find is going to be confusing, conflicting or down-right illogical, so, despite your best efforts, you might end up making some massive mistakes like:
Thinking the thumb of the Iguanodon was actually a horn on its nose,
That Tyrannosaurs sat on their tails like Kangaroos, or, my personal favorite,
That the Stegosaurus had a brain in its butt.
And, in fairness, if you’re forced down the path of architecture archaeology, then you’re really only as good as what you have to work with. That’s why understanding, creating and maintaining architecture properly is such a big deal.
Anyway, the solution to the 53,426 word policy problem was to build a SABSA architecture out of it so we knew what was there, and could figure out how to work with it going forward to bring it forward into the brave new world.
But, I can tell you…if you don’t understand SABSA properly, and you think that it’s this big, massive process that’ll drown you under something grander than the Victoria Falls…
…and ESPECIALLY if you think that applying SABSA in practice is starting at the upper-left cell and working your way downwards to the bottom-right corner of the Architecture Matrix…
STOP!
Do not pass Go.
Do not collect your functional, useful and genuinely informative security architecture.
And, after yesterday’s emails, I’m not even going to toss in the caveat about it being a whole lot more than an infrastructure diagram of the placement of your security control implementation technologies.
Now, maybe you can do it without any of the core concepts and techniques of SABSA. Or maybe you’ve already developed your own approach to using SABSA to solve this problem.
All excellent places to be. And, I’d genuinely love to hear more about it if you’re willing to share. Just reply to this email.
However…if you feel a bit overwhelmed by a task like that, and you don’t really have a strong link between your security policies and, well…
…anything…
…except maybe cross-references to the CSC Top 20 or NIST 800-53 or your current favorite flavor of control library…
…then maybe it’s time to fix that problem.
And, I know how you can fix it for good. No, it’s not a “fire and forget” type of exercise for only one set of 53,426 words of organizational security policy, because if it was just that…
…you’d be well and truly screwed when the next set of policies came around…
…or you changed jobs…
…or someone decided that there was a new control library in town that everyone needed to worship.
No, I’m talking about building the skills to be able to do it reliably and efficiently—each and every time it becomes necessary.
Oh, and also how to be able to scale that effort intelligently based on the time you have for the exercise, because I can tell you from experience, you can probably at least get 70-80% of the gist of it in a couple of hours—and without reading each-and-every-one of those 53,426 words.
Yes, there is a trick to it. And it’s a trick that I first introduce in Module 1 of the Building Effective Security Architectures (BESA) program I mentioned above, and that “trick” is something I ask you to practice over and over again through all 6 sets of exercises you’re asked to do during the program. And I do this because that one simple thing is so important that it’s one of the key practices of The Agile Security System™ that enables you to “think in SABSA” once you’ve practiced it to the point it becomes a habit.
Now, maybe this doesn’t sound interesting or useful to you, and that’s totally fair. It’s not for everyone, and you might be confident (if not mistaken, at least in my opinion) that you can be a truly effective security architect without actually applying SABSA at all. Maybe it really is “just another matrix” or “just like Zachman, but for security”…
…or, my personal favorite, “I’m already TOGAF certified, so I know all the security architecture I’ll ever need to know.”
But, if that’s where you are, it’s good to be clear about it, because I can tell you that you’re much better off saving the money you’d invest in the program and, I dunno, going on a trip to the beach with your family, friends or significant other, because – at least right now – the BESA program DEFINITELY is not for you.
On the other hand, if you do think it’d be kinda handy to devour your security policies and figure out what they are (and aren’t) supporting…and have a much better chance of identifying any security and control gaps before the bad guys do it for you…
…then there’s a good chance that the program is something that will make a difference—both to you and your organization.
To learn more about how it works and what I cover in the rest of the modules over the 7 weeks of the program – and why we run it as a remote-based, real-time cohort rather than as a go-at-your-own-pace individual experience – go ahead and check out this link:
And, at the time I’m writing this email you still have just over 37 hours to register and still get $2,000 off the regular price of the program. After 11:59pm US/Eastern tomorrow, the price increases by $1,000.
Now 37 hours might seem like a lot of time, but it really isn’t. So if you’ve been debating whether you’re going to join the July cohort for the last 7 days I’ve been talking about it, then I’d say we’re getting close to time to make a decision. If you’ve decided it’s not for you, that’s totally cool.
But if you’ve decided it’s something you should do, well…all I can say is, “You’d better get hoppin’, Harvey!”
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
