Problem solve Get help with specific problems with your technologies, process and projects.

Using security policy templates

Charles Cresson Wood explains the value of and approach to modifying information security policy templates to meet an organization's specific needs.

Employing a template approach to drafting security policies can save time and expense. Yet some organizations go too far, particularly when templates are slapped into place (similar to replacing a hardware board in a downed server) without considering how the policy statements will work in the existing environment.

Often, management is presented with a "best practices" set of borrowed policies and they're asked to sign the document -- a strategy which implies a certain "let's get this over with as fast as possible" approach. Someone likely "copied" the policies from another organization, the Internet, or a book. The person who "borrowed" the policies may not be in a position to explain the options to management, or discuss the implications of the options because they hadn't authored those polices to meet their organization's particular circumstances. This "take it or leave it" approach can diminish the importance of policies, and ultimately won't serve the organization's information security strategy.

Policies aren't a one-size-fits-all affair. Rather, they must be scrupulously tailored to the environment in question before adoption. Management needs to analyze information security policies according to major decision factors, such as organizational risks and cultural effects, costs and benefits, deployment implications and supporting technology requirements. For example, rather than simply dictating that every user must, from this point forward use digital certificates, management needs to have an extended conversation, about the options and the related implications of these options (including "do nothing").

Prior to adopting policies, management also needs to consider the current level of staff awareness and motivation, the state of information security compliance and how staff will react to certain policies. For example, to plug-and-play a policy template for dealing with pornographic downloads requires tailoring to the environment, particularly if employees regularly access the Internet to get their jobs done. If a "no tolerance" policy is adopted, which requires that anyone caught downloading porn be immediately terminated, people may become reluctant to use the Internet, and productivity could suffer as a result.

What's more, making an example of people caught and dismissed could exacerbate the problem. Consider the legitimacy of the employees' concern that they may mistakenly type in a Web address for a porn site, and as a result they'd be immediately terminated. This concern is fully grounded in the current Internet technology, where a single typographical error could redirect users to a porn site that they never intended to visit. From an employee's perspective, flirting with that possibility certainly isn't worth one's job. In this example, management would have failed to anticipate how a prefabricated policy would discourage people from using the Web. They would have overlooked the opportunity to adopt an employee-friendly disciplinary approach, where people get warnings before they get fired for violating a "no tolerance for downloading porn" policy.

Policies, in some respects, are a compilation of requirements -- a summary of how an organization approaches information security. Judging the potential effectiveness of proposed policies requires an understanding from management about the organization's unique risks (typically found in a risk analysis report) and the prevailing circumstances in the organization. Management needs to consider legal and regulatory requirements, what may need changing before proposed policies can be implemented and the long-term implications of the security policy to be adopted.

Consider the approach taken by a large personal computer software company -- where management was upset about a relatively high level of software piracy and wanted to absolutely ensure that no more piracy took place. They adopted a strict policy, which required the use of a hardware key before their company's software would run. While the short-term objective was served well, and piracy did drop off markedly, the policy caused a slide in software sales -- the hassle of using a hardware key was a big turn-off for potential buyers. In fact, a certain amount of piracy was actually beneficial to sales, as it allowed people to take the software program from one job to another for demonstrating it to a new boss or colleagues. In this instance, for a few years afterwards, the software company was scrambling to catch up with other vendors, because those competitors took the opposite approach to acquaint their next user generation by seeding campuses with free copies of their software.

In the long run, appropriate background analysis is needed for modifying policy templates to an organization, which in turn enables management to proactively and effectively develop policies in conjunction with business partners and other third-parties.

About the author
Charles Cresson Wood, CISSP, CISA, CISM, is an independent information security consultant based in Sausalito, Calif. He specializes in the development of information security documents including policies, standards, procedures and job descriptions. He is also the author of the book and CD-ROM entitled Information Security Policies Made Easy.

This was last published in January 2005

Dig Deeper on Information security policies, procedures and guidelines