CHAPTER 44

SECURITY POLICY GUIDELINES

M. E. Kabay and Bridgitt Robertson

44.1 INTRODUCTION

44.2 TERMINOLOGY

44.2.1 Policy

44.2.2 Controls

44.2.3 Standards

44.2.4 Procedures

44.3 RESOURCES FOR POLICY WRITERS

44.3.1 ISO/IEC 17799: 2005

44.3.2 COBIT

44.3.3 Informal Security Standards

44.3.4 Commercially Available Policy Guides

44.4 WRITING THE POLICIES

44.4.1 Orientation: Prescriptive and Proscriptive

44.4.2 Writing Style

44.4.3 Reasons

44.5 ORGANIZING THE POLICIES

44.5.1 Topical Organization

44.5.2 Organizational

44.6 PRESENTING THE POLICIES

44.6.1 Printed Text

44.6.2 Electronic One-Dimensional Text

44.6.3 Hypertext

44.7 MAINTAINING POLICIES

44.7.1 Review Process

44.7.2 Announcing Changes

44.8 SUMMARY

44.9 FURTHER READING

44.10 NOTES

44.1 INTRODUCTION.

This chapter reviews principles, topics, and resources for creating effective security policies. It does not propose specific guidelines except as examples. Many of the chapters in this Handbook discuss policy; a few examples are listed next:

Chapter 23 provides an extensive overview of physical security policies.

Chapter 25 discusses local area network security issues and policies.

Chapter 38 reviews software development policies.

Chapter 39 surveys quality assurance policies.

Chapter 45 provides guidance on employment policies from a security standpoint.

Chapter 47 includes policies for improving operations security and production.

Chapter 48 reviews specific recommendations for e-mail and Internet usage.

Chapter 49 looks at methods for enhancing security awareness.

Chapter 52 offers policies for secure application design.

Chapters 56 through 59 deal with policies for emergency response, backup, and recovery.

Chapter 61 presents policies for working effectively with law enforcement.

Chapter 66 discusses effective methods for developing security policies in specific organizations.

44.2 TERMINOLOGY.

One of the preeminent leaders in security policy development, Charles Cresson Wood, has emphasized that when developing policy, it helps to segregate information that has different purposes. Specifically, one should create different documents for policy, standards, and procedures.¹

44.2.1 Policy.

The term “policy” is defined as the rules and regulations set by the organization. Policies are laid down by management in compliance with applicable law, industry regulations, and the decisions of enterprise leaders. Policies are mandatory; they are expressed in definite language and require compliance. Failure to conform to policy can result in disciplinary action, termination of employment, and even legal action. Familiar examples of policy include requirements for background checks when hiring employees, the obligation to follow laws governing the duplication of proprietary software, and restrictions on the use of corporate vehicles for private purposes.

Security policy governs how an organization's information is to be protected against breaches of security; examples include policies on identification and authentication, authorization for specific kinds of access to specific data, responsibilities for data protection, limitations on the use of corporate resources for e-mail and Internet access, and restrictions on installation of programs on corporate systems. Policies are the basis for security awareness, training, and education; they are a necessary underpinning for security audits. Without policies, it is impossible to demonstrate due diligence in the protection of corporate assets.

Policies are focused on the desired results, not on the means for achieving those results. The methods for achieving policies are defined in the next sections on controls, standards, and procedures.

44.2.2 Controls.

When developing a framework for implementing security policies, controls are the measures used to protect systems against specific threats. For example, a policy might stipulate that all production systems must be protected against unauthorized modification of data by programmers; a specific control that could be named in the policy might be that test data extracted by programmers from the production databases must be anonymized to protect confidential data.

44.2.3 Standards.

A standard in computing can be an accepted specification for hardware, software, or human actions. An example of a technical standard is the transmission control protocol/Internet protocol (TCP/IP) that governs how systems can be interconnected into the Internet.

