Principle of Information Security Module 3 Information Security Management part 7

How policy is developed and implemented can help or hinder its usefulness to the organization. If an organization takes punitive action on an effective policy, the individual affected may sue the organization, depending on its action in implementing the penalties or other actions defined in the policy. Employees terminated for violating poorly designed and implemented policies could sue their organization for wrongful termination. In general, policy is only enforceable and legally defensible if it is properly designed, developed, and implemented using a process that assures repeatable results.

For policies to be effective and legally defensible, the following must be done properly:

• Development—Policies must be written using industry-accepted practices and formally approved by management.
  
  
• Dissemination—Policies must be distributed using all appropriate methods.
  
  
• Review—Policies must be readable and read by all employees.
  
  
• Comprehension—Policies must be understood by all employees.
  
  
• Compliance—Policies must be formally agreed to by act or affirmation.
  
  
• Enforcement—Policies must be uniformly applied to all employees.

We will examine each of these stages in the sections that follow. Before we do, however, you should realize that almost every organization has a set of existing policies, standards, procedures, and/or practices. This installed base of guidance may not always have been prepared using an approach that delivers consistent or even usable results. Most of the situations you find yourself in will involve more policy maintenance than policy development. Prior to implementation, policy should be reviewed by the organization’s legal counsel to ensure it is acceptable within the limits of the law and that implementation of the policy and its corresponding penalties would, in fact, be defensible in the event of a legal dispute.

Developing Information Security Policy

It is often useful to view policy development as a three-part project. In the first part of the project, policy is designed and written (or, in the case of an outdated policy, redesigned and rewritten). In the second part, a senior manager or executive at the appropriate level and the organization’s legal counsel review and formally approve the document. In the third part of the development project, management processes are established to distribute and enforce the policy within the organization. The first part is an exercise in project management, whereas the latter two parts require adherence to good business practices and legal regulation.

Writing a policy is not always as easy as it seems. However, the prudent security manager always scours available resources (including the Web) for examples that may be adapted to the organization. Seldom will the manager find the perfect policy, ready to be implemented. Some online vendors sell blank policies that you can customize to your organization. In any event, it is important that the organization respect the intellectual property of others when developing policy. If parts of another organization’s policy are adapted, appropriate attribution must be made. Most policies contain a reference section where the author may list any policies used in the development of the current document. Even policies that are purchased from policy vendors or developed from a book on writing policies may require some level of attribution. It is recommended that any policies adapted from outside sources are thoroughly summarized to prevent the need for direct quotations, which can detract from the message the policy is attempting to convey—that “our organization” wants employees to be effective and efficient without undue distractions.

Policy Distribution

While it might seem straightforward, getting the policy document into the hands of employees can require a substantial investment by the organization to be effective. The most common alternatives are hard copy and electronic distribution. Hard copy distribution involves either directly handing or mailing a copy to each employee or posting the policy in a publicly accessible location. Posting a policy on a bulletin board or other public area may be insufficient unless another policy requires the employees to read the bulletin board on a specified schedule.

Distribution by internal or external mail may still not guarantee that the individual receives the document. Unless the organization can prove that the policy reached its target audience, it cannot be enforced. Unlike in law, ignorance of policy, where policy is inadequately distributed, is considered an acceptable excuse. Distribution of classified policies—those containing confidential information—requires additional levels of controls, in the labeling of the document, in the dissemination and storage of new policy, and in the collection and destruction of older versions to ensure the confidentiality of the information contained within the policy documents themselves.

Another common method of dissemination is by electronic means: e-mail, newsletter, intranet, or document management systems. Perhaps the easiest way is to post policies on a secure intranet in HTML or PDF (Adobe Acrobat) form. The organization must still enable a mechanism to prove distribution, such as an auditing log for tracking when users access the documents. As an alternative delivery mechanism, e-mail has advantages and disadvantages. While it is easy to send a document to an employee and even track when the employee opens the e-mail, e-mail tracking may not be sufficient as proof that the employee downloaded and actually read any attached policies, and the document can get lost in an avalanche of spam, phishing attacks, or other unwanted e-mail. The best method is through electronic policy management software, as described in the section on automated tools. Electronic policy management software not only assists in the distribution of policy documents, it supports the assessment of comprehension and evaluation of compliance.

