Information Security Policy: Love Me, Hate Me
Ask any professional in nearly any trade what the secret to ensuring a repeatable process that works well is and they'll tell you…great policy/procedures/documentation. Everyone has a technique they think works better than others. Something someone discovered after completing a task multiple times, or maybe even just once. Ever wrecked a vehicle? I guarantee you don't need to do it a lot to learn how to avoid it. Why then do we continually try to reinvent the wheel when it comes to IT and our policy or procedures? We know some things work and others don't, however we never write it down. "It's all up here" we say pointing to the melon shaped object sitting atop our shoulders.
The problem is…how can we expect a process to be followed if we don't have a way to distribute it, train employees to follow it and check up on it? This is where the Love/Hate relationship begins. We love to have policy as it helps define our organization, gives us implementation guidance and sometimes even protects us. This is all fine and dandy when the policy doesn't impact our operations. When it does have a negative impact, either real or perceived, we go ballistic. We also typically loathe the process of creating policy. It tends to get bogged down in politics way too much and many we complicate the process due to one of the following...
1.) We either don't understand what a policy is and what it's used for or…
2.) We don't want to put in the effort to build an effective framework for use in the future.
Not having a firm grasp on either of these will doom your policy projects. One thing I've learned is that writing policy really is an art. It's something I've been doing for many years now and to this day I'm learning new tricks or techniques to improve the process. I'll share some of the points I've learned along the way in hopes of helping you navigate the murky waters we call policy development.
Policy has to be generic and specific at the same time. Talk about conflict of interest. You need the policy to be general enough so as leadership, technology, laws and other external forces change, your policy hopefully will still be valid and not require significant reworking. The approval process at most companies for policy which has global impact is tedious, time consuming and most importantly, POLITICAL. You want to avoid this whenever possible. So while being as general and non-committal as possible you need the policy to have some sort of bite. It needs to be clear what the general preferences of the organization are.
Policy is only a guide. It's a statement that management agrees a specific issue needs to be address and generally how they want to see it addressed. It is not a roadmap to remediation so don't try to make it one.
Policy alone isn't sufficient. It takes a full set of documentation to manage risks and have any reasonable assurance of information security and privacy. Here are the 4 basic types of documentation you need.
Policy – General accepted principals of an organization
Baselines – Standard accepted configuration for hardware and software. Deviations require risk assessment and management approval before being implemented
Procedures – Set of detailed instructions for how to implement security controls, manage changes, identify risks and remediate gaps.
Guidelines – When no specific instruction is given, use these "common sense" principles as a guide.
Policy should identify responsibility and authority. If everyone has input into every baseline or procedure that is created, you'll paralyze your organization. Policy should state who is responsible for implementing each section and what authority they have. In this mode, the server group may be responsible for creating the baseline for server hardware or OS configurations, but the application group gets to review it prior to being published in order to ensure their needs are met as well. Each organization will implement this a little differently however the main idea to remember is limit the number of people who have to sign off. Don't leave out true stakeholders but don't give groups outside of the process too much weight in the decision.
Train your users. Telling them a policy exists, find it…follow it…simply isn't enough. It shows a certain callousness on the part of the employer and more importantly would not hold up in court if you policy is challenged for any reason. If the policy is really that important to your organization then provide some training.
Review policy on a regular and frequent basis. For corporate level policy, annual reviews should suffice. For baselines or procedures quarterly might be better. Whatever schedule you choose, document this in your policy and follow it. Not reviewing policy can be as bad as not having it to begin with.
Following some of these simple guidelines will help you have some assurance of the safety of your systems when developing policy in conjunction with the things you learned about your organization during the risk assessment I spoke of in the first article in this series.