Standards can be de facto when they are so widely used that new applications routinely respect their conventions; an example is the Hewlett-Packard interface bus (HP-IB), which became so popular that it was eventually turned into a de jure standard when the Institute of Electrical and Electronics Engineers (IEEE) based its formal IEEE-488 standard on the HP-IB. In contrast, the Centronix parallel interface, although equally popular and universally used, remains proprietary.

In a corporate environment, the term “standard” refers to specific technical choices for implementing particular policies. For example, a corporate policy might stipulate that strong identification and authentication, selected by the technical staff, must be used when gaining access to restricted data; the corresponding standard might specify that a particular brand and model of a microprocessor-equipped smart card should be used in satisfying access control restrictions. Typically, standards are of concern to those who must implement policies; not all standards need be made known to all personnel. Standards also must change in response to a changing technical environment; typically standards change much more rapidly than policies.

44.2.4 Procedures.

Procedures prescribe how people are to behave in implementing policies. For example, a policy might stipulate that all confidential communications from employees traveling outside the enterprise must be encrypted; the corresponding standard might define the proprietary virtual private network (VPN) software and hardware needed to implement that policy; and the corresponding procedure would explain in detail each step required to initiate a secure connection using that particular VPN.

44.3 RESOURCES FOR POLICY WRITERS.

If one is setting out to create policy de novo (i.e., without a preexisting policy document), it is critically important to use an existing policy template. Creating policies without guidance from experienced policy writers is a time-consuming, frustrating job that can consume thousands of hours of time, cause dissension within the enterprise, and leave everyone so disgusted that the policies end up turning into shelfware: stored, but never used. There are several well-recognized resources for helping policy writers structure their work, avoid pitfalls, and save enormous amounts of time. In the review that follows, readers will find information about these resources:

• ISO 17799
• COBIT^®
• CERT-CC documentation
• NSA Security Guidelines
• U.S. Federal Best Security Practices
• RFC2196
• IT Baseline Protection Manual
• Commercial policy guides

44.3.1 ISO/IEC 17799:2005.

An increasingly popular standard for writing and implementing security policies, especially in Europe, is ISO/IEC 17799:2005, which is based on the old BS7799.

The British Standard 7799 (BS7799) originated in the U.K. Department of Trade and Industry as a code of practice; it was formally renamed the BS7799 in February 1995. BS7799 was not adopted quickly in Great Britain because it was not flexible enough, it used a simplistic security model, and there were more pressing issues, such as the imminent arrival of the Y2K problem.² In addition, BS7799 was a proprietary standard for which users had to pay the equivalent of several hundred dollars before accessing the full documentation.

Version 2 of BS7799 was published in May 1999, and that year also saw the establishment of formal certification and accreditation methods. At that point, the International Organization for Standardization (ISO) began the process of defining BS7799 as an international standard; ISO 17799 was published in 1999. In 2005, the standard was renamed as ISO/IEC 17799:2005 in collaboration with the International Electrochemical Commission (IEC).³

With the increasing interest in security, ISO 17799 certification has been established as a goal for many organizations throughout the world. Major consultancies have trained their auditing staff for compliance with ISO 17799; e-commerce is also a driving force behind the push for certification. One possible motivation is the experience of the ISO 9000 (quality) certification process in the 1980s; certification soon became a competitive edge and then a competitive requirement to maintain and develop market share.

In the context of policy development, ISO 17799 offers a convenient framework to help policy writers structure their project in accordance with an international standard. The abstract from the ISO follows.

The control objectives and controls in ISO/IEC 17799:2005 are intended to be implemented to meet the requirements identified by a risk assessment. ISO/IEC 17799:2005 is intended as a common basis and practical guideline for developing organizational security standards and effective security management practices, and to help build confidence in interorganizational activities.

The full text of ISO 17799 is available in electronic format or on paper from the ISO for 202 Swiss francs. In addition, a variety of guides are available to help organizations to develop ISO 17799-compliant policies with minimal rewriting.⁴

