Policies don’t have to be painful

by James Costello

Several years ago, one of my clients asked me to write a security policy for them (since I was the “Security Guy” at the consulting company they employed).  I spent a couple of hours looking at various templates and examples on the Internet.  What I found were a lot of carbon copies of the same few templates with “insert corporate name here”. Regardless, I created a security document for them; my client was happy to have something and I was able to help them out, but I was not really satisfied with what I had written and wanted to do better.

Recently, I’ve been working with a team to rewrite the security policies for my current employer; policies that look exactly like the one I put together for my client years ago. The review of the current documents made something clear to me: No one likes to write these documents, so they use templates as a quick way to get the job done.  Unfortunately, the template-based policies can be difficult to read through for people who need to work on them, and will most likely be unread by the employees who will be most affected by them.

So what can we do, dear reader?

I am going to start by defining policy this way:  A policy is a set of rules that supports an overall vision. This policy is developed using a set of standards, which are incorporated into procedures to implement the policy. For example, if the concept is that the company’s wireless network should be secure, the policy would state that technologies will be used to secure wireless communications on corporate sites. The standard would be that the general public would not be able to connect directly to the corporate network via wireless networking. The procedure would be to use WPA2 configured on the access points.  If a new technology comes out that proves to be more secure than WPA2, the policy does not need to be rewritten; just the procedure.  There can also be multiple procedures for the same policy, e.g. the procedure to implement WPA2 on Windows is different from the procedure to implement it on Linux.

It’s simple: The vision is the overall goal. The policy supports the vision, the standards measure how the policy relates to the vision, and the procedures support the policy.  Procedures should not typically be included in a policy document because they can be more dynamic and will change more often than the policy will.  In my current organization, policies have to be approved by the Executive Management team, and it can take as long as a month for one sentence to be approved.  Instead, procedures should be established at the team level and reviewed by direct management, so that changes to the procedure can be implemented quickly while still supporting the existing policy.

One of the best references I have found for this policy style are the PCI-DSS documents.  Vision, policy, and standard are established, and the procedures are left up to the individual companies.  The documents are easy to read and reference, and can be a great starting point for companies to examine how their own security policies are written.  Not everything in the PCI-DSS documents will be applicable to every organization and I do not necessarily agree with everything in them, but they are quite useful for readability and review by non-IT security staff.

The simple steps to follow to build your own company’s security policy:

1. Establish the vision.
2. Write the policy to support the vision.
3. Develop standards to measure the policy, and finally
4. Create the procedures to implement the policy