Policy Review

Barriers to employees reading policies can arise from literacy or language issues. A surprisingly large percentage of the workforce is considered functionally illiterate. According to Macrotrends, a full 1 percent of people 15 and older living in the United States cannot read and write with understanding. Based on statistics from 2020, that means more than 3.28 million adults in the United States are considered illiterate.* Many jobs do not require literacy skills—for example, custodial staff, groundskeepers, or production line workers. Because such workers can still pose risks to InfoSec, they must be made familiar with policy even if it must be read to them. Visually impaired employees also require additional assistance, either through audio or large-type versions of the document.

A contributing factor to the literacy issue is that the number of non-English-speaking residents in the United States continues to climb. According to 2018 U.S. Census data, more than 67 million residents speak a language other than English at home.* However, language challenges are not restricted to organizations with locations in the United States. Multinational organizations also must deal with the challenges of gauging reading levels of foreign citizens. Simple translations of policy documents, while a minimum requirement, necessitate careful monitoring. Translation issues have long created challenges for organizations.

Policy Comprehension

Simply making certain that a copy of the policy gets to employees in a form they can review may not ensure that they truly understand what the policy requires of them. Comprehension involves two aspects of policy administration:

1. the target audience can understand the policy, and
   
   
2. the organization has assessed how well they understand it.

To be certain that employees can understand the policy, the document must be written at an appropriate reading level, with minimal technical jargon or management terminology. The readability statistics supplied by most productivity suite applications—such as Microsoft Word—can help determine the current reading level of a policy. The Flesch Reading Ease test evaluates writing on a scale of 1–100. The higher the score, the easier it is to understand the writing. For most corporate documents, a score of 60 to 70 is preferred. The Flesch–Kincaid Grade Level test evaluates writing on a U.S. grade-school level. While a 13th-grade level (freshman in college) may be appropriate for a textbook, it is too high for organizational policy intended for a broad audience. For most corporate documents, a score of 7.0 to 8.0 is preferred.

The next step is to use some form of assessment to gauge how well employees understand the policy’s underlying issues. Quizzes and other forms of examination can be employed to assess quantitatively which employees understand the policy by earning a minimum score (e.g., 70 percent) and which employees require additional training and awareness efforts before the policy can be enforced. Quizzes can be conducted in either hard copy or electronic formats. The electronic policy management systems mentioned earlier can assist in the assessment of employee performance on policy comprehension.

Policy Compliance

Policy compliance means the employee must agree to the policy. According to Whitman in “Security Policy: From Design to Maintenance”: Policies must be agreed to by act or affirmation. Agreement by act occurs when the employee performs an action, which requires them to acknowledge understanding of the policy prior to use of a technology or organizational resource. Network banners, end-user license agreements (EULAs), and posted warnings can serve to meet this burden of proof. However, these approaches in and of themselves may not be sufficient. Only through direct collection of a signature or the equivalent digital alternative can the organization prove that it has obtained an agreement to comply with policy, which also demonstrates that the previous conditions have been met.*

What if an employee refuses explicitly to agree to comply with policy? Can the organization deny access to information that the individual needs to do his or her job? While this situation has not yet been adjudicated in the legal system, it seems clear that failure to agree to a policy is tantamount to refusing to work and thus may be grounds for termination. Organizations can avoid this dilemma by incorporating policy confirmation statements into employment contracts, annual evaluations, or other documents necessary for the individual’s continued employment.

Policy Enforcement

The final component of the design and implementation of effective policies is uniform and impartial enforcement. As in law enforcement, policy enforcement must be able to withstand external scrutiny. Because this scrutiny may occur during legal proceedings—for example, in a civil suit contending wrongful termination— organizations must establish high standards of due care with regard to policy management. For instance, if policy mandates that all employees wear identification badges in a clearly visible location and select members of management decide they are not required to follow this policy, any actions taken against other employees will not withstand legal challenges. If an employee is punished, censured, or dismissed as a result of a refusal to follow policy and is subsequently able to demonstrate that the policies are not uniformly applied or enforced, the organization may find itself facing punitive as well as compensatory damages.