44.3.2 COBIT.

The Control Objectives for Information and related Technology (COBIT) provide a business-oriented set of standards for guiding management in the sound use of information technology.⁵ COBIT was developed by volunteers working under the aegis of the IT Governance Institute (ITGI), which was itself founded by the Information Systems Audit and Control Association (ISACA).

COBIT is an information technology (IT) governance framework and supporting tool set that allows managers to bridge the gap between control requirements, technical issues, and business risks. COBIT enables clear policy development and good practice for IT control throughout organizations. COBIT was first published by ITGI in April 1996. ITGI's latest update—COBIT 4.1—emphasizes regulatory compliance, helps organizations to increase the value attained from IT, highlights links between business and IT goals, and simplifies implementation of the COBIT framework. COBIT 4.1 is a fine-tuning of the COBIT framework and can be used to enhance work already done based on earlier versions of COBIT. When major activities are planned for IT governance initiatives, or when an overhaul of the enterprise control framework is anticipated, it is recommended to start fresh with COBIT 4.1. COBIT 4.1 presents activities in a more streamlined and practical manner so continuous improvement in IT governance is easier than ever to achieve.⁶

COBIT documents are available free (with registration) through download as PDF files in English, French, German, Hungarian, Italian, Japanese, Korean, and Russian.⁷ The extensive Frequently Asked Questions provide detailed guidance for managers beginning their study of the standard.⁸ ISACA also provides an interactive, Web enabled version of COBIT that allows registered users to “construct and download [their] own, personalized version of COBIT for use on the desktop in MS Word or Access format.”⁹ Different levels of detail are available for visitors, ISACA members, and purchasers. ISACA also offers training courses in its “COBIT Campus”¹⁰ as shown:

• COBIT Awareness Course (2 hours, self-paced e-learning)
• COBIT Foundation Course (8 hours, self-paced e-learning or 14 hours, classroom)
• COBIT Foundation Exam (1 hour, online 40 questions)
• IT Governance Implementation Course (14 hours, classroom)
• COBIT for Sarbanes-Oxley Compliance (5 hours, self-paced e-learning)

44.3.3 Informal Security Standards.

In addition to the formal standards just discussed, several sets of guidelines have garnered a degree of acceptance as the basis for exercising due diligence in the protection of information systems. These informal standards include:

• CERT-CC security improvement modules
• Security guidelines handbook from the U.S. National Security Agency (NSA)
• RFC2196 from the Internet Engineering Task Force
• IT baseline protection manual from the German Information Security Department

44.3.3.1 CERT-CC^® Documentation.

The Computer Emergency Response Team Coordination Center (CERT-CC)1^® at the Software Engineering Institute (SEI) of Carnegie Mellon University (CMU) has compiled a series of security improvement modules (www.cert.org/certcc.html) on these topics:

Vulnerability Remediation

• Current Vulnerability Work
• Vulnerability Notes Database

CSIRT Community

• CSIRT Development
• National CSIRTs

Secure Coding

• Secure Coding Project Page
• Secure Coding Standards

Artifact Analysis

In addition, CERT expert Julia H. Allen published an excellent guide in 2001 that has retained its value.¹¹ Chapter headings for this 480-page text are listed next.

1. The CERT Guide to System and Network Security Practices
2. Securing Network Servers and User Workstations
3. Securing Public Web Servers
4. Deploying Firewalls
5. Setting Up Intrusion Detection and Response Preparation
6. Detecting Signs of Intrusion
7. Responding to Intrusions

Appendix A: Security Implementations

Appendix B: Practice-Level Policy Considerations

44.3.3.2 NSA Security Guidelines.

The National Security Agency (NSA) of the United States has published a freely available Security Guidelines Handbook.¹² The preface describes it in this way:

This set of employee policies is tailored to the needs of the high-security NSA, but it provides useful information that all organizations can adapt to their own requirements. According to the table of contents, these topics are included:

