1ISACA JOURNAL VOLUME 1, 2009

Journal Online

For any security professional attempting to write a security policy, it is critical to understand the difficulty and “hair-pulling” nature of the task. What should be written? How should it be written? Who is responsible? Writing information security policies is an art form. Anyone who thinks that their organization’s 80-page security manual underwent writing and approval in a couple of days should think again.

This article explains the approach the author adopted to create the “ultimate” network security policy manual. While some policy requirements may be cost-prohibitive or a logistical headache in certain environments, the idea is similar to a holiday wish list where people list everything they desire, except this is for a security environment. This policy will evolve and mature as personal experience advances, threats change and security adapts. It is important to keep the policy breathing, as it is a living document; it should not be neglected. The security arena changes rapidly and the security policy must keep pace.

Existing REsouRcEs and Policy EvolutionHow does one effectively transform ideas and strategies into a security policy? Most security professionals appreciate that executive support is crucial to implement and sustain an information security program. To acquire and maintain this support, the scope of the policy must be explicitly defined and the policy statements must be relevant and communicated to all employees.

Existing resources explain the process of outlining a security policy manual including:1 • Purpose• Objective • Applicability • Distribution • Enforcement • Monitoring

Additionally, the SANS Institute has several examples in its Security Policy Project.2

An article may say to write a policy addressing risk; what does that mean? Risks to network security are defined by addressing security standards. This article details what to document within the sections listed previously and how to use a standard effectively to introduce a network

security policy, providing business and IT context. The objective is to take the language from the standard and develop the policy statements.

The author’s Network Security Policy Manual (NSPM)3 is based primarily on the Information Security Forum (ISF)’s The Standard of Good Practice4 and secondarily on ISO 17799:20055 from the International Organization for Standardization (ISO).6

Focusing on the networks domain of the ISF standard, the NSPM covers the requirements of four of the five control objectives:• Network management• Traffic management• Network operations• Local security management

Voice networks (the fifth control objective, not listed above) was not included in the scope of this policy. An easy way to write policy statements is to transform the standard’s language into a policy statement, addressing an organization’s acceptable level of risk. For the purpose of the NSPM (and the scope of the voice networks control objective of the ISF standard), voice networks did not represent a risk to the overall network and the domain was subsequently dropped.

Additionally, the NSPM contains statements not found in the ISF standard. Incorporating details beyond the scope of the standard, the NSPM includes a control for network security and contains significant detail in the firewall control. An individual standard is not a single, encompassing solution; however, it may be used to jumpstart thoughts and ideas on how to harden network security.

gRowing PainsThroughout the writing and review of the NSPM, a continual discovery process revealed small changes to improve clarity of the policy. These included:• Headings should be used to group common

policy statements. • Roles and responsibilities must be defined

to eliminate any doubt of responsibility. To accomplish this, roles should be grouped by position, e.g., director of network security,

Paul R. Meynen is an

information security

consultant in Chicago,

Illinois, USA. He completed

the Network Security

Policy Manual as part of

an independent study

course at DePaul University,

administered by James Krev.

Meynen may be reached at

MeynenP@gmail.com.

How to Write a Security Policy: Network Security Policy Manual

2 ISACA JOURNAL VOLUME ONE 2009

network security engineers, network security architects. Early drafts defined roles and responsibilities throughout the policy, creating disjointedness and lacking cohesion. Defining roles and responsibilities in the beginning of the policy establishes a foundation for managing the network security program. Moreover, this section deserves special attention because under the umbrella of an enterprisewide information security program, roles and responsibilities would be defined within an acceptable-use policy. With the narrow focus of the NSPM on network security, the network management control objective addresses roles and responsibilities.

• A policy manual must be developed, as opposed to four individual policies. Using four separate policies would lack continuity, making it difficult to correlate statements across policies. While the four control objectives listed previously are individual policies, creating a manual with chapters provides context and continuity throughout the entire policy. Moreover, defining metadata (e.g., applicability, distribution) in the introduction to the policy facilitates easier management, as all subsequent policies adhere to a single rule set.

Policy wRiting ExaMPlE no. 1An introduction must precede both a policy and its control objectives. This provides context to the reader and places focus on the subsequent policy statements. The ISF standard and ISO 17799 provide introductory statements prior to each domain and control objective. Additionally, ISO 17799 uses implementation guidance for each control, offering direction when constructing policy statements. Leveraging the implementation guidance and summaries will assist in introducing a domain and its associated control objective(s).

A standard, such as the ISF’s, uses the word “should” consistently. The use of “should” in a policy will not suffice, as it leaves potential for interpretation and presents difficulty in enforcing policy following a security incident. A policy is a set of rules; therefore, the words “must” or “will” are used to enforce the policy statements. See figure 1.