One forward-thinking organization found a way to enlist employees in the enforcement of policy. After the organization had just published a new ID badge policy, the manager responsible for the policy was seen without his ID. One of his employees chided him in jest, saying, “You must be a visitor here, since you don’t have an ID. Can I help you?” The manager smiled and promptly produced his ID, along with a $20 bill, which he presented to the employee as a reward for vigilant policy enforcement. Soon, the entire staff was routinely challenging anyone without a badge.*

Policy Development and Implementation Using the SDLC

Like any major project, a policy development or redevelopment project should be well planned, properly funded, and aggressively managed to ensure that it is completed on time and within budget. One way to accomplish this goal is to use a systems development life cycle (SDLC). The following discussion expands the use of a typical SDLC model by discussing the tasks that could be included in each phase of the SDLC during a policy development project.

Investigation Phase

During the investigation phase, the policy development team or committee should attain the following:

• Support from senior management because any project without it has a reduced chance of success. Only with the support of top management will a specific policy receive the attention it deserves from the intermediate-level managers who must implement it and from the users who must comply with it.
  
  
• Support and active involvement of IT management, specifically the CIO. Only with the CIO’s active support will technology-area managers be motivated to participate in policy development and support the implementation efforts to deploy it once created.
  
  
• Clear articulation of goals. Without a detailed and succinct expression of the goals and objectives of the policy, broken into distinct expectations, the policy will lack the structure it needs to obtain full implementation.
  
  
• Participation of the correct individuals from the communities of interest affected by the recommended policies. Assembling the right team, by ensuring the participation of the proper representatives from the groups that will be affected by the new policies, is very important. The team must include representatives from the legal department, the human resources department, and end users of the various IT systems covered by the policies, as well as a project champion with sufficient stature and prestige to accomplish the goals of the project and a capable project manager to see the project through to completion.
  
  
• A detailed outline of the scope of the policy development project and sound estimates for the cost and scheduling of the project.

Analysis Phase

The analysis phase should produce the following:

• A new or recent risk assessment or IT audit documenting the current InfoSec needs of the organization. This risk assessment should include any loss history, as well as past lawsuits, grievances, or other records of negative outcomes from InfoSec areas.
  
  
• The gathering of key reference materials, including any existing policies. Sometimes policy documents that affect InfoSec will be housed in the human resources department as well as the accounting, finance, legal, or corporate security departments.
  
  
• The policy development committee must determine the fundamental philosophy of the organization when it comes to policy. This will dictate the general development of all policies, but in particular, the format to be used in the crafting of all ISSPs. This philosophy typically falls into one of two groups:

• “That which is not permitted is prohibited.” Also known as the “whitelist” approach, this is the more restrictive of the two, and focuses on creating an approach where specific authorization is provided for various actions and behaviors; all other actions and behaviors (and uses) are prohibited or at least require specific permissions. This approach can impede normal business operations if appropriate options emerge but cannot be incorporated into policy until subsequent revisions are made.

• “That which is not prohibited is permitted.” Also known as the “blacklist” approach, this alternate approach specifies what actions, behaviors, and uses are prohibited and then allows all others by default. While easier to implement, this approach can result in issues as more and more areas that should be prohibited are discovered by users.

Design Phase

The first task in the design phase is the drafting of the actual policy document. While this task can be done by a committee, it is most commonly done by a single author. This document should incorporate all the specifications and restrictions from the investigation and analysis phases. This can be a challenging process, but you do not have to come up with a good policy document from scratch. A number of resources are at your disposal, including the following:

