As I mentioned in my last article, security policies serve to protect (data, customers, employees, technological systems), define (the company's stance on security), and minimise risk (internal and external exposure and publicity fallout in the event of a breach). Security policy creation and dissemination are not just a good idea; both are mandated by a slew of corporate regulations, including PCI, HIPAA, and FISMA.

This article presents five mistakes that companies commonly make when writing and implementing security policies. As simplistic as some of these errors sound, they happen often enough and cause heavy damage to companies' bottom lines.

Not having a policy

As security policy mistakes go, this is a big one and can range in practice from not having any policy to only having an "implied policy" - one that is informally discussed by management, but not written down or distributed to anyone.

Not only does this careless approach leave a security weakness and create legal liability, but it might also be in violation of regulations that explicitly mandate a properly written and disseminated security policy.

Of course, as soon as a policy is formally created, companies often discover that a large portion of their systems actually violate it. This isn't surprising, since it indicates that the policy was not developed solely around current standards of IT operations. This means that, in addition to a security policy, companies also must document the deficiencies in their current systems, analyse the risks, and assess the costs of remediation of those deficiencies to bring them into compliance with the new policy.

Not updating the security policy

Assuming you don't fall victim to mistake number one, you will become aware of a crucial security point: simply having a nicely written policy is not enough for improved security.

Inevitably, there will be changes made to the company network as well as business processes; the security risks and compliance requirements will also change. It makes sense that, as both threats and corporate landscapes evolve, so must the security policy.

Reasons to update the policy include deployment of new technology (or disposal of outdated software or hardware), new or updated regulatory mandates, corporate growth, mergers or reorganizations that bring new data and users into the system, and new business lines or practices - essentially, any changes to the elements the security policy is in place to protect.

Companies that do not regularly review and update their security policy with these and other changes risk having gaping holes in their threat posture and becoming sitting ducks in the security pond, despite having a "shiny new" security policy document.

Not tracking compliance with the security policy

If you have a policy in place and you regularly update it, you have taken two important steps toward policy nirvana. But other mistakes might get you!

A security policy becomes practically and sometimes even legally useless if a company does not track whether the policy is followed or even whether or not employees are aware of its stipulations. First, to be able to enforce the policy, a company must make sure that the policy is disseminated to all employees and that regular awareness training is conducted, especially when the policy is updated. Further, to ensure the usefulness of the policy, ongoing activity monitoring is essential.

Perhaps the most effective way to track policy compliance is through logging. Collecting and analysing log data will allow for a look into what is happening in the IT environment. If an employee emails a work document to a personal account or tries to access data that is beyond their level of access or if an outside hacker makes several unsuccessful attempts to log in to a server, there will be logs of all of these events. Tracking user and system activity via logs and comparing that data to the stipulations of the security policy is the best way to objectively assess ongoing compliance with your policy.

Having a "tech only" policy

Assuming that you avoid the first three pitfalls discussed above, another common slip-up involves the focus of the policy.

A policy that only covers technological security (e.g. password complexity, firewall rules, IPS alerting, anti-virus updates, etc.) and omits discussion of people and their activities leaves the company vulnerable to "softer" threats: insider privilege abuse, personal use of computing resources, etc. While it is important to describe the technical safeguards and to make sure that they are driven by the security policy and not deployed in an ad hoc fashion, policy must cover all three of the "people, process, technology" triad.

Once again, log data is important to this balance, as system activity (such as system restarts, automatic updates, attack blocking) and user activity (from routine IT tasks to physical security) is captured in logs and can be checked against the policy as well as presented as evidence of violating or following the policy.

Having a policy that is large and unwieldy

Put simply, a security policy has to be written in such a way that it is understandable to those who are required to follow it.

If a policy is written in legalese and occupies 130 pages, most employees will not even try to understand what it prescribes and violations are sure to follow. Similarly, policies that are written too strictly and ban what most employees do on a daily basis to fulfill their job duties, will likely drive employees to massive non-compliance. An education effort will be needed even before the policy is put in place. Thus, creating a clear and understandable policy from the very beginning will contribute a lot to future policy compliance levels.

Overall, we've looked at five common security policy mistakes. For a security policy to be able to serve its purpose, it must be clearly written and updated as needed. It must cover technical and non-technical realms; finally, compliance with it should be monitored.

Dr. Anton Chuvakin , GCIA, GCIH, GCFA is a recognized security expert and book author. He's currently Chief Logging Evangelist with LogLogic, a log management and intelligence company. He is the author of Security Warrior and a contributor to Know Your Enemy II, Information Security Management Handbook, Hacker's Challenge 3 and PCI Compliance.