case study
WHAT BINDS WELL-FORMED IT SECURITY POLICIES together is a sense of shared beliefs, purpose, and urgency. Within your organization, you will achieve that, in part, by establishing principles that create a shared vision, by empowering others to act, and by institutionalizing support processes. It’s important that the
implementation of IT security policies become second nature to the organization. That is, business processes should be designed with the controls needed to
implement and maintain security policies built in.
For example, consider the issue of emergency access to a server in the middle of the night. Gaining access may require going through a firecall system that will issue
an ID and password only when approval by the manager is obtained. In that way security policies are enforced and cannot be bypassed. But that process assumes
there is a shared belief that such controls are important. That extra step of obtaining approval before accessing the server in the middle of the night is of value. The
business may see the deal as an unneeded delay, given skilled staff that can be trusted to do the right thing. Defining a shared set of core security principles and vision
is vital to how IT security policies are designed and implemented.
This chapter gives you a micro look into each document within the collection of policy framework documents.
Chapter 7 Topics
This chapter covers the following topics and concepts:
• Which principles and concepts are important in the design of policy
• How to organize the contents of an IT policy framework
• What to consider when implementing the policy and standards library
• What the importance of the policy change control board is
• How to maintain the policy and standards library over time
• What best practices are for policies and standards maintenance
• What some case studies and examples of IT security policy management and maintenance are
Chapter 7 Goals
When you complete this chapter, you will be able to:
• Describe the characteristics of a “good” policy or standard that meets the organization’s needs
• Describe the core security principles that policy writers should keep in mind while developing policies
• Explain what an architecture operating model is and why it is important
• Explain the review and approval process for policies, standards, procedures, and guidance documents
• Explain the document publication and training and awareness processes needed for policies and standards
• Explain the role and activities of the policy change control board
• Describe the processes needed for maintaining and updating policies and standards
Policies and Standards Design Considerations
All documents in a policy and standards library are meant for people to read and consume. Policies and standards are not guidelines that offer suggestions. They are a
collection of concrete definitions that describe acceptable and unacceptable human behavior. There are consequences for failing to follow approved standards.
Developing them is not a trivial undertaking.
There’s little point in writing documents that people cannot understand or that make compliance highly difficult or impossible. The best kinds of documents are
clearly worded and address the six key questions who, what, where, when, why, and how.
NOTE
Most often, the questions related to where, when, and how are more appropriate for procedures or guidelines rather than policies or standards. Try to keep your policies and standards at the what, who, and why levels of detail.
These questions provide a consistent direction in writing policies and standards. Journalists traditionally ask these six questions as they research and write news
stories. Most readers, of news articles and policy documents alike, are busy. They need concise and precise information. Lack of clarity forces readers to make
assumptions. Often those assumptions are wrong. When you answer these questions within the first few sections of your documents, you increase the reader’s
comfort level and increase the likelihood of compliance.
TIP
When writing policies and standards, avoid using terms like should when you mean must or need to.
Effective policies are those that employees understand and embrace. It’s simply human nature for people to work harder for something they believe in. This depends
on a shared belief system. These shared beliefs are collectively described as the organizational culture. Some organizations have a strong command and control culture. This dictates that policies and standards are written as strong, imperative statements; for example, “You must log off at the end of each workday.” Other
organizations use subtler phrases and tone, intended to persuade those who must follow the policy. But it’s important to avoid using “squishy” language or loose
terms when developing your documents. If you allow people to interpret your requirements on their own, they might look for ways to opt out of them.
The challenge is how to establish, or recognize, a core set of beliefs that can influence how you write policies. One method is to break the problem down into how the
security controls are to be implemented and what controls are needed.
Architecture Operating Model
An architecture operating model can help you understand how the security controls are to be implemented. One issue over which disagreement often arises is how much security should be centralized or decentralized within the business. A discussion of the architecture operating model within the company can identify areas
of disagreement and create a common set of beliefs on the proper placement and implementation of controls.
There are different ways to have this broad architectural conversation. One way is outlined in a book entitled Enterprise Architecture as Strategy: Creating a
Foundation for Business Execution, by Jeanne W. Ross, Peter Weill, and David C. Robertson. Their approach was to analyze and categorize the primary operating
model of the business on the basis of four concepts: diversified, coordinated, replicated, and unified. As you can see by Figure 7-1, these operating model concepts
are aligned with how the business chooses to integrate and standardize with an enterprise solution. In general, the higher level of integration and standardization in
an enterprise solution, the easier it is to implement security policies. The more the leaders of the business are deploying their own solution, the harder it is to
implement security policies. The following defines in context to IT solutions each quadrant of Figure 7-1 in the context of IT solutions:
FIGURE 7-1
The four basic business operating models.
• Diversified—In the diversified operating model, the technology solution has a low level of integration and standardization with the enterprise. Typically, the exchange of data and use of services outside the business unit itself is minimal.
• Coordinated—In a coordinated operating model, the technology solution shares data across the enterprise. However, the level of shared services and standardization are minimal.
• Replicated—In a replicated operating model, the technology solution shares services across the enterprise. However, the level of data sharing is minimal.
• Unified—In a unified operating model, the technology solution both shares data and has standardized services across the enterprise.
Typically, you will have both highly integrated and less integrated systems across the enterprise. These choices are made by the business and thus reflect the beliefs
the business holds. For example, if a business makes many changes to an application over a year, it may want more direct control over the technology. The staff may
see control as critical to their success. This is especially true if they feel they have to make technological changes throughout the year to keep up with the market. This
approach can lead to standalone solutions that are business-specific and less integrated with enterprise solutions.
The four concepts (diversified, coordinated, replicated, and unified) align with service integration and service standardization. Service integrationgenerally refers to
how much shared data is used across a business. Service standardization, on the other hand, refers to how much control the business has in setting up its solutions
and processes. For example, a real estate business may have a high degree of service integration. The company may share data on new home purchases between the
business unit that sold the home and the unit that sells insurance for the home.
The architecture operating model can have a profound effect on how your controls are implemented and how policies are written. The challenge is balancing the
needs of the business and the enterprise need to control security. These deliberate choices the business makes typically reflects the beliefs of the business’s leaders.
NOTE
It is important not to underestimate the strong feelings the business has in the level of controls it wants over technology. The challenge is selecting an operating model that the business can commit to and that will ensure that IT security policies are enforced.
Principles for Policy and Standards Development
No two organizations or risk assessment outcomes are the same; there are no universal recipes for building an IT security program. Instead, principles help you make
decisions in new situations using proven experience and industry best practices. By considering several principles, you can derive control requirements and help
make implementation decisions.
Use the following principles to help you develop policies, standards, baselines, procedures, and guidelines. These are the common core security principles
recommended for industry best practices, regardless of the organization’s business nature:
• Accountability principle—The personal responsibility of information systems security should be explicit. Some roles in the organization are accountable only for the work they perform daily. Other roles are accountable for their own work, plus all the work performed by their team of employees. Accountability helps to
ensure that people understand they are solely responsible for actions they take while using organization resources. You can think of accountability as a deterrent
control.
• Awareness principle—Owners, providers, and users of information systems, as well as other parties, should be informed of the existence and general context of policies, responsibilities, practices, procedures, and organization for security of information systems.
• Ethics principle—The way information systems are designed, and the level of access to data reflected in the security controls, should operate in accordance with the organization’s ethical standards. This includes the level of disclosure and access to customer data.
• Multidisciplinary principle—Policy and standards library documents should be written to consider everyone affected, including technical, administrative, organizational, operational, commercial, educational, and legal personnel.
• Proportionality principle—Security levels, costs, practices, and procedures should be appropriate and proportionate to the value of the data and the degree of reliance on the system. They should also be proportional to the potential severity, probability, and extent of harm to the system or loss of the data. In other words,
don’t spend $1,000 to protect $500 worth of assets.
• Integration principle—Your documents should be coordinated and integrated with each other. They should also integrate with other relevant measures, practices, and procedures for a coherent system of security.
• Defense-in-depth principle—Security increases when it is implemented as a series of overlapping layers of controls and countermeasures that provide three elements to secure assets: prevention, detection, and response. This is referred to as defense in depth. It is both a military concept and an information security concept. Defense in depth dictates that security mechanisms be layered so that the weaknesses of one mechanism are countered by the strengths of two or more other
mechanisms.
• Timeliness principle—All personnel, assigned agents, and third-party providers should act in a timely and coordinated manner to prevent and to respond to breaches of the security.
• Reassessment principle—The security of information systems should be periodically reassessed. Risks to technology change daily and periodic reassessments are needed to assure that security requirements and practices are kept current with these changes. Standards also need reassessments, at least annually, to assure
they represent the current state of affairs.
• Democracy principle—The security of an information system should be balanced against the rights of customers, users, and other people affected by the system versus your rights as the owners and operators of these systems. In other words, consider your users or partners when requiring information that could place their
privacy rights at risk.
• Internal control principle—Information security forms the core of an organization’s information internal control systems. Regulations mandate that internal control systems be in place and operating correctly. Organizations rely on technology to maintain business records. It’s essential that such technology include internal
control mechanisms. These maintain the integrity of the information and represent a true picture of the organization’s activities.
• Adversary principle—Controls, security strategies, architectures, and policy library documents should be developed and implemented in anticipation of attack from intelligent, rational, and irrational adversaries who may intend harm.
• Least privilege principle—People should be granted only enough privilege to accomplish assigned tasks and no more.
• Separation of duty principle—Responsibilities and privileges should be divided to prevent a person or a small group of collaborating people from inappropriately controlling multiple key aspects of a process and causing harm or loss. For example, in an accounting department, the person preparing invoices for
payment should not be the same person writing the checks for payment.
• Continuity principle—Identify your organization’s needs for disaster recovery and continuity of operations. Prepare the organization and its information systems accordingly.
• Simplicity principle—Try to favor small and simple safeguards over large and complex ones. Security is improved when it’s made simpler.
• Policy-centered security principle—Policies, standards, and procedures should be established as the formal basis for managing the planning, control, and evaluation of all information security activities.
The Importance of Transparency with Regard to Customer Data
Policies related to the handling and use of customer data should include the concept of transparency. Organizations should be transparent and should notify
individuals of the collection, use, dissemination, and maintenance of personally identifiable information (PII). PII is information that can be used to identify a
specific person. This can be something used alone, such as a person’s name.
TIP
Whenever customer data is involved, be sure to check with your compliance team on the legal requirements related to handling and use of such data.
A closely related concept is as nonpublic personal information (NPI). This is the term the Gramm-Leach-Bliley Act uses to refer to any personally identifiable
financial information that a consumer provides to a financial institution.
Transparency with regard to handling of customer data should include the following elements:
• Individual participation—Organizations should involve the individual in the process of using PII and seek individual consent. This consent should include the collection, use, dissemination, and maintenance of PII. Organizations should also provide mechanisms for appropriate access, correction, and redress regarding use
of PII.
• Purpose specification—Organizations should specifically describe the authority that permits the collection of PII and articulate the purpose or purposes for which they intend to use data.
• Data minimization—Organizations should collect only PII that is directly relevant and necessary to accomplish the specified purpose(s). Additionally, they should retain PII only for as long as is necessary to fulfill the specified purpose(s).
• Use limitation—Organizations should use PII solely for the purpose(s) specified. If PII is shared, it should be for a purpose for which it was collected.
Types of Controls for Policies and Standards
With a shared sense of purpose and beliefs within the business and principles in hand, you can begin to map what you want to accomplish with the security controls.
Security controls are measures taken to protect systems from attacks on the confidentiality, integrity, and availability of the system. Sometimes, safeguards and
countermeasures are used synonymously with the word control. Controls are chosen after the risk assessment of the assets is complete. Once you have identified and
assessed the risks to your assets, you can select the appropriate control to counter the threat, mitigate, or reduce the risks.
Security Control Types
Security controls can be described according to two different categorization schemes: one based upon what the control is and the other based upon what the control
does.
The first category includes administrative, technical, and physical control categories. They describe what the control actually is, such as a named process, a standard,
a firewall, or a locked door:
• Administrative controls are the policies, standards, and procedures that guide employees when conducting the organization’s business. Pre-employment screening of personnel and a change management process are also examples of administrative controls.
• Technical security controls are the devices, protocols, and other technology used to protect assets. These include antivirus systems, cryptographic systems, firewalls, and more.
• Physical security controls are the devices used to control physical access. Examples here are fences, security guards, locked doors, motion detectors, and alarms.
The second set of controls describes what controls do. These controls include the following:
• Preventive security controls prevent intentional or unintentional security threats. Examples include network access policies, firewall rules, and locks on wiring closets and server room doors.
• Detective or response controls act like alarms and warnings. These controls kick in after an incident begins. Examples include motion detectors, log files, and files that contain system audit information.
• Corrective controls help you respond to and fix a security incident. Corrective controls are also used to limit or stop further damage. Some examples include cleaning a virus off a system, closing a firewall port, and blocking an Internet Protocol (IP) address.
• Recovery controls help you put a system back into operation once an incident ends. Disaster recovery and tape backups fit into this category.
There is significant overlap between security control categories. Some controls can be administrative and preventive or technical and corrective, or any combination.
This overlap occurs by design for the purpose implementing the principle of defense in depth.
You can find catalogs of security controls for virtually every security topic. One such catalog is called Control Objectives for Information and related Technology, or
COBIT for short. COBIT is an IT governance framework developed by ISACA that includes supporting tools to help bridge the gaps between control requirements,
technical issues, and business risks. You can visit the ISACA Web site at http://www.isaca.orgfor more information.
Document Organization Considerations
While there are many ways to organize a library of policies, one thing they all have in common is the need for a numbering scheme. A numbering scheme helps you
organize the material by topic and become a quick reference point for people to use to refer to specific content. You can create your own numbering scheme or use an
existing one. Should you decide to use an existing framework like ISO/IEC 27002, you can begin with the taxonomy it provides.
NOTE
Taxonomy is the practice and science of classification. A hierarchical taxonomy is a tree structure of classifications for a given set of objects or documents.
Figure 7-2 offers an example that you might consider using for your taxonomy.
FIGURE 7-2
A possible policy and standards library taxonomy.
Think of Figure 7-2 as a sideways tree. The program-level policy or information security charter on the left side is the “root.” It establishes the tree and delegates the
authority for managing the tree to the information security department of the organization. Let’s call it IS (for information security), POL (for policy), and add “001”
because it’s the first document: IS-POL-001.
To the right, you find a collection of program framework policies. This framework uses ISO/IEC 27002 topics for policy types. They are numbered in groups of 100 to
allow for growth. Each of these policies stands on its own and serves as the first major branches of the tree. From these branches, standards and their supporting
documents appear.
Looking at the Access Control (IS-POL-800) framework policy as an example, you can see control standards labeled IS-CSTD-810 through 840. The CSTD label is
short for “Control Standard.” Figure 7-3 shows just this part of the policy and standards library.
Baseline standards are then numbered to maintain the consistency of the taxonomy and support the control standards upon which they’re based. The baseline
standards are specific to technology and numbered as IS-BSTD-821 and 822, where BSTD stands for Baseline Standard. These two standards define the requirements
for password management as they pertain to the Windows operating system and the UNIX operating system. In this example, the numbering follows the parent
standard’s numbering, IS-CSTD-820.
Procedures link to the baseline standards that they support. For example, IS-PROC-821 and 822 are directly mapped to the 821 and 822 baselines. In most cases,
there is a one-to-one mapping of baselines and procedures in support of the control standard. Figure 7-4 shows a close-up of baseline standards and procedures in
the policy and standards library tree.
TIP
Whatever numbering scheme you adopt, leave plenty of room for adding new documents. Think through a numbering scheme carefully before you decide to use it. Ask yourself how you would add new policies. How you would add new technology areas such as introducing mobility into the organization for the first time?
Guideline documents are most often tied to a specific control standard, as shown in Figure 7-5. Guideline documents (GUIDs) are useful where there may not be any
technology for enforcing controls, but the guidelines provide useful information for process management or controls.
When people look for a specific document, the name of the document should tell them all they need to know. After they gain some experience with the taxonomy,
they’ll know where to look.
FIGURE 7-3
Control standards branch out from the Access Control (IS-POL-800) framework policy.
FIGURE 7-4
Baseline standards and procedures provide additional branches of the library tree.
FIGURE 7-5
Guidelines provide additional branches of the library tree.
Sample Templates
In this section, you will look at some suggested document formats for policies and standards. You can use these as is or create a template that best reflects your
organization’s needs.
Sample Policy Template
The following outline of a policy document helps you organize the content for your program-level policy and framework policies:
POLICY NAME AND IDENTIFYING INFORMATION
1. PURPOSE
This document establishes a policy for …
2. BACKGROUND
This document was developed because …
3. SCOPE
This policy applies to the use of …
TIP
Never use individual (personal) names in a policy or standard. For Role and Responsibilities, use the name of the department, unit, or specific role that is accountable. Individuals join and leave the company.
4. OPERATIONAL POLICY
4.1. Section 1
4.2. Section 2
4.3. Section 3
4.4. Section 4
5. ROLES AND RESPONSIBILITIES
The following entities have responsibilities related to the implementation of this policy:
6. APPLICABLE LAWS/GUIDANCE
7. EFFECTIVE DATES
This policy becomes effective on the date that [xxx] Chief Information Officer (CIO) signs it and remains in effect until officially superseded or canceled by the CIO.
8. INFORMATION AND ASSISTANCE
Contact the … for further information regarding this policy.
9. APPROVED
[Director of Information Security Policies] Date of Issuance
10. ASSOCIATED RESOURCES
This policy is augmented by …
The following is a sample policy statement for access control that would appear in the “Operational Policy” section of a framework policy:
Personnel must be positively authenticated and authorized prior to being granted access to <Organization> information resources. Access based on an individual’s
role must be limited to the minimum necessary to perform his or her job function.
Access to critical information resources must be controlled through a managed process that addresses authorizing, modifying, and revoking access, and periodic
review of information system privileges.”
Sample Standard Template
The following outline of a standards document helps you organize the content for your control and baseline standards:
STANDARD NAME AND IDENTIFYING INFORMATION
1. PURPOSE
This document establishes a standard for …
2. BACKGROUND
This document was developed to support …
3. SCOPE
This standard applies to the use of …
4. STANDARD STATEMENT(S)
4.1. Section 1
4.2. Section 2
4.3. Section 3
4.4. Section 4
5. ROLES AND RESPONSIBILITIES
The following entities have responsibilities related to the implementation of this standard:
6. GUIDANCE
Links to guidance documentation for this standard …
7. EFFECTIVE DATES
This standard becomes effective on the date that [xxx], Chief Information Officer (CIO), signs it and remains in effect until officially superseded or canceled by the
CIO.
8. INFORMATION AND ASSISTANCE
Contact the … for further information regarding this standard.
9. APPROVED
[Director of Information Security Policies] Date of Issuance
10. ASSOCIATED RESOURCES
This standard is augmented by …
The following are sample statements for access control that would appear in the “Standard Statement(s)” section of a control standard:
Access to all <Organization> information resources must be controlled by using user IDs and appropriate authentication methods as required by the Information
Classification Standard and the Information Handling Standard.
Access to all <Organization> information resources connected to the <Organization> network must be controlled by using user IDs and appropriate authentication.
In order to ensure individual accountability, the use of any user ID must be associated with a specific individual. Passwords must never be shared between users.
The following is a sample statement for UNIX account management that would appear in the “Standard Statement(s)” section of a baseline standard:
Default system accounts must be locked (except root). The password field for the account must be set to an invalid string and the shell field in the password file must
contain an invalid shell. /dev/null is a good choice because it is not a valid logon shell.
Sample Procedure Template
The following outline of a procedures document helps you organize the content for any procedures needed to implement baseline standard controls:
PROCEDURE NAME AND IDENTIFYING INFORMATION EFFECTIVE DATE
Date the procedure becomes effective. This can be the same as or later than the approval date in order to allow time for training and implementation if necessary.
1. PROCEDURE
Insert procedural steps in the table …
1.1. Section 1.1
1.2. Section 1.2
1.3. Section 1.3
1.4. Section 1.4
2. STANDARD
Indicate the name and number of the baseline standard to which this procedure relates …
3. FORMS
List any form numbers and names and their location if there are any needed to conduct this procedure.
4. PROCEDURE HISTORY
List all previous known versions (including obsolete procedure numbers or titles if known) and their effective dates.
5. INFORMATION AND ASSISTANCE
Contact the … for further information regarding this standard.
6. APPROVED
[Director of Information Security Policies] Date of Issuance
7. KEYWORDS
Indicate any cross references, aliases, phrases, or terms that describe the procedure. Define all acronyms, abbreviations.
8. ASSOCIATED RESOURCES
This standard is augmented by …
The following is a sample procedure snippet for data destruction on media that could appear in the “Procedure” section of a procedure document:
Disk sanitization involves securely erasing all the data from a disk so that the disk is, except for the previous wear, “new” and empty of any previous data. For
example, a disk connected to a Linux system may be sanitized by repeating the following command three to seven times (or more):
dd if=/dev/random of=/dev/hdb && dd if=/dev/zero of=/dev/hdb
This command first writes a random pattern to disk /dev/hdb, then writes all zeros to it. Any disk that needs to be sanitized, including any flash memory device or
former PC or Macintosh disk may be attached to a Linux (or other Unix) system and erased using the above command, replacing /dev/hdb with the appropriate disk
device name.
Sample Guideline Template
Although there are generally no standard templates for guidelines, you can use or adapt the following:
GUIDELINE NAME AND IDENTIFYING INFORMATION
1. PURPOSE
This document provides guidance and advice in helping to meet the control requirements from Standard(s) …
2. BACKGROUND
This document was developed to support ….
3. SCOPE
This guidance applies to the use of ….
4. GUIDANCE SECTION(S)
4.1. Section 1
4.2. Section 2
4.3. Section 3
4.4. Section 4
5. ROLES AND RESPONSIBILITIES
The following entities have responsibilities related to the implementation of this standard: …
6. EFFECTIVE DATES (may or may not be needed)
7. INFORMATION AND ASSISTANCE
Contact the … for further information regarding this document.
8. APPROVED
[Director of Information Security Policies] Date of Issuance
9. ASSOCIATED RESOURCES
This guideline is augmented by …
The following is a sample guideline snippet for the use of encryption within a university setting. This text could appear in the “Guidance Section” section of a
guideline document:
“University personnel and student organizations:
• Should use industry-standard encryption algorithms to protect their data.
• Should not attempt to develop their own proprietary encryption algorithms and should carefully scrutinize any claims made by vendors about the security of
proprietary encryption algorithms.
Considerations for Implementing Policies and Standards
Implementing your policies and libraries entails four major steps:
• Building consensus on intent
• Reviews and approvals for your documents
• Publication of the documents
• Awareness and training
Building Consensus on Intent
Separating the writing of the actual policy language from the discussion on the intent of the policy change is a good way to build a consensus. During this step, you
should discuss the drivers for the change in terms of the architecture operating model and principles. This reinforces the shared beliefs and helps promotes the
desired culture.
This separation also has the added advantage of reducing the time it takes to develop the actual policy language. Too often time is wasted disagreeing with policy
language when, in fact, the real disagreement is on the need for the policy. If you have agreement on the need for the security control and the intended outcome, then
writing the policy language is easier. The actual writing simply documents this agreement. This approach also makes the review and approval easier, as there’s
already an awareness of the need for the policy change, and an understanding of its intent.
Throughout your research and interview processes with operational users and their managers, you should have prepared them for changes that the information
security (IS) department will be mandating. This give-and-take process helps to improve the quality of the document content. It also helps with buy-in from those
who are subject to the rules and controls you’ll be implementing based on the risk analysis and assessment work completed.
Reviews and Approvals
Once they are written, you need to share your documents again with those who helped you develop them. Let those employees review the policy document language
well before you implement them. These reviews allow you to assess the impact of the policy or standard on the organization before deploying it in a potentially
disruptive fashion.
These reviews sometimes require you to revise parts of a policy or standard to allow for current conditions. Sometimes you may need to postpone implementing some
controls until the environment is better prepared for compliance. Early in your overall policy development project, you should work with your organization’s audit
group to determine how soon after policy publication they will audit based on the policy. By allowing a grace period for compliance, you are helping to ensure that the
policies will be enforceable. A grace period gives personnel time to implement any project, processes, or internal communications necessary for compliance.
TIP
If you cannot implement controls immediately, postpone the implementation date. Let people know that new controls are coming at a future specific date. Depending on the size of the organization, the grace period can be from a few months to one year.
Allow sufficient time to gather and address concerns, as well as sufficient time for the business to prepare its employees for the change. Once you gain the
concurrence of those subject to the policies, it’s vital to gain approval from their managers or their management team. Often, executive managers appoint delegates
for standards reviews and rely on recommendations before they approve or reject changes. If you’ve done a good job with those subject to the specific standards,
approvals should be timely.
Ultimately, your goal is to gain senior executive approval of the policy or standard. The executive approver may be the chief information security officer (CISO), if the
role exists. That person is unlikely to give approval if all parties have not reviewed the document. Internal reviews within the IS department should help mitigate
some of the executive approver’s concerns once the document reaches him or her for approval. Here are some suggested people who should be given the opportunity
to become a second or third layer of review:
• Technical personnel—You may need to call upon the expertise of technical staff with specific security and/or technical knowledge in the area about which you are writing.
• Legal—The legal department should have input into the policy development process. They can provide advice on current legislation that requires certain types of information to be protected in specific ways. Your legal department should also review policy and standards documents once they are complete.
• Human resources (HR)—The HR department may need to review and/or approve your policy or standard if your document addresses topics covered by existing HR policies. E-mail usage and physical security are examples. Make sure you reference the HR policy rather than repeat content. Simply repeating content
can lead to future inconsistencies.
• Audit and compliance—Internal audit personnel will monitor compliance with a policy once it is in force. If you work with external compliance groups, consult with them as needed. While the internal audit team members generally will not be the ones to approve policy changes, they can express an opinion or concerns that
should be addressed.
Although these review steps may seem onerous, early buy-in is needed to ensure there are no surprises when policy changes take effect. It’s better to put in the time
and effort early in the process to avoid rework later.
Once policies and standards are approved, you need to distribute them in ways that work best in your organization.
Publishing Your Policies and Standards Library
Publishing your policy and standards library depends on the communications tools available in your organization. Many organizations use some form of an intranet
for internal communications. Different departments may have their own sub-section of the intranet, and IS should have its own. An intranet generally has a front
page or portal that announces new content on the site. It also includes news, other announcements, access to standard forms, and so on.
Sometimes, intranet sites use a back-office engine for managing content, like Microsoft SharePoint Server. Departments can use SharePoint for the documents and
contact information they wish to share, and then publish the content to the intranet for anyone to access.
If your organization uses a content management tool for departmental Web sites, you might consider using that for publishing your documents. Documents must be
readily obtainable at any time, with a copy placed on the internal network shared drives or the organization intranet. Some of the best practices for publishing your
documents are to create separate Web pages for each document and provide a link to the document itself on that Web page. The page should contain:
• Identifying information
• Overview of the document
• Last revision date and the name or initials of the person who revised the document
• Next scheduled document review date
• Keywords for the intranet search engine to simplify locating your documents
• Links to related documents
• A link to an Adobe Portable Document Format (PDF) version of the document
NOTE
You might consider a roadshow prior to the publication of major policy changes. In this context, a roadshow refers to showing up at a large gathering of employees and explaining the change. This could be as simple as being a guest at a normally scheduled department meeting or calling a town-hall meeting to announce the upcoming changes.
The medium you choose for developing your policy content may determine the level of difficulty you’ll encounter in the review cycle. Word processing documents are
appealing because they’re easy to use and convenient. However, for review purposes, word processing documents aren’t always efficient. When you’re ready with a
final draft, you can create a set of PDF documents that comprise the policy and standards library. You then publish the library in a way that’s best for your
organization.
A new class of software, called Governance, Risk, and Compliance (GRC), is available to support policy management and publication. Functions that are commonly
found in a GRC tool include:
• Assessing the proper technical and non-technical operation of controls, and mitigating/remediating areas where controls are lacking or not operating properly
(governance)
• Assisting in quantification, analysis, and mitigation of risk within the organization (risk)
• Authoring, distribution, and policy and controls mapping to the governing regulation, as well as tracking exceptions to those policies/regulations (compliance)
GRC tools are typically delivered as modules that plug in to a central GRC engine. Usually, you can license a policy and standards module. With this module, you can
use the workflow features to develop and share your documents for reviews and approvals, publish the library as Web pages, and search for relevant documents.
Some organizations use the tools for:
• Awareness training using quizzes
• E-mails to users that notify them of new content or changes to existing policies
• E-mails that notify people that new content is ready for them to review or approve
• Tracking changes to documents to ensure that important content is not lost or erroneously changed
The following GRC tools, as well as several others, are widely used:
• RSA Archer GRC, http://www.emc.com/security/rsa-archer.htm
• Symantec Control Compliance Suite, http://www.symantec.com/business/control-compliance-suite
• Modulo Risk Manager, http://modulo.com
NOTE
As part of a continuous improvement effort, plan to review and update published policies and other framework documents periodically. You’ll learn about document review and maintenance later in this chapter.
Awareness and Training
Implementation requires not only educating personnel on each of the core elements, but also on changing their role to emphasize protecting data and systems.
An awareness program can motivate employees and promote the shared beliefs discussed earlier in this chapter. Motivating employees is as important as mastering a
technology. A motivated employee can deal with the unexpected. This is particularly important when dealing with unexpected security events. Remember, it’s not
getting employees to learn the policy that’s important; it’s motivating employees to execute the policy. Additionally, this communication creates a foundation for
other discussions, such as performance appraisals and process improvement. Consequently, a security awareness program is one of the key factors for the successful
implementation of an organization-wide security policy. Awareness tools should describe and outline the specific mandate for all employees to secure organization
assets. It should also explain the core elements of the security policies and standards. The program is aimed at generating an increased interest in the information
security field in a way that’s easy to understand.
Gaining management awareness and buy-in should be your first step. Without management support and commitment, it’s unlikely that your efforts to educate the
masses later on will succeed. As you’re selling the program to your executive sponsor(s) and gaining approval for issuing your documents, use that time to leverage
their authority with managers and direct reports to ensure compliance. With that level of buy-in secure, the task of gaining buy-in from the rest of the organization is
made that much easier.
Awareness programs are often divided into two parts: awareness and training. The purpose of awareness is to provide employees with a better understanding of
security risks. The importance of security primarily focuses on the daily operation of the organization. Training should cover many potential security problems in
detail, as well as introduce a set of easy-to-understand rules to reduce the risk of problems.
Here are a few techniques that many others have found useful in “getting the message out”:
• The mantra for any awareness and training must be “Security is everyone’s responsibility.”
• It’s vital that employees clearly understand that uneducated and untrained employees can endanger sensitive information, and render useless any technical
security measure or process in place.
• It’s vital to have a good strategy that draws people and motivates them to learn how they can improve information security. Everyone has a particular learning
style. Some people are visual learners. Others learn by listening. Still others need hands-on exercises that make it personal to them. Mixing up the modes of learning
by using different media, different messages, and content-communications tools helps ensure that most people will understand and retain the information.
• People tend to be interested in stories about computer security, especially computer crimes. Making use of this may help people understand that they are going to
be the new “gatekeepers” of critical organization data. Use stories and examples from within your organization, too. Don’t focus only on the horror stories of bad
security practices. Show and tell people about the benefits of being good corporate citizens and the potential rewards for compliance.
• As much as possible, use examples that make security a personal choice. Develop scenarios where people need to make a choice as to what they might do in a
particular situation. Relate these situations to actual ones people might encounter from day to day.
Furthermore, you can help people perceive actual personal benefits from the security program, such as the new skills they will gain. For example, mention to them
how this information can help them increase the security of their personal computers at home and their own information.
Varying the methods of education can increase the success of your awareness and training program. Ensure you have a fresh, ever-evolving, and dynamic education
program. The following sections offer suggestions for broadening awareness and educating staff about security.
Security Newsletter
One interesting and valuable way to reach and educate your staff is a security newsletter. The main idea is to provide users with an interesting and engaging way of
understanding the points outlined in the policy and standards library. You can send it via e-mail or post it on your intranet.
If you develop your newsletter in-house, you may need to ask for help from others in the information security group. Also consider getting input from people outside
the group who have security-related perspectives to share with the rest of the organization. An alternative is to subscribe to third-party security newsletters that you
tailor to your organization.
The following sections describe parts of a typical security newsletter.
TIP
Rather than a formal newsletter, you could set up an Information Security Awareness area on your intranet. You could maintain several pages of information that are linked and easily updated.
Security Articles
Sometimes people appreciate reading detailed, in-depth information on a specific topic that helps them understand the subject more clearly. For example, if in a
security awareness campaign you covered e-mail threats, you could include an associated article in the next newsletter while the topic is still fresh in the employees’
minds. The following are possible article topics:
• Password security—Discuss the importance of passwords and their crucial role in the protection of the data. Other articles might include how to properly maintain user IDs and passwords, password creation and maintenance, and best practices.
• Acceptable Internet use—Discuss the possible dangers posed by Internet connectivity and information that employees should be aware of while browsing the Web from work.
• Why are they targeting us?—This could be an interesting topic to describe the motivation of different attackers and the purpose behind attacks. This can provide users a better understanding of the importance of having proper information security measures implemented
• Your role in the protection of the organization—Think of as many scenarios as you see fit. The idea for these articles is to explain the most important aspects of information security in an informal yet effective way. You could cover social aspects combined with brief technical explanations if needed.
technical TIP
Create a social network of evangelists throughout your organization. These people will act as advocates for information security and help their specific departments or groups answer questions related to their obligations for compliance. You can start with people who show an above-average level of security
interest or skills. Identify and promote these groups as a social network that speeds the adoption of security. Start by tracking the people who stand out during
awareness sessions or other training opportunities.
What Is …?
This section of the newsletter educates or informs staff and acts as an information security glossary. It includes various security terms explained in non-technical,
easy-to-understand terms. General security topics such as Trojan horses, worms, and firewalls can be covered individually, as well as other topics or concepts that
you think are useful, must-know, or that can help with compliance to standards and policies.
Ask Us
You can include an “Ask Us” section in your newsletter. Over time, you can create a frequently asked questions (FAQ) document that summarizes the questions and
answers to give users a richer experience when interacting with the IS department.
The questions and corresponding answers could be included in the next issue of the newsletter, so that it will not only be a collective information source to a large
group of people, but also stimulates the asking of further questions.
Security Resources
A “Security Resources” section might include short news pieces that cover some aspect of information security in an easy-to-understand form. The idea is to help
users understand the importance of security awareness via security news, news of the latest security breaches, losses suffered by companies due to security problems,
and so on.
Contacts
Make sure to include the contact details for the IS department so that users will know precisely whom to contact in case of a problem. Publish the intranet uniform
resource locator (URL) to your site everywhere you can to help remind people that help may be a click away.
Policy Change Control Board
Effective oversight of the policy change ensures that security is implemented in a thoughtful way. Oversight of the policy change process usually falls under an
existing committee. The committee members are often senior leaders who represent both the technology and the business interests. These individuals as leaders
ensure that the right balance between protecting the organization and operating needs is maintained.
It’s important that changes not be made unilaterally or cause unexpected consequences. To avoid these situations, form a policy change control board or committee.
You can organize this group ad hoc, meeting as needed for reviews and approvals. It can also be a standing committee or working group that meets regularly to
address changes, additions, and enhancements to policies and standards. You can develop a standard that creates the board and establishes membership
requirements. Minimally, you should include people from information security, compliance, audit, HR, leadership from other business units, and project managers
(PMs). PMs set the agenda for the meetings, take meeting minutes, assign action items, and follow up on deliverables.
NOTE
Security personnel need to be aware of policy and standards change requirements. They also need to understand the impact of the change on the IT environment. Because systems, applications, and networks are integrated, a change to one component can affect other components.
The objectives of the policy change control board are to:
• Assess policies and standards and make recommendations for change
• Coordinate requests for change (RFCs)
• Ensure that changes to existing policies and standards support the organization’s mission and goals
• Review requested changes to the policy framework
• Establish a change management process for policies and standards
A policy does not exist in a vacuum. If implemented well, it’s part of the day-to-day transactions and activity of a business. In that respect, there must be a process to
track major events, such as what went right and what went wrong. For example, if there was a breach, a post review would examine which controls should have
prevented the event or mitigated the impact. Which policies were not effective in preventing the breach? The policy and standards change-management process
ensures that policies and standards are refreshed when needed. It deals with new developments in technology and changes in the business environment. When
potential changes are identified, change management determines whether the changes should be made or a new policy or standard is needed. There must also be a
“lessons learned” process that allows for problems to be resolved and changes made to the policies and standards being designed.
NOTE
A “lessons learned” process ensures that mistakes are made once and not repeated. Lessons learned can come from anyone and anywhere.
The policy change control board assesses and approves RFCs. An RFC typically responds to known problems but can also include improvements. A challenge when
handling an RFC is to determine whether it should be approved or whether a transitional policy or standard will resolve the issue.
Business Drivers for Policy and Standards Changes
Additionally, there are business drivers for policy and standards changes, which may include the following:
• Business-as-usual developments—Over time, an organization might realize that meeting policy or standards requirements is impossible, too costly, or unnecessary given changing business conditions.
• Business exceptions—As the business changes, new systems or processes are introduced. They may vary from what a policy or standard requires.
• Business innovations—New opportunities for revenue growth or cost reduction can lead to innovative changes that were previously not considered. Standards may need to adapt to these innovations or be adjusted to permit innovations.
• Business technology innovations—New technology often comes with unknowable risks until you gain experience using it. Standards may need revisions to allow for the use of the new technology or for use in new ways that were not envisioned when the standards were developed.
• Strategic changes—An organization may change its business model and come under new regulatory requirements. For example, an organization might purchase a bank to reduce the costs of credit card processing. In this case, changes to an existing standard are far-reaching and may affect every standard in place.
Some change requests result in a complete redevelopment of the policy and standards library, or at least in one facet of the policy and standards development cycle.
Maintaining Your Policies and Standards Library
The policies and standards library is like a tree, and over time, requires pruning and maintenance. The policy change control board helps determine what changes
should be made to which documents. Other needs for changes can come about from issues related to specific users or groups, and documents may need trivial or
isolated changes. One of the tasks of the board is to determine which requests they will address and which ones are normal maintenance requests.
TIP
Establish a FAQ (frequently asked questions) site to clarify minor points in the policy. Over time, as you see the type of questions and answers that resonate with the end user, you can move those answers into the actual policy language itself.
Updates and Revisions
An update many be considered a non-substantive edit. Examples include updating a position title or a department name, correcting a typo, and repairing broken Web
site links.
Revisions may be of minor or major significance:
• A minor revision usually has low significance. An example is clarifying the wording within a sentence or paragraph.
• A major revision significantly changes the policy. Examples include new requirements, new limitations, or expanded responsibilities. These types of changes
should be sent to the policy change control board for consideration.
Throughout the chapter, you were provided with some best practices for developing your documents, numbering them appropriately, publishing your documents,
and spreading the word about them. If you follow this guidance, the change process should take minimal effort. If every change requires a complete revisiting of the
library, you have a much bigger problem on your hands.
Assuming that you follow the same development and review cycles for your updates and gain the necessary buy-in from those who are affected by changes, the most
time-consuming activity will be communicating your changes to the organization. Using the techniques and tools for communication and media, you should be able
to rely on the same processes you developed for ongoing awareness and training.
To help you determine what changes or maintenance you’ll need to perform, use the information provided by:
• Exceptions and waivers—Look for common problems related to compliance. If the standard cannot be met very often, it’s because there is a problem with the standard (or policy).
• Requests from users and management—Make it easy to obtain feedback on people’s actual experience with complying with the standards. Major requests should be formally documented and sent to the policy change control board. However, don’t ignore the feedback about what’s causing people concern or prompting
questions about the document.
• Changes to the organization—Companies come and go. Mergers and acquisitions happen constantly. Should you find yourself in a situation where your organization has bought or sold a division and you need to revisit the polices and standards for the combined organization, use the tools and techniques you’ve
learned in this chapter to help resolve conflicts or fill in gaps that come about from the change.
Best Practices for Policies and Standards Maintenance
The following list of activities and advice comes from leading practices in policy and standards development and management experts. It was culled from years of
experience and is being collected here so you can avoid many of the pitfalls others have experienced when developing a library:
• Ask yourself the key questions of who, what, where, when, why, and how as you set out to research and develop policies and standards.
• Base your decisions on core information security principles to support business objectives. Because there are no universal recipes for developing policies and
standards, you need to rely on principles to advance the cause.
• Establish a cohesive and coherent document organization taxonomy that leaves you with room for growth and changes.
• Use common templates for each type of document and stick with them. Nothing leads to confusion more than different document styles that are intended to meet
the same purposes.
• Use a collaboration tool for developing documents that allows others access to drafts early in the development cycle. It should be easy to solicit reviews and
comments.
• Establish a repeatable review process for your draft documents. The process should consider a representative sample of people who will be affected by new policies
and security controls.
• Publish your library in a form that your organization is already using. Introducing new technology for distributing policies and standards at the same time you
publish the documents may cause unnecessary confusion.
• Use a broad variety of communications and awareness media and techniques to reach a wide audience. Keep your message consistent and easy to understand.
• Establish a policy change control board to help identify major changes to the library and to keep it up to date.
• Create a “lessons learned” process to improve the policy through feedback and review of major events.
Case Studies and Examples of Designing, Organizing, Implementing, and Maintaining IT Security Policies
The following three case studies review how to develop or implement a policy framework. You will look at cases from the private sector, the public sector, and the
critical infrastructure protection area.
Private Sector Case Study
During an internal review, American Imaging Management (AIM) decided it needed to improve its due diligence practices. AIM decided to expand its corporate
security program. The company began by performing a risk assessment on its current security program.
The assessment used the ISO 27001 gap assessment methods. When complete, AIM delivered a recommended course of action. These activities were intended to
address and remediate areas that were either under- or over-controlled.
Using the Plan-Do-Act-Check cycle from the ISO standards, AIM’s activities included:
• Defining more detailed roles and responsibilities
• Identifying all relevant security requirements (legislative, regulatory, and contractual)
• Defining all supporting policies, standards, and procedures
• Defining and establishing a security awareness program
• Expanding the organization’s vulnerability management program
• Collaborating with the business continuity/disaster recovery (BC/DR) team to integrate security program objectives
• Improving the incident response program
• Implementing an internal security control audit program
By the end of the project, AIM was able to create a road map for building a security program that could be registered to the ISO 27001 standard.
Public Sector Case Study
To improve security in California’s IT infrastructure, the Office of the State Chief Information Officer (OCIO) issued a new policy that includes employee remote
access security standards for working from home or off-site. The policy also requires that state agencies complete a compliance form.
The policy was issued to help state agencies develop secure remote access for employees and minimize security risks. The corresponding standard highlights
important measures that IT agencies must adopt to certify their remote access programs. It includes controls related to the use of up-to-date operating system
software and security software for every remote connection.
The standard also requires that all computing equipment connected to the state’s IT infrastructure network for remote access purposes be state-owned and securely
configured. Remote access users can only connect through secure encrypted channels—virtual private networks—authorized by agency management. The security
measures also apply to paper files and mobile devices like personal digital assistants (PDAs).
According to the information policy letter, agency heads must comply with the following:
• Make sure authorized users permitted to use remote access are trained for their roles and responsibilities, security risks, and the requirements in the standard
• Adopt and implement the requirements in the standard and certifying their agency’s compliance
• Annually complete and submit the Agency Telework and Remote Access Security Compliance Certification form to the Office of Information Security
California was among the first governments in the country to establish enterprise-wide policies for remote access, joining states such as Virginia and Arizona, and the
federal government.
CHAPTER SUMMARY
This chapter addressed techniques for designing, organizing, implementing, and maintaining an IT security policy and standards library. The importance of
understanding the organizational culture and creating shared beliefs was discussed. You learned how understand a businesses perspective and mindset through an
understanding of its architecture operating model. You learned characteristics of policies and standards that make them easy to understand. Core security principles
were covered, which are important to remember when developing security documents. Training and awareness programs help you enforce policies and get buy-in
from employees.
You also learned about the review and approval processes that are part of creating and maintaining library documents. A policy change control board, for example, is
an efficient way to maintain policies and standards. It also helps minimize unforeseen impacts on the organization. Additionally, you learned the importance of
creating a “lessons learned” process to keep the policies current. Finally, you learned about some leading practices that others have found useful for developing and
maintaining a policy and standards library.
KEY CONCEPTS AND TERMS
Architecture operating model
Coordinated operating model
Defense in depth
Diversified operating model
Evangelists
Lessons learned
Organizational culture
Replicated operating model
Roadshow
Taxonomy
Unified operating model
CHAPTER 7 ASSESSMENT
1. When writing policies and standards, you should address the six key questions who, what, where, when, why, and how.
A. True
B. False
2. Which of the following are important to consider before a policy?
A. Architecture operating model
B. Intent
C. Policy change control board
D. A and B
E. B and C
F. A, B, and C
3. Guideline documents are often tied to a specific control standard.
A. True
B. False
4. Which of the following is not an administrative control?
A. Development of policies, standards, procedures, and guidelines
B. Screening of personnel
C. Change control procedures
D. Logical access control mechanisms
5. Which of the following are common steps taken in the development of documents such as security policies, standards, and procedures?
A. Design, development, publication, coding, and testing
B. Feasibility, development, approval, implementation, and integration
C. Initiation, evaluation, development, approval, publication, implementation, and maintenance
D. Design, coding, evaluation, approval, publication, and implementation
6. The sole purpose of an architecture operating model is to define how all the businesses technology will be implemented.
A. True
B. False
7. Exceptions or waivers to security policies are a bad idea and should never be approved.
A. True
B. False
8. Which type of control is associated with responding to and fixing a security incident?
A. Deterrent
B. Compensating
C. Corrective
D. Detective
9. List examples of physical security control items. ________
10. A process to refresh policies as needed based on a major event uses the principle called ________.
11. A(n) ________ is a plan or course of action used by an organization to convey instructions from its senior-most management to those who make decisions, take actions, and perform other duties on behalf of the organization.
12. The principle that states security is improved when it is implemented as a series of overlapping controls is called ________
13. Security principles are needed in the absence of complete information to make high-quality security decisions.
A. True
B. False
14. “Access to all Organization information resources connected to the <Organization> network must be controlled by using user IDs and appropriate authentication” is a statement you might find in a procedure document.
A. True
B. False
15. Which of the following does a policy change control board do? (Select two.)
A. Assesses policies and standards and makes recommendations for change
B. Determines the policy and standards library numbering scheme
C. Implements technical controls as business conditions change
D. Reviews requested changes to the policy framework