Of Policies & Plans

We here at Pythia Cyber are big believers in rigor so we strongly recommend following a rigorous framework when building your cybersecurity program (CSP). We use the NIST CSF by default but we recognize that there are a few other frameworks which will also do the trick.

We seek to season cybersecurity with behavioral science because human behavior is a huge but rarely addressed part of running a CSP. Those who run the CSP are humans. Those who follow the CSP are humans. Those who work to subvert or circumvent the CSP are humans. There is much that is NOT cyber in cybersecurity.

There are few places along the path to a great CSP where being human is more evident than in the writing of policies and procedures. The point of these documents is to inform, not impress. The goal is to guide human behavior in times of stress, so clarity and accuracy are of utmost importance. Length or literary flourishes are worse than irrelevant, they are an impediment to being useful in times of stress and urgency.

When writing policies you should bridge the management domain of "what we need to protect" with enough of "why this is a priority" thrown in to support all the value judgments that go into writing procedures based on those policies. The policy is never an end in itself, it exists only to guide the operational people in writing the procedures on which you will depend to guide you in times of disaster.

Always keep in mind that the policy links management priorities with operational priorities. Every policy should be as short as possible while being as complete as needed. That is a tall order. For myself, I like to use the Ten Commandments as an example of pith and clarity.

(Obviously your policies will have to be a bit more detailed that the Ten Commandments and will likely be received with a bit less reverence.)

Once you have a policy you have a statement of what management wants to happen. From this your operations people should be able to write specific instructions about what operations thinks should happen.

Where the policy should balance "what" and "why," the procedure should be mostly about "how." You shouldn't rely on a pure recipe because whoever is executing the plan in the heat of the moment needs enough context to be able to carry on even if your plan is wrong or out of date in small ways. But neither should you expect whoever is carrying out the plan be expected, under pressure, to improvise important steps or roll the dice on critical questions.

Always think of whoever is going to carry out your plan. Even if you think that you will be the one carrying out the plan.

Few experiences are as humbling as carrying out one's own Respond plan and discovering just how vague you were in some parts and just how many details you got wrong or have changed. I have carried out my own plan in front of an audience and been quite embarrassed as we all realized that had I not been there, the plan would have been hard to follow. Many were the notes I took that day. Many were the notes I got from others. Many were the revisions made to the plan when the dust settled. Yes, it all worked out just fine. No, no one was comfortable with the requirement that I be present for maximum chances of success.

Not that you will ever avoid revisions after the dust settles. Ideally you compare notes with the operations people about how easy the plan was to follow, then you check with the users about how the actions affected their work and finally you circle back to those responsible for the policy to make sure that the procedure actually did what the policy required.

The different audiences with differing agendas are why we do not recommend leaving all the writing to a small group. Better a blandly worded but clear policy than a beautifully written unclear on. Better a boring procedure that anyone can follow, with enough context to handle curve balls, then a cleverly compact procedure that is hard to implement.

The good news is that you are not being graded on style, only substance. The bad news is that failing to get this right will have real world consequences.

Don't let the perfect be the enemy of the good. Don't wait to get started. Don't skip steps: the managers need to write policies so that operators know what to protect and how best to protect that. Operators need to write procedures because disaster is rarely scheduled and the procedure needs to work no matter who ends up following it and no matter how many small things have changed or been gotten wrong.

Making sure your CSP has a sound foundation is hard. We can help. Ask us how.