• The Web—You can search for other similar policies. The point here is not to advocate wholesale copying of these policies but to encourage you to look for ideas for your own policy. For example, dozens of policies available on the Web describe fair and responsible use of various technologies. What you may not find, however, are policies that relate to sensitive internal documents or processes.
  
  
• Government sites—Sites such as http://csrc.nist.gov contain numerous sample policies and policy support documents, including SP 800-100, “Information Security Handbook: A Guide for Managers.” While these policies are typically applicable to federal government Web sites, you may be able to adapt some sections to meet your organization’s needs.
  
  
• Professional literature—Several authors have published books on the subject. Of particular note is Charles Cresson Wood’s Information Security Policies Made Easy series, which not only provides more than 1,000 pages of policies, it makes those policies available in electronic format, complete with permission to use them in internal documents. Exercise caution when using such resources, however; it is extremely easy to take large sections of policy and end up with a massive, unwieldy document that is neither publishable nor enforceable.
  
  
• Peer networks—Other InfoSec professionals must write similar policies and implement similar plans. Attend meetings like those offered by the Information Systems Security Association (www.issa.org) or the Information Systems Audit and Control Association (www.isaca.org), and ask your peers.
  
  
• Professional consultants—Policy is one area of InfoSec that can certainly be developed in-house. However, if your organization does not have the requisite expertise, or if your team simply cannot find the time to develop your own policy, then hiring an outside consultant may be your best option. Keep in mind that no consultant can know your organization as well as you do; you may decide to have the consultant design generic policies that you can then adapt to your specific needs.
  
  
• Next, the development team or committee reviews the work of the primary author and makes recommendations about its revision. Once the committee approves the document, it goes to the approving manager or executive for sign-off.

Implementation Phase

In the implementation phase, the team must create a plan to distribute and verify the distribution of the policies. Members of the organization must explicitly acknowledge that they have received and read the policy (compliance). Otherwise, an employee can claim never to have seen a policy, and unless the manager can produce strong evidence to the contrary, any enforcement action, such as dismissal for inappropriate use of the Web, can be overturned and punitive damages might be awarded to the former employee. The simplest way to document acknowledgment of a written policy is to attach a cover sheet that states “I have received, read, understood, and agreed to this policy.” The employee’s signature and date provide a paper trail of his or her receipt of the policy.

Some situations preclude a formal documentation process. Take, for instance, student use of campus computer labs. Most universities have stringent policies on what students can and cannot do in a computer lab. These policies are usually posted on the Web, in the student handbook, in course catalogs, and in several other locations, including bulletin boards in the labs. For the policies to be enforceable, however, some mechanism must be established that records the student’s acknowledgment of the policy. This is frequently accomplished with a banner screen that displays a brief statement warning the user that the policy is in place and that use of the system constitutes acceptance of the policy. The user must then click an OK button or press a key to get past the screen. However, this method can be ineffective if the acknowledgment screen does not require any unusual action to move past it. Most acknowledgment screens require that the user click a specific button, press a function key, or type text to agree to the terms of the EULA. Some even require the user to scroll down to the bottom of the EULA screen before the “I accept” button is activated. Similar methods are used on network and computer logins to reinforce acknowledgment of the system use policy.

A stronger mechanism to document and ensure comprehension is a compliance assessment, such as a short quiz, to make sure that users both read the policy and understand it. A minimum score is commonly established before the employee is certified to be “in compliance.” Coupled with a short training video, the compliance quiz is the current industry best practice for policy implementation and compliance.

The design phase should also include specifications for any automated tool used for the creation and management of policy documents, as well as revisions to feasibility analysis reports based on improved costs and benefits as the design is clarified. During the implementation phase, the policy development team ensures that the policy is properly distributed, read, understood, and agreed to by those to whom it applies, and that their understanding and acceptance of the policy are documented.

Maintenance Phase

During the maintenance phase, the policy development team monitors, maintains, and modifies the policy as needed to ensure that it remains effective as a tool to meet changing threats. The policy should have a built-in mechanism through which users can report problems—preferably on an anonymous basis through a Web form monitored either by the organization’s legal team or a committee assigned to collect and review such content. It is in this phase that the last component of effective policy development—uniform enforcement—comes into play. The organization should make sure that everyone is required to follow the policy equally and that policies are not implemented differently in different areas or hierarchies of the organization.

When the policy comes up for schedule review, the development committee reassembles, reviews any submitted recommendations, and begins the process anew, as described in the next section.