One of the things that’s even harder to talk about with organizations than security architecture is security governance. And the reason I think this is true is that people have the wrong idea about what security is supposed to do in the organization.
They think we’re the police, so naturally, the only thing we care about are the controls that enforce the “laws” or the policies of the organization.
This line of thinking naturally leads to an assumption that when you talk about “security governance” what you actually mean is something more akin to “control governance.”
Are the controls we have running and working properly?
Are we executing the right processes and procedures when things go wrong?
Are we following “standard” control libraries and frameworks (we can hide behind when the auditors come because we really have no idea what the real security requirements actually are)?
If we’re going to have any chance at all of building more effective security controls, we need to break this incessant fixation on the controls and the assumption that security = controls.
It’s just not true.
Security keeps you safe when you’re trying to do whatever it is you want to do.
Sure, there are controls involved. There will always be controls involved, and yes, those controls will need to be operated…
…and operating those controls and taking the right actions in response to what they tell us or when the situations in our environment require it.
If you look at the definition in even a simple dictionary, you’ll find that to govern is:
“conduct the policy, actions and affairs of a state, organization or a people and to control, influence or regulate a person, action or course of events.”
That’s basically out of Apple’s dictionary, but if you really think about what it says, the order is really wrong, because how do you know:
…what the policy should be?
…what actions are really a priority?
…what affairs must be managed?
…what people should be controlled or influenced, and in what ways?
…which course of events matter most?
And here we hit another problem: the chicken-and-egg relationship between strategy and governance, because “conduct” in the definition above, means to manage, as in the management of an activity or an organization.
How do all these things really fit together—especially for security?
It’s really no wonder people find something easy like controls, and say, well, we know the controls in our environment, and we know where they are, and we’re monitoring the logs, and the controls are how we deliver security, so yeah, we’re “governing” security.
Because it sounds soooooo much classier than service management operations.
But this whole set of relationships is a muddy mess of misunderstanding, and we’ve gotta untangle it and make it crystal clear what role governance should play in building an effective security program.
If you want to get the answers to some of those questions delivered to your door before Christmas, then get thee on over to this link:
…and subscribe to the print Security Sanity™ newsletter before the end of November. The whole issue is going to be about defining the role of governance in an effective security program and how this can be accomplished through The Agile Security System™ and its SABSA foundation.
And, remember, by effective, I mean a security program that is truly able to demonstrate in concrete, tangible ways that are easily communicated to business leaders that it is enabling the business to deliver its own mission as quickly and safely as possible.
If you’re struggling to do that today, then some of the advice in the newsletter will give you some things you can start doing the very day you read it to start making that easier to do—no matter what level of “maturity” you have in your organization.
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
