The issue of policy writing has never been an easy one, but one way to tackle the problem is to find a way to get user sign-off.
How often have you heard, “I’m not sure you can do that; there isn’t a policy in place?” I hear it too often, because I hate writing policies. And I hate writing policies because at a very engineering-centric company like mine, generic policies don’t go over well.
If I were to write a policy stating, “No running with scissors,” I would be asked to define “running.” How fast can you walk before it counts as running? Does the policy apply to small, blunt scissors?
So, when I write information security policies, there’s no such thing as being too specific. I tried to keep our acceptable-use policy fairly generic, not mentioning any specific applications or technologies.
Afterward, when I found out that a business unit was using Skype, the manager said, “Show me a policy stating that Skype is considered unacceptable use.”
He argued that his department’s use of Skype was saving the company money and increasing productivity, while I countered that Skype is a risky application. His argument held sway until I rewrote the policy to call out specific popular but risky programs.
More recently, I wrote a policy to ensure that all devices on the production network are properly patched. A security assessment had demonstrated the immediate need for such a patch management policy.
But the network manager pointed out that in the Cisco world, devices don’t get “patched” – they get a complete IOS revision. She knew exactly what I was referring to, but she wanted the policy to be called the “security software update policy.”
Her feedback was part of our peer review process. Although peer reviews take more time – because you have to submit them, revise them and resubmit them – I like this approach. For one thing, it helps ensure that policies are enforceable. The network manager might note that a policy’s wording would require redesigning the entire network, dooming the policy to failure.
Peer review also means no policy comes as a surprise. And the process is respectful of peers. It keeps me from churning out policies that generate resentment. Nonetheless, all that negotiating of terms and content is policy hell for me.
Grabbing attention
One problem with policies is that once they are published to a Web site, they languish until someone asks, “Do we have a policy regarding such and such?”
That passive approach may be fine for many policies, but others need to be actively promoted. Several months ago, an employee uploaded algorithmic code to his Yahoo “briefcase.” In the end, we couldn’t prove if the employee knew that he wasn’t supposed to transfer code to a personal account even if his intention was, as he said, to work from home on the weekend.
This incident shows that we need a way for employees to electronically sign off after reading important acceptable-use or intellectual property protection policies. Such a tool would also be a way to generate general security awareness. Video might be a particularly effective way to make sure our important policy messages stick in people’s minds.
I will start the hunt for vendors that offer policy and security training, and that provide compliance training tools, and I’ll report back in a later installment. Until then, it’s back to policy hell.
This week’s journal is written by a real security manager, “Mathias Thurman,” whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@ yahoo.com.
Related content:
Why business models matter
MITS, The Grey, The Dark and The Dirty