Policy wRiting ExaMPlE no. 2The ISF standard suggests that to alleviate a malfunction of network resources, a company should ensure that network components may be recovered. The NSPM identifies that critical systems must be recovered first and that capacity must exist to recover those systems (figure 2). Furthermore, the NSPM incorporates recovery time objectives from the business continuity plan, clearly specifying a value beyond “critical timescales.”

Policy wRiting ExaMPlE no. 3One must avoid defining a product or technology as it creates restrictions. For example:

External access should be provided using a Kerberos authentication server, which should provide reliable and complete authentication for external connections.

This explicit definition will cause problems. If the authentication technology changes to another solution, the policy manual must be reviewed and updated. Instead, this policy statement must be used:

A dedicated remote access server will be used for all external access; it must authenticate external connections using a reliable and accepted access control (e.g., Kerberos, TACACS+, Radius).

The term “e.g.” is very useful as it means “for example” and is similar to “including.” In other words, “e.g.” allows for the mentioning of sample technologies while not intending to list all possible solutions.

Policy wRiting ExaMPlE no. 4Finally, remember that the NSPM focuses on network security. There are additional domains in the ISF and ISO 17799 standards that would exist within an enterprisewide security program. The NSPM seeks

Figure 1—Example 1 Policy statement development

Example: Principle and objective statements (from ISF) for Incident Management Control (NW3.3)

Principle: All network incidents—of any type—should be recorded, reviewed and resolved using an incident management process.

objective: To identify and resolve network incidents effectively, their business impact should be minimized, reducing the risk of similar incidents occurring.

Policy statement: Any incident occurring on the network must be recorded, reviewed and resolved following an established incident management process. Incident management allows for rapid response and efficient resolution to mitigate impact to the business and future risk of similar incidents.

Figure 2—Example 2 Policy statement development

Example: Network Resilience Control (NW1.3.3) (from ISF).

The risk of malfunction of critical communications equipment, software, links and services should be reduced by ensuring that key network components can be replaced within critical timescales.

Policy statement: To mitigate the risk and effects of a malfunction, priority must be given to critical system segments and proper capacity allocated to those segments by ensuring that key network components are capable of being replaced within the specified recovery time objectives.

0ISACA JOURNAL VOLUME 1, 2009

to encompass the aspects of the enterprise program while not defining rules that would be out of scope. For example, the wireless access control in the NSPM states:

Documentation must be maintained for wireless connections. It must include the configuration of wireless hardware to maintain point-to-point hardware encryption of a minimum strength.

Defining a 128-bit encryption standard, for example, is beyond the scope of the NSPM. This policy statement would belong within an acceptable encryption policy.

conclusionWriting security policies is challenging. It requires the coordination of resources and cooperation of employees throughout the company. However, policy writing is an indispensable skill, because, when a policy is established, it must undergo reviews and updates (most often annually). Maintenance of the security policy is equally important for daily business activities and defense against internal and external malicious threats. The security of personnel data and customers’ personally identifiable information is imperative to the business. Securing credit card data, medical information or (in the US) a Social Security number, for example, is the basis of the NSPM. It is the heart of an enterprise information security program.

EndnotEs1 Simon, Mark; “An Enterprise Security Policy Management Framework Part 1 & 2,” ISSA Journal, February 2008, www.issa.org/Members/Journals-Archive/2008.html. SANS Institute, “Building a Security Policy Framework for a Large, Multi-national Company,” January 2005,

www.giac.org/certified_professionals/practicals/gsec/4276.php. Gartenberg, Marc; “How to Develop an Enterprise Security Policy,” ComputerWorld, January 2005, www.computerworld.com/securitytopics/security/story/0,10801, 98896,00.html. Ungerman, Mark; “Creating and Enforcing an Effective Information Security Policy,” Information Systems Control Journal, ISACA, vol. 6, 2005

2 SANS Institute, Security Policy Project, www.sans.org/resources/policies

3 The Network Security Policy Manual is an original, copyrighted creation of the author (Paul Meynen). To obtain a copy of the NSPM, please e-mail MeynenP@gmail.com.

4 Information Security Forum, The Standard of Good Practice, https://www.isfsecuritystandard.com/SOGP07/index.htm

5 International Organization for Standardization, ISO 17799:2005, Information Technology—Security Techniques—Code of Practice for Information Security Management, 2005, www.iso.org

6 A copy of ISO 17799:2005 was not obtained by the author until the end of the course in which he developed the NSPM. Consequently, there was not sufficient time to incorporate all the additional policy statements recommended in ISO 17799:2005. However, ISO 17799:2005 presents an incredible level of detail and is a robust standard to implement a security program. As the NSPM evolves, the implementation guidance (explained later) in the ISO standard will be leveraged to incorporate new statements into the NSPM.

authoR’s notEThe author would like to thank James Krev for his patience and guidance in support of this research at DePaul University, as well as Jacob Furst and Linda Allen for their meticulous editing of the work.

The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the Information Systems Control Journal.

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.

© 2009 ISACA. All rights reserved.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.

www.isaca.org