Initial Security Responsibilities

• Anonymity
• Answering Questions about Your Employment
• Answering Questions about Your Agency Training
• Verifying Your Employment
• The Agency and Public News Media

General Responsibilities

• Espionage and Terrorism
• Classification
• Need-to-Know
• For Official Use Only
• Prepublication Review
• Personnel Security Responsibilities
• Association with Foreign Nationals
• Correspondence with Foreign Nationals
• Embassy Visits
• Amateur Radio Activities
• Unofficial Foreign Travel
• Membership In Organizations
• Changes in Marital Status/Cohabitation/Names
• Use and Abuse of Drugs
• Physical Security Policies
• The NSA Badge
• Area Control
• Items Treated as Classified
• Prohibited Items
• Exit Inspection
• Removal of Material from NSA Spaces
• External Protection of Classified Information
• Reporting Loss or Disclosure of Classified Information
• Use of Secure and Non-Secure Telephones

Helpful Information

• Security Resources

44.3.3.3 U.S. Federal Best Security Practices.

The United States Federal Chief Information Officers (CIO) Council has created a Best Practices Committee that provides extensive free documentation for policy makers.¹³ The committee is defined in this way:

There is an extensive collection of documents freely available in PDF format for downloading.¹⁴ Some of the topics in the collection of particular interest for this chapter's context include:

• Best Practices
• Enterprise Architecture
• IT Security/Privacy
• GAO Reports
• IT Related Laws and Regulations

44.3.3.4 RFC2196 (Site Security Handbook).

The Internet Engineering Task Force (IETF) has an extensive list of informational documents called Requests for Comments (RFCs) governing all aspects of the Internet.¹⁵ One document of particular value to any organization trying to improve its security practices is the classic Site Security Handbook, RFC2196, edited by B. Fraser of the Software Engineering Institute at Carnegie Mellon University, the same body that hosts the CERT-CC.¹⁶ The Handbook has this structure:

Introduction

• Purpose of this Work
• Audience
• Definitions
• Related Work
• Basic Approach
• Risk Assessment

Security Policies

• What is a Security Policy and Why Have One?
• What Makes a Good Security Policy?
• Keeping the Policy Flexible

Architecture

• Objectives
• Network and Service Configuration
• Firewalls

Security Services and Procedures

• Authentication
• Confidentiality
• Integrity
• Authorization
• Access
• Auditing
• Securing Backups

Security Incident Handling

• Preparing and Planning for Incident Handling
• Notification and Points of Contact
• Identifying an Incident
• Handling an Incident
• Aftermath of an Incident
• Responsibilities

Ongoing Activities

Tools and Locations

Mailing Lists and Other Resources

References

44.3.3.5 IT-Grundschutz Catalogues.

The German government's computer security arm, the Bundesamt für Sicherheit in der Informationstechnik, has published a useful set of guidelines since 1997, the IT-Grundschutzhandbuch. Originally known in English as the IT Baseline Protection Manual, the most recent version as of this writing was published in 2005 and is available free in English as the IT-Grundschutz Catalogues.¹⁷ The work is freely available in PDF in German, English, Swedish, and Estonian.

In general, each module presents concepts, threats and vulnerabilities, and countermeasures. This work is easy to understand and provides a sound basis for effective information security protection.

44.3.4 Commercially Available Policy Guides.

There are several commercially available policy templates that save time when developing new policies or improving existing policies. Three of particular value are discussed next.

44.3.4.1 Charles Cresson Wood's ISPME.

The most widely used commercially available collection of security standards is the work by Charles Cresson Wood, Information Security Policies Made Easy (ISPME). The text includes a CD-ROM for easy access to the text so that users can avoid tedious retyping of existing materials.

