As you might remember, the subject of the next Security Sanity™ print newsletter is all about security governance, and, governance in general within the concepts and foundational rules established by SABSA. And in talking to people about it a lot of the time, we get tangled up in assumptions about what we really mean when we talk about the fundamentals of security governance.
Part of the problem comes from the myriad of resources and standards that talk about it, and then immediately toss the cat amongst the pigeons right after they’ve said some pretty good things about the scope and intent of what security governance should be.
One of the most common threads, and one we all know by heart, is that security should be business driven. You can’t hardly pick up anything written about modern security without reading some variation of this mantra—and, that’s a good thing.
We know that security should support the business rather than security driving the direction of the business. We all know how it shouldn’t be done…
…and yet, in far too many organizations – for some reason – it just doesn’t seem to get there. And in many of those same organizations, there’s a claim of ISO 27000 ISMSs and robust and mature security governance programs, which, by the most fundamental principles, are supposed to be business-driven.
But they’re not.
Time and time again, there’s a massive disconnect between the mission and purpose of the organization, its strategic objectives and the mission and purpose of security.
And I’m just going to come out and say it: part of the blame is on the people who
- write said standards and guidance, and
- people who blindly implement them without really thinking about what they’re doing.
It comes back to the most fundamental question we need to ask:
What do you mean by “secure”?
And the whole shift to “cyber” everything hasn’t really done us any favors either. Sure, the pedants can define a clear boundary between what cyber is and isn’t—
but can your organization?
Do you really know the scope of what you’re trying to keep “secure”?
And if the answer to that is effectively IT or technology resources, then you have a built-in problem in your security program from the start.
Either you’re correct in following the principle of being business-driven, meaning that you, well…kinda need to know something about business, how it works, how business stakeholders think and how to speak to them in terms they care about INDEPENDENTLY OF IT…
…or, you’re correct in following the implicit and explicit directions on how to implement “business-driven security governance” by attaching yourself solely to IT like a parasite, believing that you can be business-driven-by-proxy if you’re aligned with the IT strategy and fully integrate your cybersecurity controls and scope within the bounds of your Enterprise Architecture program—assuming you have one.
However…this too is a foundation made of Jell-O, because in many organizations, “Enterprise Architecture” is really not the architecture of the enterprise. It’s really EITA, or Enterprise IT Architecture, that is potentially hiding behind its own onerous processes that don’t really integrate security or that follow a home-grown methodology only Dr. Frankenstein could love.
…and don’t even get me started about TOGAF and the published approach to integrating SABSA. Sure, it’s better than nothing—but it isn’t right either.
So if you’re leeching off EITA or IT, then there’s a fundamental assumption that THEY are going to be aligned to the business, and if you’re aligned to them, then, hey presto! You’ll be aligned to the business too.
And…this could happen.
But how do you prove it?
How do you prove you’re adding value to the business and being able to speak to the board about things that matter to them if the start and end of your world is the view you inherit from IT?
And we wonder why we struggle to get any kind of credibility as security.
Don’t get me wrong. There are organizations out there who get it right. And there’s a lot of them out there who are doing it without SABSA or The Agile Security System™ or anything like it.
But it still comes back to your definition of being business-driven and your approach to doing it. It’s a choice you need to make with your security program, and then it’s a choice you’ll need to be able to clearly articulate and communicate to all and sundry.
The reality is, while I have an opinion about what the right answer should be, that’s not really what’s important. There are many reasons you might not be able to practically do what you believe is right, instead having to manage with the environment you have and what you are able to influence.
That’s ok. That’s life.
Either way, you still have to be able to define what it is you do, and what you don’t. So my question to you is:
Do you have a good way to do this today?
If you wanted to prove you were aligned to the business, either directly or through IT as a proxy, how would you do it?
How easy would that alignment be for the people with the money you want to understand?
It’s far too easy to give lip service to being business-driven and aligned with an organization’s strategy. It’s much harder to actually do it, let alone prove that’s where you’re spending your time and budget.
If you’d like to understand more about the best way I’ve found to do this in my 25 year career, then you’ll need to make sure you’re subscribed to the Security Sanity newsletter before the deadline at the end of the month. To do that, you can go here:
Just don’t be delusional about how business-driven you really are with your security program. You’ll never be able to increase your credibility and trust with the business you’re trying to keep safe if you can’t demonstrate how your world tangibly connects to theirs.
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
