One of the projects I have want to do for a long time is to develop and release a good set of policies and standards for free. I plan to do the heavy lifting here and hopefully recruit a few good folks who will join me in writing. I know several sets exist like at SANS but IMHO they leave a lot to be desired.

I made a blog post last week on my personal blog about what I think the problems with policies and standards are. It seems smart to get a good list of what everyone else sees as well before I start so we don't replicate the same mistakes that are "in the wild".

From my experience in the "real world", polices and standards are more often than not;

• "Shelfware" that is inaccessible; usually Microsoft Word documents stuffed on a Windows folder or obscure intranet page but sometimes nicely bound and printed in the CSO's office or on his coffee table in his waiting area.
• Dismissed by the business at large as largely irrelevant to those outside of information security and often referred to as the "constitution of the thought police"
• Poorly presented and poorly written. If car repair manuals were security policies there would be no hot-rods!
• Inconsistent; 8 char password in one policy, 7 char passwords in another
• Infrequently updated and therefore out-of-date
• Suffer from a lack of precision context

The programs that support them are more often than not;

• "Peaks and troughs" efforts at best and one time shots at worse
• Have no ability to record who read, signed and accepted the policy beyond crude email
• Poor or loose process to bind stakeholders into creation, changes and management
• No process to deal with updates beyond "save as..."
• No ability to automatically request, grant and track exceptions beyond Excel (or the back of a cigarette packet)

 

For your "policies and standards are more often" list, I have seen them written as technology controls only (i.e., we have anti-virus, firewalls, etc., therefore we have a security program).

In your "programs that support them", what I have also seen is they die on the vine or loose support most often when senior leadership does not have a clear understanding of how policies can benefit a business (i.e., tracked to a key performance indicator), which often then marginalize them to technology controls only.

Also, I assume when you say "poor or loose process to bind stakeholders" you are meaning, or including, ill defined roles and responsibilities?
 

ebreece:

For your "policies and standards are more often" list, I have seen them written as technology controls only (i.e., we have anti-virus, firewalls, etc., therefore we have a security program).

I think thats a great point of view. I hadn't looked at it that way before.

 

ebreece:

"poor or loose process to bind stakeholders"

, yes I mean that usually few people feel they have a stake in the policies or standards and if they do it's a negative one. Think about vacation accrual or 401K's and almost everyone knows exactly what the policy is and why it's good for them. I think this kind of adoption can be achieved by understanding the stakeholders needs and motivations.

 

Frankly, there are not many people who look forward to writing, or are qualified to write policies and standards, so one big issue is "who will write them?" Modest to large sized organizations all need them, but rarely have someone who can actually write them professionally. Short of hiring a security professional, what choices are there? You could have an IT guy write them, but then they often focus too much on technology. Maybe someone from the legal department could write them, but then they are often not technical enough or specific enough. Maybe getting them "off-the-shelf" from some vendor would work, but they would still need to be closely read and editted to fit the company.

 Two things that I have seen work well on some organizations for this task. First, let any interested party write a policy or standard if they like and give it to their manager. If the manager likes it then they pass it on, which bring up the second item - a Policy Committee. The most successful organizations I have seen have a group that studies new policies and one that studies standards. Any policy or standard document has to get through the proper committee to take effect. This method "spreads the pain" of writing these documents and approving them. It also alleviates some of the political problems that can arise with more unpopular edicts. If your manager is on the Policy committee that just approved the new Internet Use policy you dislike, it is harder to be vocal in opposition.

tthomas:

Frankly, there are not many people who look forward to writing, or are qualified to write policies and standards, so one big issue is "who will write them?" Modest to large sized organizations all need them, but rarely have someone who can actually write them professionally. Short of hiring a security professional, what choices are there?

This is one of the main drivers behind the Policies and Standards project here at ISM. It's rare that these things will ever be a competitive advantage to anyone so if we can get companies collaborating on a mundane and common topic then everyone can win.

You point about stakeholders is well taken. When people are told what to do they rebel, its humannature. When they agree that something is in their best interest they don't. I think a balance can be achived where policies and standards make peoples lives easier. When they are consulted and have a say in "law making" as a democratic process they tend to be prepared to abide by the rules.

I always advocate identifying the stakeholers first and involving them in any standards and policy work.Wen they buy in they recruit other champions and the butterfly affect kicks in.

Argh blue skies ;-)

 

 

Well, truly it comes back to educating the users. To really have an effective program and reduce resistance you need to educate the users regularly on security issues and how they directly impact them and the company. I have seen it in action and when there is a good system of security training for the users, they don't look at policies and standards as hinderances as much as "necessary evils" or even as "needed safegaurds" if you are lucky. The users are also where the "rubber meets the road" because if they don't like or understand what you are trying to do, they WILL undermine whatever standards or policies are being put in place.

 Of course, all of this pre-supposes you have a staff of IT security professionals that can provide the training and guidance. Most shops are like my current one, though, where there is just one person (me in this case) charged with "security" and that is only one of my hats. Thus, I rarely have time to write policies, lt alone provide training.