Hint: Be wary about policies in a vacuum
“We need a policy on that.”
This is a phrase that seems to act as a universal panacea to too many managers. When a problem is identified, and the blame game has been played out, the way forward is usually to create a policy. If you’ve got a policy, then everything will be fine, because everything will be clear and everyone will obey the policy, and nothing can go wrong. Right?
The problem is that policy, on its own, is worthless. A policy, to have any utility at all, needs to exist in a larger context to have any real meaning.
When that manager said that they wanted a policy, what did that actually mean? Usually, the reason that the manager identified the need for a policy was that they noticed that something had gone wrong that shouldn’t have and they wanted to have a way to make sure it didn’t happen again.
A policy in a vacuum doesn’t actually help with either of those points. What should we be considering, then? A holistic security framework made up of:
- Governance models
- Processes
- Policies and auditing
Let’s look at those pieces separately.
Step 1: Governance models
When we say that “something had gone wrong that shouldn’t have“, what we’re saying is that there is some sort of model for what the world should look like. Sometimes this is a legal framework, sometimes it’s a regulatory framework, and sometimes it’s a looser governance model. The sort of thing we can expect to see at this level would be statements like:
- patient data must be secured against theft
- details of unannounced mergers must not be made available to employees who are not directors of the company
- only authorized persons may access the military base
These are high-level requirements and statements of intent. They don’t tell you what to do in order to make these things happen (or not happen), they just tell you that you have to do them (or not do them). Collections of these types of requirements are called governance models. And once they are defined, we can go to step 2.
Step 2: Processes
At the other end of the spectrum, you’ve got the actual processes required to make the general intent of the governance model happen. For the examples above, they might include:
- AES-256 encryption using OpenSSL version 1.1.1 FIPS, with key patient-sym-current for all data on database patients-20162019
- Documents to be collected after a meeting and locked in a cabinet by the CEO or CFO
- guards on duty must report any expired passes to the base commander and refuse entry to all those producing them.
These are concrete processes that must be followed, which will hopefully allow the statements of intent that we noted above to be carried out.
Step 3: Policies and auditing
Once you have identified the governance statement (for context) and some key processes, it’s time to create policies to round out what to do in eventualities and ensure these are auditable for continuous learning.
Remember, the governance statements don’t tell you how to do what needs to be done, and the processes are context-less, which means that you can’t tell what they relate to, or how they’re helping. It’s also difficult to know what to do if they fail: what happens, for example, if the base commander turns up with an expired pass?
Policies are what sits in the middle. They provide guidance as to how to implement the governance model and provide context for the processes. They should give you enough detail to cover all eventualities, even if that’s to say “consult the Legal Department when unsure.”
What’s more, they should be auditable. If you can’t audit your security measures, then how can you be sure that your governance model is being followed?
Policies, then, should provide enough detail that they can be auditable, but they should also preferably be separated enough from implementation that rules can be written that are applicable in different circumstances.
Here are a few policies that we might create to follow the first governance model examples above.
Patient data must be secured against theft:
Policy 1: all data at rest must be encrypted by a symmetric key of at least 256 bits or equivalent;
Policy 2: all storage keys must be rotated at least once a month;
Policy 3: in the event of a suspected key compromise, all keys at the same level in that department must be rotated.
You can argue that these policies are too detailed, or you can argue that they’re not detailed enough: both arguments are fair, and the level of detail (or granularity) should depend on the context and the use to which they are being put.
Either way, ensure your policies are all:
- auditable
- able to be implemented by one or more well-defined processes
- understandable by both those who are concerned with the governance level and those involved at the process implementation and operations level
For more get our white paper on managing risk.