Trans World Solutions Inc.   

6 Myths About Security Policies

Leave your preconceptions behind and write policies that work in the real world

BY Al Berg

As a technical director in my company's corporate infosec department, I assumed I knew all I had to know about writing information security policies. After spending a lot of time in the past year as part of a team assigned to update and enhance our organization's policies, I can say without qualification that most of my assumptions were wrong.

My company (I can't tell you the name, because that would be against our information security policy) delivers services to the financial sector. Our original infosec policy was written back in the days of the dinosaurs--1995. It was a simpler time. We connected to our business partners over leased lines and knew who was on the other end. Our systems were isolated, aside from a dial-up here and there. The Internet was a fad--why would we ever connect our mission-critical networks to it?

Fast-forward to 2001. Our business partners now used value-added networks and the Internet to send us important stuff. E-mail had become as important as the telephone, and we were doing business on the Web. Our world had become more complex. Our policies were seriously in need of an update.

In the course of working on the new policies, I learned the truth about my assumptions, which I now call the "Six Myths of Info security Policies."

Myth 1: Information security policies are the foundation of an effective infosec effort.

I know, I know, this is heresy. We've all been told that infosec policies are the foundation on which all our security efforts are built. Not quite. Developing information security policies should be your second step. Your first priority is to develop a way to quantify and evaluate risk. You need to know what you are protecting and how much it's worth before you can decide how to protect it.

Writing policies that require you to spend a million dollars on information security might make sense if you are protecting the formula for Coca-Cola, launch codes for nuclear missiles or some other vital information asset.

However, nobody has an unlimited security budget, so you need to be able to look at all of your systems and data to determine the appropriate level of effort and expense.

Risk assessment is a lot of work, but when you're done, you'll know:

• What your organization's information assets are.
  
• Which information is essential for keeping the lights on and the profits coming.
  
• What kinds of risks you need to guard against.

Risk assessment is a bit like tennis--you can't play alone. In most organizations, the required knowledge and resources are spread out across the business units. Through a proper risk assessment, you'll get to know lots of people from all over your company and learn a lot about how the business really works.

Myth 2: Information security is a technical issue.

Does your encryption policy state that "all data must be encrypted with the WhizBang 4.3 cipher and 128-bit keys?" If so, it's time to take a step back and look at what policies are. Repeat after me: Policies are not technical manuals.

Info security policies are statements of your organization's approach to keeping its information safe. They're high-level directions from management to the troops. Policies don't specify how to get something done; they simply dictate that a goal be accomplished.

For example, a policy having to do with encryption of sensitive information might contain this language: "Whenever information classified as confidential or highly confidential is stored on a computer or transmitted over a public network, it must be protected using encryption hardware or software approved by the corporate information security department." There are a few things you should notice about this statement:

• It's very simple, non-technical and sounds like something that a senior manager would say. That's good. After all, policies are supposed to provide overall guidance to the organization.
  
• It states a goal and high-level parameters for reaching that goal.
  
• It doesn't specify what technologies are to be used, or how they are to be configured.
  
• It's measurable. When audit time rolls around, it will be possible to "score" departments on compliance.
  
• It won't have to be changed just because a new encryption algorithm is published (or the old one is broken), or because your encryption vendor goes out of business.

You can compare info-security policies to the U.S. Constitution. The Constitution doesn't provide details like parking ordinances or building codes. However, every law, from the federal government down to those passed in the smallest town, can be traced back to the Constitution. Like the Constitution, info-security policies provide the framework for all of the day-to-day rules and regulations we use to keep our systems safe.

Myth 3: You need many layers of documentation to support your policies.

Just because you put lots of time and effort into writing policies, don't assume your coworkers can or will do the same. Make life simple for yourself and your colleagues. Once your policies are in place, write a set of standards to explain how people and departments can comply. For example, a Standard for Encryption for Mobile Computers in support of the sample policy we talked about above might include these elements:

• All mobile computers running Windows 2000 shall be configured to automatically encrypt the Documents and Settings folder and all of its subsidiary folders using the built-in Encrypting File System (EFS).
  
• Users must store all corporate documents and information in the encrypted portion of the disk drive.
  
• The network support department will keep custody of the EFS recovery keys to allow retrieval of data from mobile computers. These keys must be stored in a secure repository, accessible only to the network support department manager and the internal audit manager.

Other standards that might be written in support of the encryption policy could include how to protect information stored in PDAs; when and how e-mail messages must be encrypted; and what encryption products may be used in writing software for company use. Concise standards documents provide many important benefits:

• New technologies can be addressed without having to revisit policy. Remember, policies are statements of business goals and directions. They shouldn't become obsolete because of some software upgrade or less-than-earth-shattering change in technology. Policies should last a few years.
  
• Differences in how various departments do business can be accounted for. There's no reason that standards documents can't be written on a departmental level, as long as they comply with the policy. Going back to our encryption policy, maybe the information on the strategic planning department's laptops is so secret that the entire hard disk needs to be encrypted using a solution with a removable hardware key. The departmental standard can say so.
  
• Bite-sized standards are easier to digest. Not everyone in your company finds access controls, encryption algorithms and firewall rule sets fascinating. When people are looking for the answers to their security questions, don't make them wade through tons of material to find what they need.
  
• Timing is important. The moment new policies are released, the anxiety level in your organization will increase. People will want to know exactly what they need to do to comply with the policies. It may make sense to release the policies well before their effective date, which gives people a chance to read and digest them, and then publish standards to deal with the most common and urgent issues promptly.

Myth 4: If you build it, they will come.

Right after you post the new corporate information security policies on the company intranet, you notice that your inbox has 843 new messages--all from angry, anxious and confused colleagues who see your "masterpiece" as more of a "disasterpiece." All they can think about is the extra work you have imposed on them and the budget dollars they don't have to put the policies to work.

New info-security policies shouldn't be a surprise. The process of writing policies is a group activity. You need to include representatives from the business units from the start. Write draft policies and ask people how the policies will affect the way their departments do business. For example, we originally wrote policies that would have prohibited any non-company-owned machines from being connected to our networks. But we learned from our business units that a number of in-house consultants use their own laptops, and many employees take work home and connect via VPN from their personal systems. There wasn't room in the budget to buy computers for all of these folks. We went back to the drawing board and drafted policies and supporting standards that balanced security and fiscal reality.

Bringing users into the loop early makes them stakeholders in the policies and ambassadors to the rest of the organization. Peers who believe in the need for info-security carry a lot more weight with users than the "professional paranoids" of IT security. In my organization, our advisory group became a standing committee. The committee is our liaison to the business units, ensuring that our security solutions are designed with the primary business in mind.

Myth 5: Fear sells.

Building support for and compliance with policies is hard. It's very tempting to use fear as a sales tool. While warning managers and coworkers of the dire consequences of "letting our guard down" is effective up to a point, sounding the alarm bells every time a new virus is written or a new IIS vulnerability is found is going to sound like crying wolf after a while. Keep the security conversation calm and business-focused. The keys to achieving policy compliance are convincing people that information has great value and needs to be protected; writing policies that strike a balance between security and business needs; and getting very public support for new policies from top corporate management. This means that our final myth is really critical.

Myth 6: Okey-dokey, the policies are written. My work is done here.

If you are having some trouble sleeping this evening, pick up a copy of a typical info-security policy. The next thing you know, it's morning! No matter how well thought out and comprehensive your policies are, if people don't know about them, they will be as useful as a Jet Ski in the Sahara.

Get the word out--from the top. Make sure your new policies are distributed with a cover memo from the CEO stressing that they reflect management's marching orders. Once this is done, the real work begins.

My company's management understood the need to make info-security a priority years ago, and established an excellent awareness program. Our "awareness" folks made the new policies the focus of their programs for this year. Over the past few months, they:

• Printed calendars that highlight a different policy each month. These are hanging in a majority of offices and cubicles.
  
• Produced a Survival Guide to Information Security Policies, which presents the policies using equal parts plain English and humor. Copies have been distributed to every employee.
  
• Designed and presented 90-minute info-security policy training sessions for all employees.
  
• Ran a series of popular info-security game shows in which contestants' knowledge of the new policies (as well as other topics) can earn them office fame and prizes.
  
• Built an Intranet site that serves as a central clearinghouse for security information, including all policies and standards.

Even if you work in a small organization or one in which management hasn't "seen the light," there are a lot of inexpensive ways to get the word out. Here are a few ideas that spring to mind:

• Every week or two, send out a company-wide e-mail with a brief security tip.
  
• Print up posters highlighting policies for the bulletin boards in the cafeteria or break rooms.
  
• Recognize "security achievers." When employees contribute good ideas or assist in preventing/responding to an info-security incident, make it a big deal. Give them a gift certificate and publish a blurb in the company newsletter.
  
• Set up a "security hotline" for users to call or e-mail when they have questions about the policies or want to report a possible incident.
  
• Be responsive and make it easy for people to get answers.

Revamping our info-security policies has been a lot of work, and the process is continuing. Standards need to be written and updated. Users need to be educated. Compliance needs to be measured, and every so often, our info-security department has to gently guide our colleagues away from potholes and pitfalls.

However, having a strong and relevant set of policies allows our organization to deal with most security-related issues as a normal part of business and to focus our attention on problems and exceptions. And both the info-security team and our colleagues have learned a lot in the process.

AL BERG, CISSP, is a contributing editor for Information Security and a technical director in the corporate information security department of a firm providing data processing services to the financial industry.

[ Home ] [ Up ]

Send mail to info@comcast.net with questions or comments about this web site.