Pratum Blog

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

It happens every 3-5 years, especially at larger organizations. I'm talking about the switch from a centralized approach to IT and information security to a de-centralized approach. Then, a few years or leadership changes later, courses are reversed. It's an endless cycle I see regularly. So much time is wasted implementing the model of service delivery that sometimes not much service is ever actually delivered.

Why can't we pick a method and stick with it? Or better yet, blend the two so no matter who's in charge or what the analysts say, you can simply point out that we're somewhere in the middle and "leaning" one way or the other. Executives, I talking to you here. You need to think long and hard about changing the service delivery model at your organization. Is the change being called for by the organization's business units? If so, a change may actually be in order and it might stick after your departure which if current trends tell us anything will be in approximately 3-5 years. If this is simply something you want to do to put your mark on the organization, take a step back and re-evaluate.

While nobody wants to be stagnant, there is a fine line between change for improvement and revolutionary change. Now obviously I can't say one or the other isn't needed in your organization but what I can say is that sometimes we don't stop to evaluate which type of change we're making and why.

So…I know all the arguments on both sides of the centralized/de-centralized debate. Cost reductions, agility, consistency, compliance, integration, yada-yada-yada. Tell me your thoughts. Where is your organization, do you like it, want to change it? Go ahead…vent a little. You'll feel better.

A friend of my sent me this link recently about some researchers at UC Santa Barbara who took control of a botnet for 10 days earlier this year. I'd seen the report but never read the entire thing. (http://www.cs.ucsb.edu/~seclab/projects/torpig/torpig.pdf). He indicated that his company had been affected by a similar problem and suffered a leakage of data. This got me thinking about the principle of defense in depth.

Our information technology ecosystems are complex. There's no getting around that fact. As we build more functionality into them, we're loading the gun of our adversaries with ammunition to shoot right back at us. Trying to defend against an attack using only one defense mechanism is bound to fail. My dad was a career Navy man. I remember asking him one day why the aircraft carrier he was attached to had a "strike group" surrounding it. His explanation was…you guessed it…defense in depth. The submarines, destroyers and frigates that sailed with them were layers of defense to protect the carrier. Each had its own mission which overlapped with the other ships. This created a mesh for miles around the carrier which was designed to identify, intercept and if needed destroy any threats to the carrier. Should any of these defense layers not be deployed, there would be a gap or weakness in that mesh of security.

Companies often decide to only deploy one layer of security which targets specific threats that are seen as high probability. These companies often find themselves in a world of hurt. If that end node is compromised there is nothing to stop the trouble which is sure to follow.

If you rely solely on desktop malware protection then monitor your outbound traffic logs for inconsistencies such as lots of traffic to an IP or domain, spikes in traffic during off peak hours, etc. At least this way you'll know you have a problem and can begin to plan your response. Better yet…layer up your defenses at the network perimeter, interior network core and then at the end node. Hopefully through a layered approach you'll be able to identify, intercept and destroy any threats before the even come close to your data.

Get our blog posts delivered to your inbox:

The information we track while users are on our websites helps us analyze site traffic, optimize site performance, improve our services, and identify new products and services of interest to our users. To learn more please see our Privacy Policy.