According to the WHO, the effectiveness of seat belts in worldwide studies is about 50% in avoiding the loss of life during a car crash. This is pretty concrete, and the studies have been validated since the ‘60s in some form or another, so there’s a pretty high confidence in that probability.
However, our friend, the NIST CSF, tells us that it’s a framework intended to provide a “risk-based approach to managing cybersecurity risk” which “may be voluntarily adopted by owners and operators of critical infrastructures [and other parties] to help them identify, assess and manage cyber risks.”
And, according to what it says, it’s even “business driven” because it explicitly mentions how profiles, if you bother to create them, can be used to “help an organization to align and prioritize its cybersecurity activities with its business/mission requirements, risk tolerances and resources.”
…because you’re clear about all those in your organization, right?
I won’t bore you with any more quotes, but I do want to point out some points in favor of the NIST CSF. it was:
…designed by committee
…has the appropriate get-out clauses and waffle words to make it basically fit whatever you might choose to do with it
…and it still ticks the box as a control list of “industry best practice.”
I mean, what more could there be to love?
Yes, I’m railing on the CSF just a bit because I read something the other day that mentioned how boards should be asking their security teams how they’ve aligned with industry standard best practices and standard frameworks to give them confidence that they can be externally assessed for compliance with the framework.
And we know that just because you’re using your seatbelt, if you’re driving 120 mph through a school zone, high on crack and with your hair on fire…
…you’re still wearing your seatbelt. Everything must be A-OK.
The reality is, the NIST CSF isn’t all that bad. There’s some good things it’s done to standardize practices – or at least conversations about security in various parts of the globe – and, at the end of the day…
It’s not likely to disappear anytime soon.
That means we can either bitch about getting lemons, or we can make some kick-ass Caipirinhas and just get on with it.
I’m going with option b, and might I suggest that they go extremely well with a dish from Bahia called moqueca, which incidentally sounds closer to khak-a than it does for the Spanish word for poop.
So why am I telling you all this, you might rightly ask?
Well, let’s say you’re in an organization that uses the CSF as it’s “gold standard” for cybersecurity coverage, and let’s say that you’re trying to build proper, business-driven SABSA security architectures, and let’s say that you don’t want to engineer the whole flippin’ thing
…or, incidentally, justify why the whole of §3.2 Establishing or Improving a Cybersecurity Program schizophrenically oscillates between strategy and design activities faster than a nerdy teenager debating whether he’ll try to ask the token “hot chick” to dance with him at Homecoming…
then perhaps you’ll find a use for the hot-off-the-presses Bonus #4 included with your pre-order of The Definitive Guide to The Agile Security System™. I’ve been sitting on this in draft form for some time, and I’ve even used parts of it with some of our clients—or advised and validated theirs when they’d rolled their own. So, I guess, if I’m doing the whole CIS20 thing, I might as well throw in the Archistry Guide to Using the NIST CSF too.
Like Bonus #1, it’s engineered based the control objectives of the NIST CSF to show you what is really important and implied by the framework and how it does or doesn’t give you the coverage you think across the Baseline Perspectives™.
But it also talks through the steps of the process steps to create or improve a cybersecurity program and compares them to the SABSA core lifecycle and architecture layers. The results might surprise you slightly…or maybe they won’t.
And it gives you 24 attributes, 22 domains and 105 domain and attribute mappings to chew on—just from the descriptions of the core categories alone.
I won’t go through the whole spiel again, because we’re almost across the line with the 10 required orders to make this whole package come to life, and you already know the drill.
If we get just a few more expressions of interest – that means orders – before tomorrow at midnight, then the whole project goes ahead with some more bonus items I’ll talk about tomorrow.
My objective here with all this is to really help you improve not only your architecture practice, but the effectiveness of your security program overall. And I talked to a couple more people today who were lamenting about board-level approval for framework adoption who seem to think that a grassroots architecture and security program improvement isn’t possible…
…or maybe they think it’s just not worth their time.
If that’s you, then yeah, this book and all the bonuses based on my own 14 years doing this for real around the globe (and teaching it to over 200+ people too) probably isn’t worth the glowing bits you’re reading now.
But if you do want a simpler way to do real architecture that you can apply whether your manager, the board or your grandmother gives you permission, and you’re prepared to do the work to learn it when it’s spelled out in front of you, then yeah, you might find the book useful.
It’ll ship mid-January if we get the orders, and it’ll never, ever, not-in-a-bazillion-years be $247 again. On Friday, the price goes up over $100, and in January it’ll be about 5 Ben Franklins.
If you’re in, you’d better hurry and order the book and all the bonuses with this link:
If you’re not, that’s totally fine. I don’t need any drowned, dead horses on my watch. There’s only so much I can do.
Andrew S. Townley
Archistry Chief Executive
P..S. And if you’re interested in subscribing to the monthly print Security Sanity™ newsletter where The Agile Security System™ first appeared, you can start with the next issue here: https://securitysanity.com