Wood integrates the perspectives of both management and technical staff when making recommendations. He was one of the original promoters of information security as a way to achieve a competitive advantage and a coauthor of the first computer crime investigation manual. He was one of the first to advocate and document integration of information resource management concepts with information security activities, use of head-count ratio analysis to determine appropriate levels of information security staffing, an information security document life cycle for planning and budgeting purposes, and network management tools to achieve consistent and centralized systems security. He has also developed and successfully marketed two unique software packages that automate information security administration activities. In addition, he evaluated and recommended U.S. Government policies on open versus classified cryptographic research for Frank Press, President Carter's technology advisor.

One of the outstanding features of ISPME is that Wood explains every policy and sometimes provides opposing policies for use in different environments. His text is not only a set of templates but an excellent basis for teaching security principles by looking at the practice of security.

44.3.4.2 Tom Peltier's Practitioner's Reference.

Tom Peltier is the Year 2001 Hall of Fame Award Recipient from the Information Systems Security Association (www.issa.org). The citation (www.peltierassociates.com/) provides the background that explains why Peltier is so highly regarded in the field of security:

Peltier's policy text is Information Security Policies and Procedures. He provides you with the tools you need to develop policies, procedures, and standards. He demonstrates the importance of a clear, concise, and well-written security program. His examination of recommended industry best practices illustrates how they can be customized to fit any organization's needs.

44.3.4.3 SANS Resources.

The System Administration and Network Security (SANS) Institute is well known for the excellent security resources it makes available to members and the general public.

44.3.4.3.1 Security Essentials Courses.

The SANS Security Essentials Courses (www.sans.org/training/description.php?tid=672) provide a solid foundation for understanding the issues underlying security policies. Level 524, Security Policy & Awareness (www.sans.org/training/description.php?tid=368), highlights this objective:

44.3.4.3.2 Free Resources.

The SANS Institute offers many free resources. For details, see www.sans.org/free_resources.php?utm_source=web-sans&utm_medium=ImageReplace&utm_content=Main_resource_button_green&utm_campaign=HomePage&ref=3601. Topics include:

• Reading Room: Over 1,600 computer security white papers in over 70 categories
• Top 20: The Twenty Most Critical Internet Security Vulnerabilities
• Newsletters: Latest Security News

44.4 WRITING THE POLICIES.

How should one write security policies? Should they be suggestions? Orders? Positive? Negative? This section affirms that policies should be definite, unambiguous, and directive. In addition, all policies should have (preferably optional) explanations for the reasons behind them.

44.4.1 Orientation: Prescriptive and Proscriptive.

Security policies should be written with clear indications that all employees are expected to conform to them. Language should be definite and unambiguous (e.g., “All employees must…” or “No employees shall …”) Some policies require people to do something—these are prescriptive (e.g., “Employees must follow the password procedures defined by the In-formation Protection Group at all times.”) Other policies prohibit certain actions—these are proscriptive (e.g., “No employee shall make or order illegal copies of proprietary software under any circumstances.”)

44.4.2 Writing Style.

Each policy should be short. Simple declarative sentences are best; writers should avoid long compound sentences with multiple clauses. Details of implementation are appropriate for standards and procedures, not for policies. Policies can refer users to the appropriate documents for implementation details; for example, “Passwords shall be changed on a schedule defined in the Security Procedures from the Information Protection Group.”

For more details on developing policy, see Chapter 45 in this Handbook.

44.4.3 Reasons.

Few people like to be ordered about with arbitrary rules. Trying to impose what appear to be senseless injunctions can generate a tide of rebellion among employees. It is far better to provide explanations of why policies make sense for the particular enterprise; however, such explanations can make the policies tedious to read for more experienced users. A solution is to provide optional explanations. One approach is to summarize policies in one part of the document and then to provide an extensive expansion of all the policies in a separate section or a separate document. Another approach is to use hypertext, as explained in Section 44.6.3 of this chapter.

44.5 ORGANIZING THE POLICIES.

