Five basic mistakes of security policy

February 29, 2008 (Computerworld) 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 minimize 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 story 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. (See my previous article, "Security Policy in the Age of Compliance," for the discussion of this.)

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, analyze 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.