This document provides guidance on writing an effective network security policy. It explains that writing security policies is challenging and requires understanding what should be included and who is responsible. The author developed a Network Security Policy Manual (NSPM) based on standards from ISF and ISO to provide an example. When writing policies, it is important to transform standard language into enforceable policy statements, avoid defining specific technologies, and ensure all sections work together cohesively. Maintaining and updating the security policy is crucial to protecting organizational assets and data.

1. Journal Online
How to Write a Security Policy:
Network Security Policy Manual
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.
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 Evolution
How 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
• urpose
P
• bjective
O
• pplicability
A
• istribution
D
• nforcement
E
• onitoring
M
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
Practice 4 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 Pains
Throughout the writing and review of the NSPM,
a continual discovery process revealed small
changes to improve clarity of the policy. These
included:
• eadings should be used to group common
H
policy statements.
• oles and responsibilities must be defined
R
to eliminate any doubt of responsibility. To
accomplish this, roles should be grouped by
position, e.g., director of network security,
ISACA JOURNAL VOLUME 1, 2009
1

2. 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.
• policy manual must be developed, as opposed to four
A
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. 1
An 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.
Figure 1—Example 1 Policy Statement Development
Example: Principle and objective statements (from ISF) for Incident
Management Control (NW3.3)
Policy Writing Example No. 2
The 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. 3
One 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. 4
Finally, 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
P
rinciple: All network incidents—of any type—should be
recorded, reviewed and resolved using an incident management
process.
Example: Network Resilience Control (NW1.3.3) (from ISF).
O
bjective: To identify and resolve network incidents effectively,
their business impact should be minimized, reducing the risk of
similar incidents occurring.
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: 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.
2
ISACA JOURNAL VOLUME ONE 2009
Figure 2—Example 2 Policy Statement Development
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.

3. 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.
Conclusion
Writing 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.
Endnotes
S
imon, 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,
1
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
S
ANS Institute, Security Policy Project,
www.sans.org/resources/policies
3
T
he 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
I
nformation Security Forum, The Standard of Good Practice,
https://www.isfsecuritystandard.com/SOGP07/index.htm
5
I
nternational 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 Note
The 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
ISACA JOURNAL VOLUME 1, 2009
0