Policies are distinct from the sequence in which they are presented. It is useful to have two distinct presentation sequences for policies: topical and organizational.

44.5.1 Topical Organization.

Security involves a multitude of details; how one organizes these details depends on the purpose of the policy document. The most common format puts policies in a sequence that corresponds to some reasonable model of how people perceive security. For example, employees can look at security with a rough correspondence to the physical world. Under this model, one might have a policy document with a table of contents that looks like this:

Principles

Organizational Reporting Structure

Physical Security

• Servers
• Workstations
• Portable computers

Hiring, Management, and Firing

Data Protection

• Classifying information
• Data access controls
• Encryption
• Countering industrial espionage

Communications Security

• Perimeter controls
• Web usage and content filtering
• E-mail usage and privacy
• Telephone and fax usage

Software

• Authorized products only
• Proprietary (purchased) software
• Development standards
• Quality assurance and testing

Operating Systems

• Access controls
• Logging

Technical Support

• Service-level agreements
• Help desk functions

44.5.2 Organizational.

The complete set of policies may be comprehensive, concise, and well written, but they will still likely be a daunting document, especially for nontechnical staff. To avoid distressing employees with huge tomes of incomprehensible materials, it makes sense to create special-purpose documents aimed at particular groups. For example, one could have guides like these:

• General Guide for Protecting Corporate Information Assets
• Guide for Users of Portable Computers
• A Manager's Guide to Security Policies
• Human Resources and Security
• Network Administration Security Policies
• Programmer's Guide to Security and Quality Assurance
• The Operator's Security Responsibilities
• Security and the Help Desk

Each of these volumes or files can present just enough information to be useful and interesting to the readers without overwhelming them with detail. Each can make reference to the full policy document.

44.6 PRESENTING THE POLICIES.

What options do policy makers have for publishing their policies? This section discusses printing them on paper versus publishing them electronically.

44.6.1 Printed Text.

Policies are not inherently interesting. Large volumes full of policies quickly become shelfware. Short paper documents, however, are familiar to people; they can be carried around, or placed at hand for easy reference anywhere. Reference cards, summary sheets, stickers, and posters are some of the printed media that can be useful in security awareness, training, and education programs. Printed text, like its electronic versions, provides the opportunity for typeface and color to be used in clarifying and emphasizing specific ideas. However, printed copies of policies share a universal disadvantage: They are difficult to update.

Updating dozens, hundreds, or thousands of individual copies of policy documents can be such a headache that organizations simply reprint the entire document rather than struggle with updates. Updates on individual sheets require the cooperation of every user to insert the new sheets and remove the old ones; experience teaches that many people simply defer such a task, sometimes indefinitely, and that others have an apparently limited understanding of the sequential nature of page numbers. Badly updated policy guides may be worse than none at all, especially from a legal standpoint. If an employee violates a new policy that has been promulgated verbally, but available manuals fail to reflect that new policy, it may be difficult to justify dismissal for wrongdoing.

44.6.2 Electronic One-Dimensional Text.

Despite the familiarity and ubiquity of paper, in today's world of near-universal access to computers in the work environment, there is a place for electronic documentation of policies. Such publication has enormous advantages from an administrative standpoint. All access to the policies can be controlled centrally, at least in theory. Making the current version of the policies (and subsets of the policies, as explained in Section 44.5.2) available for reference on a server obviates the problem of updating countless independent copies and avoids the normal situation when using paper: chaotic differences among copies of different ages.

How can one cope with employees stubbornly determined to have their own local copies of the policies on their workstations? One solution to this problem of enforcing a single version is to alert every user to changes in the central copy, or to send every user copies of the appropriate documents by e-mail, with a request to replace their copies of lower version number. Although this solution is not perfect, it does help to keep most people up to date.

44.6.3 Hypertext.

