Chapter 2

Cybersecurity Policy Organization, Format, and Styles

In Chapter 1, “Understanding Cybersecurity Policy and Governance,” you learned that policies have played a significant role in helping us form and sustain our social, governmental, and corporate organizations. In this chapter, we begin by examining the hierarchy and purpose of guiding principles, policy, standards, procedures, and guidelines, as well as adjunct plans and programs. Returning to our focus on policies, we examine the standard components and composition of a policy document. You will learn that even a well-constructed policy is useless if it doesn’t deliver the intended message. The end result of complex, ambiguous, or bloated policy is, at best, noncompliance. At worst, it leads to negative consequences, because such policies may not be followed or understood. In this chapter, you will be introduced to “plain language,” which means using the simplest, most straightforward way to express an idea. Plain-language documents are easy to read, understand, and act on. By the end of the chapter, you will have the skills to construct policy and companion documents. This chapter focuses on cybersecurity policies in the private sector and not policies created by governments of any country or state.

Cybersecurity policies should reflect the guiding principles and organizational objectives. This is why it is very important to communicate clear and well-understood organizational objectives within an organization. Standards are a set of rules and mandatory actions that provide support to a policy. Guidelines, procedures, and baselines provide support to standards. Let’s take a closer look at each of these concepts.

1. All users must have a unique user ID and password that conforms to the company password standard.

2. Users must not share their password with anyone regardless of title or position.

3. If a password is suspected to be compromised, it must be reported immediately to the help desk, and a new password must be requested.

The password standard would then dictate the required password characteristics, such as the following:

• Minimum of eight upper- and lowercase alphanumeric characters

