Five Mistakes Security Policy by Anton Chuvakin

8/14/2019 Five Mistakes Security Policy by Anton Chuvakin

1/4

Five Mistakes of Security Policy

Dr. Anton Chuvakin

WRITTEN: 2007

DISCLAIMER:Security is a rapidly changing field of human endeavor. Threats we face literally

change every day; moreover, many security professionals consider the rate ofchange to be accelerating. On top of that, to be able to stay in touch with suchever-changing reality, one has to evolve with the space as well. Thus, eventhough I hope that this document will be useful for to my readers, please keep inmind that is was possibly written years ago. Also, keep in mind that some of theURL might have gone 404, please Google around.

As I mentioned in my last article, security policies serve to protect (data, customers,

employees, technological systems), define (the companys stance on security), andminimize 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 areactually mandated by a slew of corporate regulations, including PCI, HIPAA, and

FISMA.

This story presents five mistakes that companies commonly make when writing andimplementing security policies. As simplistic as some of these sound, they happen often

enough and cause heavy damage to companies bottom lines.

1. Not Having a Policy

As security policy mistakes go, this is a big one and can range from not having any policyto only having an implied policy, one that is informally discussed by management, butnot written down or distributed to anyone. Not only does this careless approach leave a

security weakness and create a legal liability but it might also be in violation of

regulations that explicitly mandate a properly written and disseminated security policy(see my previous paper Security Policy in the Age of Compliance for the discussion of

this).

Of course, as soon as the policy is formally created, companies often discover that a largeportion of their systems actually violate the new policy. This is not surprising, since it

indicates that the policy was not developed solely around current standard of IT

operations. This means that, in addition to a security policy, companies also mustdocument the deficiencies in their current systems, analyze the risks, and assess the costs

of remediation of those deficiencies to bring them in compliance with the new policy.

2.Not Updating the Security PolicyAssuming you dont 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.

8/14/2019 Five Mistakes Security Policy by Anton Chuvakin

2/4

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 makessense that, as both threats and corporate landscapes evolve, so must the security policy.

The 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 practicesessentially, any changes to the elements the security policy is

in place to protect. Companies that do not regularly review and update their securitypolicy 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 security policy

document.

3.Not Tracking Compliance With the Security PolicyNow, 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 awareof 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 ITenvironment. 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.

4.Having a Tech Only PolicyAssuming that you avoid the first three pitfalls mentioned 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 theiractivities 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 deployedin an ad hoc fashion, policy must cover all three of the people, process, technology

triad.

8/14/2019 Five Mistakes Security Policy by Anton Chuvakin

3/4

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 aspresented as evidence of violating or following the policy.

5.Having a Policy That is Large and UnwieldyPut 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 looked at five common security policy mistakes. For a security policy to be

able to serve its purpose, it must be clearly written, updated as needed, and covertechnical and non-technical realms, and, finally, compliance with it should be monitored.

ABOUT THE AUTHOR:

This is an updated author bio, added to the paper at the time of reposting in2009.

Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert inthe field of log management and PCI DSS compliance. He is an author of books"Security Warrior" and "PCI Compliance" and a contributor to "Know Your EnemyII", "Information Security Management Handbook" and others. Anton haspublished dozens of papers on log management, correlation, data analysis, PCIDSS, security management (see list www.info-secure.org) . His bloghttp://www.securitywarrior.org is one of the most popular in the industry.

In addition, Anton teaches classes and presents at many security conferencesacross the world; he recently addressed audiences in United States, UK,Singapore, Spain, Russia and other countries. He works on emerging securitystandards and serves on the advisory boards of several security start-ups.

Currently, Anton is developing his security consulting practice, focusing onlogging and PCI DSS compliance for security vendors and Fortune 500organizations. Dr. Anton Chuvakin was formerly a Director of PCI ComplianceSolutions at Qualys. Previously, Anton worked at LogLogic as a Chief LoggingEvangelist, tasked with educating the world about the importance of logging forsecurity, compliance and operations. Before LogLogic, Anton was employed by a

8/14/2019 Five Mistakes Security Policy by Anton Chuvakin

4/4

security vendor in a strategic product management role. Anton earned his Ph.D.degree from Stony Brook University.