• Strategy
  • Risk
  • Governance
  • Compliance
  • SABSA®
  • Login

Archistry

exceptional performance since 2006

  • Home
  • About
  • Courses
  • Bookstore
  • Glossary
  • Contact
You are here: Home / Archistry Daily / How to turn 53,426 words of security policy into usable security architecture

May 12, 2020

How to turn 53,426 words of security policy into usable security architecture

Photo by Amy-Leigh Barnard on Unsplash

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:

https://archistry.com/besa

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

Article by Andrew Townley / Archistry Daily / Agile Security, BESA, Policy Architecture, Policy Engineering, SABSA, Security Policy Leave a Comment

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

  • Email
  • LinkedIn
  • Twitter
  • YouTube

EMAIL NEWSLETTER

Want to get DAILY email tips on how to build a more effective security program so you can prove your security investments deliver value to the business?

You can always unsubscribe at any time, and we won't sell your data to third parties.

About Us

Archistry works with you to ensure what you want to achieve actually gets done, linking strategy, risk, governance and compliance to enable sustained exceptional performance Read More…

Testimonials

Andrew is a highly skilled and experienced information systems architect and consultant, which in my view is a rare thing. He is innovative in his thinking and merits the title of 'thought leader' in his specialist domains of knowledge—in particular the management of risk. Andrew has embraced SABSA as a framework and, in doing so, has been a significant contributor to extending the SABSA body of knowledge."

— John Sherwood, Chief SABSA Architect

"Fabulous person to work with. Very engaging and insightful. Extremely good technical knowledge with ability to relate concepts together and overcome differing opinions. Makes things work."

— Kevin Howe-Patterson, Chief Architect, Nortel - Wireless Data Services

"Andrew was able to bring clarity and great depth of knowledge to the table. His breadth of thinking and understanding of the business and technical issues along with a clear and effective communication style were of great benefit in moving the process forward towards a successful conclusion."

— Doug Reynolds, Product Manager, MobileAware

"Andrew is a fabulous consultant and presenter that you simply enjoy listening to, as he manages to develop highly sophisticated subjects in very understandable way. His experience is actually surprising and his thoughts leave you without considerable arguments for any doubts in the subjects he covers."

— Biljana Cerin, Director, Information Security and Compliance

Recent Posts

  • The real difference between architecture and engineering
  • The myth of the isolated project
  • The boneyard of failed architecture initiatives
  • To re-architect or not to re-architect your security controls
  • Afraid up-skilling your security team will train them for their next job?

Looking for something else?

Archistry

Practice Areas

  • Strategy
  • Risk Management
  • Corporate Governance
  • Compliance
  • SABSA®
  • Home
  • About
  • Courses
  • Bookstore
  • Glossary
  • Contact

  • Terms of Service
  • Privacy Policy
  • Cookie Policy
  • Copyright © 2006-2023 Archistry Incorporated or its affiliates

"Archistry", the stained glass window logo, "Pragmantix" and the Pragmantix™ logo, "Archistry Execution Framework (AEF)", "Archistry Execution Framework, Cybersecurity Edition (ACS)", "The Agile Security System", "The Agile Business System", "Baseline Perspectives", "Architecture Wall" and "Archistry Execution Engine" are trademarks of Archistry Limited.