Perhaps the most valuable contribution from electronic publication of policies is the availability of hypertext. Hypertext allows a reader to jump to a different section of text and then come back to the original place easily. On paper, forward and backward references are cumbersome, and most readers do not follow such links unless they are particularly keen on the extra information promised in the reference. In electronic files, however, additional information may be as easy to obtain as placing the cursor over a link and clicking.

The most important function of hypertext for policy documents is to provide definitions of technical terms and explanations of the reasons for specific policies.

Some users are more comfortable with printed policies. Hypertext, like other formats of text, generally permits users to print out their own copies of all or part of their policy documentation. Many of the tools also allow annotations by users on their own copy of a file.

44.6.3.1 HTML and XML.

The most widely used hypertext format today is Hypertext Markup Language (HTML). Its variant Extensible Markup Language (XML), provides additional functionality for programmers, but from the user's perspective, the hyperlinks are the same. A simple click of the mouse in a Web browser (e.g., Microsoft Internet Explorer, Netscape Communicator, or Firefox) branches to a different page. More sophisticated programming allows the use of frames and, with JAVA or ActiveX, pop-up windows. Navigation buttons allow the user to move backward to a previous page or forward to another page. Links also can be used to open new windows so that several pages are visible at once. All of these techniques allow users to move freely through a text with full control over the degree of detail they wish to pursue.

44.6.3.2 Rich Text Format and Proprietary Word Processor Files.

Some people prefer to use word processor files for hypertext. As long as everyone uses the same word processing software, this approach can work acceptably. For example, it is usually possible to insert a hyperlink to a section of a single document, to a location in a different file on disk, or to a page on the Web. Some word processors, such as Microsoft Word and Corel WordPerfect, allow one to insert pop-up comments; floating the cursor over highlighted text brings up a text box that can provide definitions and commentary.

In addition to explicit links, Microsoft Word and other modern word processing programs can display a table of headings that allows instant movement to any section of the document.

Rich text format (RTF) is a general format for interchanging documents among word processors, but the results are not always comparable. For example, a comment created using Microsoft Word shows up as a pop-up box with a word or phrase highlighted in the text; the same comment and marker read from an RTF file by Corel WordPerfect shows up as a balloon symbol in the left margin of the document.

44.6.3.3 Portable Document Format.

Adobe Acrobat's portable document format (PDF) provides all the hyperlinking that HTML offers, but it does so in a form that is universally readable and that can be controlled more easily. The free Acrobat reader is available for multiple operating systems from www.adobe.com. PDF documents can be locked easily, for example, so that no unauthorized changes can be made. In addition, unlike HTML and word processor documents, PDF files can be constructed to provide near-perfect reproduction of their original appearance even if not all the fonts used by the author are present on the target computer system. To create PDF files, one uses the Acrobat product; the installation adds two printers to the printer list. The Acrobat PDFWriter program produces relatively crude output that does not always look identical on all systems, but the Acrobat Distiller program produces highly controllable output with uniform properties. Adobe Acrobat also allows one to create a detailed table of contents for documents.

44.6.3.4 Help Files.

Help files also provide hypertext capability. In the Windows environment, one can create help files using utilities such as Help & Manual from www.ec-software.com or AnetHelpTool from www.anetsoft.com/aht32/en/product_descr.htm. Entering the search string “create help files” into a search engine such as Google (www.google.com) brings up many pages of such tools. Windows Help files can be distributed easily to any Windows user because they are relatively small, and they are loaded almost instantly by the Help subsystem. In addition, users are permitted to add their own notes to such documents and can easily print out sections if they wish.

44.7 MAINTAINING POLICIES.

No fixed policy document can cover all eventualities. The information security field changes constantly, and so must policies. Information security is a process much like total quality management: For success, both require a thoroughgoing integration into corporate culture.

Above all, some named individuals must see maintaining security policies as an explicitpartof their job descriptions. Hoping that someone will spontaneously maintain security policies is like hoping that someone will spontaneously maintain financial records. However, as explained in Chapter 45 of this Handbook, security policies should represent the best efforts of people from throughout the organization, not the arbitrary dictates of just one person.

