Five Mistakes Security Policy By Anton Chuvakin

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 of change to be accelerating. On top of that, to be able to stay in touch with such ever-changing reality, one has to evolve with the space as well. Thus, even though I hope that this document will be useful for to my readers, please keep in mind that is was possibly written years ago. Also, keep in mind that some of the URL 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 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 actually 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 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 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 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 large portion 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 must document 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 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. 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 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” security policy document. 3. Not Tracking Compliance With the Security Policy Now, 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. 4. Having a “Tech Only” Policy Assuming that you avoid the first three pitfalls mentioned above, another common slipup 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. 5. 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 noncompliance. 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 cover technical 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 in 2009. Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert in the 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 Enemy II", "Information Security Management Handbook" and others. Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management (see list www.info-secure.org) . His blog http://www.securitywarrior.org is one of the most popular in the industry. In addition, Anton teaches classes and presents at many security conferences across the world; he recently addressed audiences in United States, UK, Singapore, Spain, Russia and other countries. He works on emerging security standards and serves on the advisory boards of several security start-ups. Currently, Anton is developing his security consulting practice, focusing on logging and PCI DSS compliance for security vendors and Fortune 500 organizations. Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a

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