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 analyzing log data will allow for a look into what is happening in the IT environment. If an employee e-mails 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; 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 (WSJ story notwithstanding), 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.