• Must include at least one special character (such as *, &, $, #, !, or @)

• Must not include the user’s name, the company name, or office location

• Must not include repeating characters (for example, 111)

Another example of a standard is a common configuration of infrastructure devices such as routers and switches. Organizations may have dozens, hundreds, or even thousands of routers and switches, and they may have a “standard” way of configuring authentication, authorization, and accounting (AAA) for administrative sessions. They may use TACACS+ or RADIUS as the authentication standard mechanism for all routers and switches within the organization.

As you can see, the policy represents expectations that are not necessarily subject to changes in technology, processes, or management. The standard, however, is very specific to the infrastructure.

Standards are determined by management, and unlike policies, they are not subject to Board of Directors authorization. Standards can be changed by management as long as they conform to the intent of the policy. A difficult task of writing a successful standard for a cybersecurity program is achieving consensus by all stakeholders and teams within an organization. Additionally, a standard does not have to address everything that is defined in a policy. Standards should be compulsory and must be enforced to be effective.

The primary objective of a baseline is uniformity and consistency. An example of a baseline related to our password policy and standard example is the mandate that a specific Active Directory Group Policy configuration (the standard) be used on all Windows devices (the group) to technically enforce security requirements, as illustrated in Figure 2-2.

In this example, by applying the same Active Directory Group Policy to all Windows workstations and servers, the baseline was implemented throughout the organization. In this case, there is also assurance that new devices will be configured accordingly.

Figure 2-3 shows another example of how different baselines can be enforced in the infrastructure with more sophisticated systems, such as the Cisco Identity Service Engine (ISE). Network Access Control (NAC) is a multipart solution that validates the security posture of an endpoint system before entering the network. With NAC, you can also define what resources the endpoint has access to, based on the results of its security posture. The main goal of any NAC solution is to improve the capability of the network to identify, prevent, and adapt to threats. The Cisco ISE shown in Figure 2-3 centralizes network access control based on business role and security policy to provide a consistent network access policy for end users, whether they connect through wired, wireless, or VPN. All this can be done from a centralized ISE console that then distributes enforcement across the entire network and security infrastructure.

In Figure 2-3, three different endpoint systems were denied or rejected access to the network because they didn’t comply with a corporate baseline.

“A good way to create a strong password is to think of a phrase, song title, or other group of words that is easy to remember and then convert it, like this:

• “The phrase ‘Up and at ‘em at 7!’ can be converted into a strong password such as up&atm@7!.

• “You can create many passwords from this one phrase by changing the number, moving the symbols, or changing the punctuation mark.”

This guideline is intended to help readers create easy-to-remember, yet strong passwords.

Guidelines are recommendations and advice to users when certain standards do not apply to your environment. Guidelines are designed to streamline certain processes according to best practices and must be consistent with the cybersecurity policies. On the other hand, guidelines often are open to interpretation and do not need to be followed to the letter.

• Simple Step: Lists sequential actions. There is no decision making.

• Hierarchical: Includes both generalized instructions for experienced users and detailed instructions for novices.

• Graphic: This format uses either pictures or symbols to illustrate the step.

• Flowchart: Used when a decision-making process is associated with the task. Flowcharts are useful when multiple parties are involved in separate tasks.

In keeping with our previous password example, the following is a Simple Step procedure for changing a user’s Windows password (Windows 7 and earlier):

1. Press and hold the Ctrl+Alt+Delete keys.

2. Click the Change Password option.

3. Type your current password in the top box.

4. Type your new password in both the second and third boxes. (If the passwords don’t match, you will be prompted to reenter your new password.)

5. Click OK, and then log in with your new password.

The following is the procedure to change your Windows password (Windows 10 and later):

1. Click Start.

2. Click your user account on the top, and select Change Account Settings.

3. Select Sign-in Options on the left panel.

4. Click the Change button under Password.

5. Enter your current password, and hit Next.

6. Type your new password and reenter it. Enter a password hint that will help you in case you forget your password.

Procedures should be well documented and easy to follow to ensure consistency and adherence to policies, standards, and baselines. Like policies and standards, they should be well reviewed to ensure that they accomplish the objective of the policy and that they are accurate and still relevant.

• Vendor Management Plan

• Incident Response Plan

• Business Continuity Plan

• Disaster Recovery Plan

Policies and plans are closely related. For example, an Incident Response Policy will generally include the requirement to publish, maintain, and test an Incident Response Plan. Conversely, the Incident Response Plan gets its authority from the policy. Quite often, the policy will be included in the plan document.

No single technique defines plain language. Rather, plain language is defined by results—it is easy to read, understand, and use. Studies have proven that documents created using plain-language techniques are effective in a number of ways:¹

• Readers understand documents better.

• Readers prefer plain language.

• Readers locate information faster.

• Documents are easier to update.

• It is easier to train people.

• Plain language saves time and money.

Even confident readers appreciate plain language. It enables them to read more quickly and with increased comprehension. The use of plain language is spreading in many areas of American culture, including governments at all levels, especially the federal government, health care, the sciences, and the legal system.

In 1971, the National Council of Teachers of English in the United States formed the Public Doublespeak Committee. In 1972, U.S. President Richard Nixon created plain language momentum when he decreed that the “Federal Register be written in ‘layman’s terms.’” The next major event in the U.S. history of plain language occurred in 1978, when U.S. President Jimmy Carter issued Executive Orders 12,044 and 12,174. The intent was to make government regulations cost-effective and easy to understand. In 1981, U.S. President Ronald Reagan rescinded Carter’s executive orders. Nevertheless, many continued their efforts to simplify documents; by 1991, eight states had passed statutes related to plain language.

In 1998, then-President Clinton issued a Presidential Memorandum requiring government agencies to use plain language in communications with the public. All subsequent administrations have supported this memorandum. In 2010, plain-language advocates achieved a major victory when the Plain Writing Act was passed. This law requires federal government agencies to write publications and forms in a “clear, concise, well-organized” manner using plain language guidelines.

We can take a cue from the government and apply these same techniques when writing policies, standards, guidelines, and plans. The easier a policy is to understand, the better the chance of compliance.

1. Write for your audience. Use language your audience knows and is familiar with.

2. Write short sentences. Express only one idea in each sentence.

3. Limit a paragraph to one subject. Aim for no more than seven lines.

4. Be concise. Leave out unnecessary words. Instead of “for the purpose of,” use “to.” Instead of “due to the fact that,” use “because.”

5. Don’t use jargon or technical terms when everyday words have the same meaning.

6. Use active voice. A sentence written in the active voice shows the subject acting in standard English sentence order: subject–verb–object. Active voice makes it clear who is supposed to do what. It eliminates ambiguity about responsibilities. Not “it must be done” but “you must do it.”

7. Use “must,” not “shall,” to indicate requirements. “Shall” is imprecise. It can indicate either an obligation or a prediction. The word “must” is the clearest way to convey to your audience that they have to do something.

8. Use words and terms consistently throughout your documents. If you use the term “senior citizens” to refer to a group, continue to use this term throughout your document. Don’t substitute another term, such as “the elderly” or “the aged.” Using a different term may cause the reader to wonder if you are referring to the same group.

9. Omit redundant pairs or modifiers. For example, instead of “cease and desist,” use either “cease” or “desist.” Even better, use a simpler word such as “stop.” Instead of saying “the end result was the honest truth,” say “the result was the truth.”

10. Avoid double negatives and exceptions to exceptions. Many ordinary terms have a negative meaning, such as unless, fail to, notwithstanding, except, other than, unlawful (“un-” words), disallowed (“dis-” words), terminate, void, insufficient, and so on. Watch out for them when they appear after “not.” Find a positive word to express your meaning.

Want to learn more about using plain language? The official website of PLAIN has a wealth of resources, including the Federal Plain Language Guidelines, training materials and presentations, videos, posters, and references.

There are two general ways to structure and format your policy:

• Singular policy: You write each policy as a discrete document.

• Consolidated policy: Grouping similar and related policies together.

Consolidated policies are often organized by section and subsection.

Table 2-1 illustrates policy document format options.

The advantage to individual policies is that each policy document can be short, clean, and crisp, and targeted to its intended audience. The disadvantage is the need to manage multiple policy documents and the chance that they will become fragmented and lose consistency. The advantage to consolidation is that it presents a composite management statement in a single voice. The disadvantage is the potential size of the document and the reader challenge of locating applicable sections.

In the first edition of this book, we limited our study to singular documents. Since then, both the use of technology and the regulatory landscape have increased exponentially—only outpaced by escalating threats. In response to this ever-changing environment, the need for and number of policies has grown. For many organizations, managing singular policies has become unwieldy. The current trend is toward consolidation. Throughout this edition, we are going to be consolidating policies by security domain.

Regardless of which format you choose, do not include standards, baselines, guidelines, or procedures in your policy document. If you do so, you will end up with one big unruly document. And you will undoubtedly encounter one or more of the following problems:

• Management challenge: Who is responsible for managing and maintaining a document that has multiple contributors?

• Difficulty of updating: Because standards, guidelines, and procedures change far more often than policies, updating this whale of a document will be far more difficult than if these elements were properly treated separately. Version control will become a nightmare.

• Cumbersome approval process: Various regulations as well as the Corporate Operating Agreement require that the Board of Directors approve new policies as well as changes. Mashing it all together means that every change to a procedure, guideline, or standard will potentially require the Board to review and approve. This will become very costly and cumbersome for everyone involved.

• For singular policy documents, this information is split between the policy heading and the administrative notation sections.

• For consolidated policy documents, a version control table is included either at the beginning of the document or at the beginning of a section.

• To provide context and meaning

• To convey the importance of understanding and adhering to the policy

• To acquaint the reader with the document and its contents

• To explain the exemption process as well as the consequence of noncompliance

• To reinforce the authority of the policy

The first part of the introduction should make the case for why policies are necessary. It is a reflection of the guiding principles, defining for the reader the core values the company believes in and is committed to. This is also the place to set forth the regulatory and contractual obligations that the company has—often by listing which regulations, such as GLBA, HIPAA, or MA CMR 17 201, pertain to the organization as well as the scope of the policy.

The second part of the introduction should leave no doubt that compliance is mandatory. A strong statement of expectation from a senior authority, such as the Chairman of the Board, CEO, or President, is appropriate. Users should understand that they are unequivocally and directly responsible for following the policy in the course of their normal employment or relationship with the company. It should also make clear that questions are welcome and a resource is available who can clarify the policy and/or assist with compliance.

The third part of the introduction should describe the policy document, including the structure, categories, and storage location (for example, the company intranet). It should also reference companion documents such as standards, guidelines, programs, and plans. In some cases, the introduction includes a revision history, the stakeholders that may have reviewed the policy, and who to contact to make any modifications.

The fourth part of the introduction should explain how to handle situations where compliance may not be feasible. It should provide a high-level view of the exemption and enforcement process. The section should also address the consequences of willful noncompliance.

• For singular policy documents, the introduction should be a separate document.

• For consolidated policy documents, the introduction serves as the preface and follows the version control table.

• Singular policies must be able to stand on their own, which means it is necessary to include significant logistical detail in each heading. The information contained in a singular policy heading may include the organization or division name, category (section), subsection, policy number, name of the author, version number, approval authority, effective date of the policy, regulatory cross-reference, and a list of supporting resources and source material. The topic is generally self-explanatory and does not require an overview or explanation.

• In a consolidated policy document, the heading serves as a section introduction and includes an overview. Because the version number, approval authority, and effective date of the policy have been documented in the version control table, it is unnecessary to include them in section headings. Regulatory cross-reference (if applicable), lead author, and supporting documentation are found in the Administrative Notation section of the policy.

• Singular policies list the goals and objectives either in the policy heading or in the body of the document.

• In a consolidated policy document, the goals and objectives are grouped and follow the policy heading.

An exemption or waiver process is required for exceptions identified after the policy has been authorized. The exemption process should be explained in the introduction. The criteria or conditions for exemptions should not be detailed in the policy, only the method or process for requesting an exemption. If we try to list all the conditions to which exemptions apply, we risk creating a loophole in the exemption itself. It is also important that the process follow specific criteria under which exemptions are granted or rejected. Whether an exemption is granted or rejected, the requesting party should be given a written report with clear reasons either way.

Finally, it is recommended that you keep the number of approved exceptions and exemptions low, for several reasons:

• Too many built-in exceptions may lead employees to perceive the policy as unimportant.

• Granting too many exemptions may create the impression of favoritism.

• Exceptions and exemptions can become difficult to keep track of and successfully audit.

If there are too many built-in exceptions and/or exemption requests, it may mean that the policy is not appropriate in the first place. At that point, the policy should be subject to review.

An effective method of motivating compliance is proactive training. All employees should be trained in the acceptable practices presented in the security policy. Without training, it is hard to fault employees for not knowing they were supposed to act in a certain fashion. Imposing disciplinary actions in such situations can adversely affect morale. We take a look at various training, education, and awareness tools and techniques in later chapters.

• Singular policies incorporate administrative notations either in the heading, at the end of the document, or split between the two locations. How this is handled depends on the policy template used by the company.

• In a consolidated policy document, the administrative notations are located at the end of each section.

The general rule is to include definitions for any instance of industry-specific, technical, legal, or regulatory language. When deciding what terms to include, it makes sense to err on the side of caution. The purpose of the security policy as a document is communication and education. The target audience for this document usually encompasses all employees of the company, and sometimes outside personnel. Even if some technical topics are well known to all in-house employees, some of those outside individuals who come in contact with the company—and therefore are governed by the security policy—may not be as well versed in the policy’s technical aspects.

Simply put, before you begin writing down definitions, it is recommended that you first define the target audience for whom the document is crafted, and cater to the lowest common denominator to ensure optimum communication efficiency.

Another reason why definitions should not be ignored is for the legal ramification they represent. An employee cannot pretend to have thought that a certain term used in the policy meant one thing when it is clearly defined in the policy itself. When you’re choosing which words will be defined, therefore, it is important not only to look at those that could clearly be unknown, but also those that should be defined to remove any and all ambiguity. A security policy could be an instrumental part of legal proceedings and should therefore be viewed as a legal document and crafted as such.

Writing policy documents is a multistep process. First, we need to define the audience for which the document is intended. Then, we choose the format. Options are to write each policy as a discrete document (singular policy) or to group like policies together (consolidated policy). Last, we need to decide upon the structure, including the components to include and in what order.

The first and arguably most important section is the introduction. This is our opportunity to connect with the reader and to convey the meaning and importance of our policies. The introduction should be written by the “person in charge,” such as the CEO or President. This person should use the introduction to reinforce company-guiding principles and correlate them with the rules introduced in the security policy.

Specific to each policy are the heading, goals and objectives, the policy statement, and (if applicable) exceptions. The heading identifies the policy by name and provides the reader with an overview of the policy topic or category. The goals and objectives convey what the policy is intended to accomplish. The policy statement is where we lay out the rules that need to be followed and, in some cases, reference the implementation instructions (standards) or corresponding programs. Policy exceptions are agreed waivers that are documented within the policy.

An exemption or waiver process is required for exceptions identified after a policy has been authorized. The policy enforcement clause is where the sanctions for willful non-adherence to the policy are unequivocally stated to reinforce the seriousness of compliance. Administrative notations refer the reader to additional information and/or provide a reference to an internal resource. The policy definition section is a glossary of terms, abbreviations, and acronyms used in the document that the reader may be unfamiliar with.

Recognizing that the first impression of a document is based on its style and organization, we studied the work of the Plain Language Movement. Our objective for using plain language is to produce documents that are easy to read, understand, and use. We looked at ten techniques from the Federal Plain Language Guideline that we can (and should) use for writing effective policies. In the next section of the book, we put these newfound skills to use.

A. Guiding principles, regulations, laws, and procedures

B. Guiding principles, standards, guidelines, and procedures

C. Guiding principles, instructions, guidelines, and programs

D. None of the above

2. Which of the following statements best describes the purpose of a standard?

A. To state the beliefs of an organization

B. To reflect the guiding principles

C. To dictate mandatory requirements

D. To make suggestions

3. Which of the following statements best describes the purpose of a guideline?

A. To state the beliefs of an organization

B. To reflect the guiding principles

C. To dictate mandatory requirements

D. To help people conform to a standard

4. Which of the following statements best describes the purpose of a baseline?

A. To measure compliance

B. To ensure uniformity across a similar set of devices

C. To ensure uniformity and consistency

D. To make suggestions

5. Simple Step, Hierarchical, Graphic, and Flowchart are examples of which of the following formats?

A. Policy

B. Program

C. Procedure

D. Standard

6. Which of the following terms best describes instructions and guidance on how to execute an initiative or how to respond to a situation, within a certain time frame, usually with defined stages and with designated resources?

A. Plan

B. Policy

C. Procedure

D. Package

7. Which of the following statements best describes a disadvantage to using the singular policy format?

A. The policy can be short.

B. The policy can be targeted.

C. You may end up with too many policies to maintain.

D. The policy can easily be updated.

8. Which of the following statements best describes a disadvantage to using the consolidated policy format?

A. Consistent language is used throughout the document.

B. Only one policy document must be maintained.

C. The format must include a composite management statement.

D. The potential size of the document.

9. Policies, standards, guidelines, and procedures should all be in the same document.

A. True

B. False

C. Only if the company is multinational

D. Only if the documents have the same author

10. Version control is the management of changes to a document and should include which of the following elements?

A. Version or revision number

B. Date of authorization or date that the policy took effect

C. Change description

D. All of the above

11. What is an exploit?

A. A phishing campaign

B. A malicious program or code designed to “exploit” or take advantage of a single vulnerability or set of vulnerabilities

C. A network or system weakness

D. A protocol weakness

12. The name of the policy, policy number, and overview belong in which of the following sections?

A. Introduction

B. Policy Heading

C. Policy Goals and Objectives

D. Policy Statement

13. The aim or intent of a policy is stated in the ________.

A. introduction

B. policy heading

C. policy goals and objectives

D. policy statement

14. Which of the following statements is true?

A. A security policy should include only one objective.

B. A security policy should not include any exceptions.

C. A security policy should not include a glossary.

D. A security policy should not list all step-by-step measures that need to be taken.

15. The _________ contains the rules that must be followed.

A. policy heading

B. policy statement

C. policy enforcement clause

D. policy goals and objectives

16. A policy should be considered _____.

A. mandatory

B. discretionary

C. situational

D. optional

17. Which of the following best describes policy definitions?

A. A glossary of terms, abbreviations, and acronyms used in the document that the reader may be unfamiliar with

B. A detailed list of the possible penalties associated with breaking rules set forth in the policy

C. A list of all the members of the security policy creation team

D. None of the above

18. The _________ contains the penalties that would apply if a portion of the security policy were to be ignored by an employee.

A. policy heading

B. policy statement

C. policy enforcement clause

D. policy statement of authority

19. What component of a security policy does the following phrase belong to? “Wireless networks are allowed only if they are separate and distinct from the corporate network.”

A. Introduction

B. Administrative notation

C. The policy heading

D. The policy statement

20. There may be situations where it is not possible to comply with a policy directive. Where should the exemption or waiver process be explained?

A. Introduction

B. The policy statement

C. The policy enforcement clause

D. The policy exceptions

21. The name of the person/group (for example, executive committee) that authorized the policy should be included in ___________________.

A. the version control table or the policy statement

B. the heading or the policy statement

C. the policy statement or the policy exceptions

D. the version control table or the policy heading

22. When you’re drafting a list of exceptions for a security policy, the language should _________________.

A. be as specific as possible

B. be as vague as possible

C. reference another, dedicated document

D. None of the above

23. If supporting documentation would be of use to the reader, it should be __________________.

A. included in full in the policy document

B. ignored because supporting documentation does not belong in a policy document

C. listed in either the Policy Heading or Administrative Notation section

D. included in a policy appendix

24. When writing a policy, standard, guideline, or procedure, you should use language that is ___________.

A. technical

B. clear and concise

C. legalese

D. complex

25. Readers prefer “plain language” because it __________________.

A. helps them locate pertinent information

B. helps them understand the information

C. saves time

D. All of the above

26. Which of the following is not a characteristic of plain language?

A. Short sentences

B. Using active voice

C. Technical jargon

D. Seven or fewer lines per paragraph

27. Which of the following terms is best to use when indicating a mandatory requirement?

A. must

B. shall

C. should not

D. may not

28. A company that uses the term “employees” to refer to workers who are on the company payroll should refer to them throughout their policies as _________.

A. workforce members

B. employees

C. hired hands

D. workers

29. Which of the following statements is true regarding policy definitions?

A. They should be defined and maintained in a separate document.

B. The general rule is to include definitions for any topics except technical, legal, or regulatory language.

C. The general rule of policy definitions is to include definitions for any instance of industry-specific, technical, legal, or regulatory language.

D. They should be created before any policy or standards.

30. Even the best-written policy will fail if which of the following is true?

A. The policy is too long.

B. The policy is mandated by the government.

C. The policy doesn’t have the support of management.

D. All of the above.

1. You are tasked with developing a standard that documents the mandatory requirements (for example, how many classes can be missed without penalty). Include at least four requirements.

2. Create a guideline to help students adhere to the standard you created.

3. Create a procedure for requesting exemptions to the policy.

Clinton, W. “President Clinton’s Memorandum on Plain Language in Government Writing,” accessed 05/2018, www.plainlanguage.gov/whatisPL/govmandates/memo.cfm.

Obama, B. “Executive Order 13563—Improving Regulation and Regulatory Review,” accessed 05/2018, https://obamawhitehouse.archives.gov/the-press-office/2011/01/18/executive-order-13563-improving-regulation-and-regulatory-review.

“Plain Writing Act of 2010” PUBLIC LAW 111–274, Oct. 13, 2010, accessed 05/2018, https://www.gpo.gov/fdsys/pkg/PLAW-111publ274/pdf/PLAW-111publ274.pdf.