The Seven Deadly Sins of Security Policy

Are your security policies really managing your organization's risks? Or are they just 'check-the-box' rules? We detail common policy mistakes security pros often make.

In today's compliance-centric world, your organization may have so many security policies that you've lost track. But how effective are your policies at really mitigating the risks you face? And are there some that you might have put in place simply to follow the law but that just aren't being enforced? According to the policy experts we interviewed, those are just two of the several common mistakes an organization can make when putting policies on the books.

Here, we detail seven regularly-seen sins witnessed by two security consultants in the field. Read on to find out which ones you might be committing, and how to make things right if you are.

For more policy guidance, check out CSO's library of security tools, templates and policies

1. Failing to do a risk assessment before crafting a policy

The first question any organization should ask before writing any policy is "Why do we need this policy and what are we trying to achieve with it?" It sounds obvious, but it is a crucial step many overlook, according to Charles Cresson Wood, an independent information security consultant based in California and the author of several information security books.

"I'm working with one client now who is compelled by laws and regulations to issue policies and awareness materials, but they haven't done a risk assessment in three years," said Cresson Wood. "They don't really know what they are up against. So these policies can't help but miss the mark. Yes, they will be in compliance with the letter of the law, but certainly not the spirit."

Wood is trying to bring a more holistic and integrated view to information security and policy crafting to his clients so they will implement policies that work, he said. Too much policy work is driven by compliance, he said. (Read: The Dangers of Over Reliance on Compliance) In fact, he doesn't even like the word 'compliance.'

"It implies users are compromising themselves or being dominated by someone. We need to get groups of people on board with what we are trying to do with these policies. I prefer term 'unity of purpose.'"

That said, the first step before you even think about putting anything down in writing is to do a comprehensive risk assessment so you know exactly what you need in your organization.

2. Having a 'one-size-fits-all' mentality

"This may sound strange coming from me," said Cresson Wood, who actually authored a book with templates for organizations to use when developing policies. "But those are just a starting point."

Many organizations are simply using examples in books or borrowing from other organizations, he said.

"Especially in this economy," said Cresson Wood. "People are pressed for time and money. They are just reprinting what they find elsewhere."

Cresson Wood even worked with one company that had a policy which still had another organization's name in the text of the document.

"I brought this to management's attention and they said "I guess we didn't do a very good job editing."

But writing a security policy that is going to work for you means more than just editing. While you might use a template or borrow from another organization's example, after your risk assessment, it is important to customize your policy for what YOUR organization needs. That means taking the time to carefully write a policy that fits your unique security profile.

3. Failing to have a standard template

We're really not trying to confuse you. Sure, we just said not to have a 'one-size-fits-all' mentality when it comes to security policy. But that doesn't mean you shouldn't have consistency for policies within your organization, according to Scott Hayden, a Texas-based security consultant who specializes in management, policy and governance, and awareness training.

"There has to be a standard structure for every document that is followed every time," said Hayden. "Sometimes I go into an organization and find this stuff willy-nilly. Some policies are on paper, but some are not. Some are even on email."

Hayden recommends clients put in corporate governance policy of standards and procedures in order to govern how policies are created, distributed and maintained.

"I really strongly enforce in my engagements that they follow the same template for policy and procedures. And making sure you are capturing the same information about each guidance document is crucial."

Following a standard for crafting policies can also help in keeping them concise and therefore more readable.

"Anytime I go into an organization and see a 100-page policy I know that is not a usable, workable document," said Hayden. "That's because anytime something changes in that policy, you must revisit it and ship it out to everybody again."

4. Having policies that only look good on paper

"One thing we see all the time is policies that are written just to satisfy a check box on some audit or regulatory requirement, but they are not enforceable," said Hayden." That's a huge issue out there."

Cresson Wood agrees and said often his clients don't even realize they are not following a policy they have in place. They are usually organizations that are failing to do sufficient and frequent compliance checking.

"Organizations that have the best track record in terms of no serious infosec breaches and a high-level of compliance will check compliance every two weeks. And they automate the process," said Cresson Wood.

Hayden said the scenario he sees frequently is a policy that is just not realistic in the real world.

"You might have a policy that states no personal use of business machines," he said. "But can you really enforce that? Because how do you define personal use?"

However, this is a huge mistake, said Hayden. Your efforts to create policy will be for naught if you can't enforce it.

"The enforceability of a policy is crucial. If you can't enforce it you are going to get dinged in an audit just as bad as if you didn't have a policy at all."

5. Failing to get management to buy in to the policy

You expect everyone to wear a badge in the building, but let's not bother the CEO with that kind of stuff, right? Wrong. Everyone needs to abide by security policy, said Cresson Wood. That includes the most high-level staff members.

"In many cases they think the CEO won't support it if they have to do it. Or they think the CEO doesn't understand technology or just doesn't deal with stuff like this," said Cresson Wood. "But we need top managers to be ambassadors of good security practices."

Cresson Wood said he has worked with clients who often give C-level executives laptops with a degraded level of security to make it easier for top management to use them.

"That is not setting the example you want to set. They should be subject same set of security requirements as everyone else. In fact, there is reason to believe they should be subject to a more stringent set of requirement because they have access to such very sensitive information, such as merger and acquisitions data."

Cresson Wood tells a great story of how this came back to bite one client; a prestigious bank where the executives wore expensive suits that they didn't want marred by the look of a security badge.

"Top management would bring people in for tours, point out the fancy computing equipment, but they wouldn't wear a badge. It eventually enabled someone to masquerade as an executive simple by wearing a nice suit and not wearing a badge."

Cresson Wood didn't disclose what the fraudster got away with. But the take away for you here is: Make everyone follow the rules.

6. Writing policy after a system is deployed

Why not write a policy for a system once you've got it up and running? Because security needs to be part of the systems development process, according to Cresson Wood, who said he often sees patch management programs that clients have put in place that are out of date and miss the mark of what is really going on in security.

"From the very beginning, from feasibility analysis stage, security needs to be part of the discussion. If security is an add-on, we are in a position where we have to play catch up. Consideration of security from the earliest phases will ensure that what gets delivered is going to work in your environment. When security is an add-on, it can't help but be incomplete, insufficient, and, in many ways, inadequate for the task."

7. Lack of follow up

You've put a security policy together. Perhaps you even did a good job and have not committed one of the six sins detailed above. But how is your follow up?

"Security policy needs to be reevaluated at least once a year, perhaps even more frequently," said Cresson Wood.

Bringing it back to that holistic process Cresson Wood referred to earlier, he advises clients to look at policy as a process, which means keeping up with it and checking in to make sure it's not only working, but also making changes as appropriate.

"Writing a policy is not an isolated task," he said. "But that is often how it is dealt with in many IT departments."

This story, "The Seven Deadly Sins of Security Policy" was originally published by CSO .

Join the discussion
Be the first to comment on this article. Our Commenting Policies