44.7.1 Review Process.

An information protection working group can meet regularly—quarterly is a good frequency to try—to review all or part of the policies. Employees can be encouraged to suggest improvements in policies or to propose new policies. The working group can identify key areas of greatest change and work on those first, leaving minor policy changes to subcommittees. Members of the working group should discuss ideas with their colleagues from throughout the enterprise, not just with each other. Every effort should contribute to increasing the legitimate sense of involvement in security policy by all employees, including managers and executives.

44.7.2 Announcing Changes.

Drafts of the new versions can be circulated to the people principally affected by changes, so that their responses can improve the new edition. Truly respectful inquiry will result in a greater sense of ownership of the policies by employees, although few of them will rejoice in the new policies. Some employees will see new security policies merely as a mild irritant, while others may view them as a tremendous obstacle to productivity and a general nuisance.

Ideally, major changes in policy should be described and explained in several ways. For example, a letter or e-mail (digitally signed, for security) from the president, chair of the board of directors, chief officers, or chief information security officer can announce important changes in policy and the reasons for the changes. A brief article in the organization's internal newsletter, or a spot on the intranet, can also provide channels for communicating the policy decisions to everyone involved.

Finally, the updated policies can be made available or distributed to all employees using some of the channels discussed in Section 44.6.

44.8 SUMMARY.

These 10 recommendations will help in preparing to create and implement security policies:

1. Distinguish among policies, controls, standards, and procedures.
2. Use all resources from government, industry bodies, and commercial organizations in preparing to create policies.
3. Use unambiguous prose when defining policies: Tell people what to do and what not to do.
4. Use short sentences.
5. Give reasons for policies.
6. Provide different views of policies—topical and organizational.
7. Provide several ways of reading the policies, including printed text, electronic text, and hypertext.
8. Review and improve or adapt policies regularly.
9. Circulate drafts showing changes in policies to interested participants before publishing them.
10. Announce major changes using high-level authorities within the enterprise.

44.9 FURTHER READING

Allen, J. H. The CERT^® Guide to System and Network Security Practices. Reading, MA: Addison-Wesley, 2001.

Barman, S. Writing Information Security Policies. Indianapolis: New Riders, 2002.

Boran, S. “IT Security Cookbook,” 2003; www.boran.com/security/index.html.

Clarke, R. “Best Practice Guidelines: Controls over the Security of Personal Information,” 1993; www.anu.edu.au/people/Roger.Clarke/DV/PDSecy.html.

Egan, M. and T. Mather. The Executive Guide to Information Security: Threats, Challenges, and Solutions. Reading, MA: Addison-Wesley. 2004.

Flynn, N. The E-Policy Handbook: Designing and Implementing Effective E-Mail, Internet, and Software Policies. Herndon, VA: AMACOM, 2001.

INFOSYSSEC. “Security Standards, Laws and Guidelines,” 2008; www.infosyssec.org/infosyssec/secstan1.htm.

NSA. “NSA Security Guidelines Handbook,” Fort Meade, MD: National Security Agency Central Security Service, 2002; www.tscm.com/NSAsecmanual1.html.

Overly, M. E. E-Policy: How to Develop Computer, E-Policy and Internet Guidelines to Protect Your Company and Its Assets. Herndon, VA: AMACOM, 1998.

Peltier, T. R. Information Security Policies and Procedures: A Practitioner's Reference, 2nd ed. Boca Raton, FL: Auerbach, 2004.

RUsecure. Information Security Policies: Securing Information in the Digital Age. Macclesfield (Cheshire), U.K.: RUsecure Information Security, 2001; www.information-security-policies.com/index.htm.

Wood, C. C. Information Security Policies Made Easy, version 10. Houston: Information Shield, 2005; www.informationshield.com/ispmemain.htm.

44.10 NOTES