Yet there are five mistakes that companies commonly make when writing and implementing security policies.
As simplistic as some of the following errors sound, they happen often enough and cause heavy damage to companies' bottom lines when they do.
Not having a policy
As security policy mistakes go, this is a big one and can range from not having any policy at all to only having an "implied policy" (ie one informally discussed by management, but not written down or distributed to staff).
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 a large portion of their systems violate it. This isn't surprising, since it indicates 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 remedying those deficiencies.
Not updating the security policy
If you don't fall victim to mistake number one, you will soon become aware of a crucial security point, namely that just 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 and hardware)
- new or updated regulatory mandate
- corporate growth
- mergers or reorganisations that bring new data and users into the system; and
- new business lines or practices.
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. 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.
To be able to enforce the policy, a company must ensure that all employees are informed and given regular awareness training, 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 an examination of 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 activity via logs, comparing it to the stipulations of the security policy, is the best way to objectively assess ongoing compliance.
Having a "tech only" policy
Another common slip-up involves the focus of the policy. A policy that only covers technological security (eg password complexity, firewall rules, IPS alerting, anti-virus updates and so on) omits discussion of people and their activities. That in turn leaves the company vulnerable to "softer" threats, such as insider privilege abuse and personal use of computing resources.
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 every point of the "people, process, technology" triad.
Once again, log data is important to this balance, as system activity (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 to be understandable to those required to follow it. If a policy is written in legalese and runs over 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 need to do daily (this Wall Street Journalstory notwithstanding), will probably drive employees into massive non-compliance. An education effort will be needed even before the policy is implemented. So creating a clear and understandable policy from the very start will contribute a lot to future policy compliance levels.
Dr Anton Chuvakin, security expert and author of Security Warrior , is currently working at LogLogic, a log management and intelligence company.