Policies

Policies are high-level statements of management intent. Compliance with policies is mandatory. An information security policy will generally contain broad statements about cybersecurity objectives, including:

• A statement of the importance of cybersecurity to the organization
• Requirements that all staff and contracts take measures to protect the confidentiality, integrity, and availability of information and information systems
• Statement on the ownership of information created and/or possessed by the organization
• Designation of the chief information security officer (CISO) or other individual as the executive responsible for cybersecurity issues
• Delegation of authority granting the CISO the ability to create standards, procedures, and guidelines that implement the policy

In many organizations, the process to create a policy is laborious and requires very high-level approval, often from the chief executive officer (CEO). Keeping policy statements at a high level provides the CISO with the flexibility to adapt and change specific security requirements with changes in the business and technology environments. For example, the five-page information security policy at the University of Notre Dame simply states that

The Information Governance Committee will create handling standards for each Highly Sensitive data element. Data stewards may create standards for other data elements under their stewardship. These information handling standards will specify controls to manage risks to University information and related assets based on their classification. All individuals at the University are responsible for complying with these controls.

By way of contrast, the federal government's Centers for Medicare & Medicaid Services (CMS) has a 95-page information security policy. This mammoth document contains incredibly detailed requirements, such as

A record of all requests for monitoring must be maintained by the CMS CIO along with any other summary results or documentation produced during the period of monitoring. The record must also reflect the scope of the monitoring by documenting search terms and techniques. All information collected from monitoring must be controlled and protected with distribution limited to the individuals identified in the request for monitoring and other individuals specifically designated by the CMS Administrator or CMS CIO as having a specific need to know such information.

The CMS document even goes so far as to include a complex chart describing the many cybersecurity roles held by individuals throughout the agency. An excerpt from that chart appears in Figure 16.1.

This approach may meet the needs of CMS, but it is hard to imagine the long-term maintenance of that document. Lengthy security policies often quickly become outdated as necessary changes to individual requirements accumulate and become neglected because staff are weary of continually publishing new versions of the policy.

Organizations commonly include the following documents in their information security policy library:

• Information security policy that provides high-level authority and guidance for the security program
• Acceptable use policy (AUP) that provides network and system users with clear direction on permissible uses of information resources
• Data ownership policy that clearly states the ownership of information created or used by the organization
• Data classification policy that describes the classification structure used by the organization and the process used to properly assign classifications to data
• Data retention policy that outlines what information the organization will maintain and the length of time different categories of work product will be retained prior to destruction
• Account management policy that describes the account life cycle from provisioning through active use and decommissioning
• Password policy that sets forth requirements for password length, complexity, reuse, and similar issues
• Continuous monitoring policy that describes the organization's approach to monitoring and informs employees that their activity is subject to monitoring in the workplace
• Code of conduct/ethics that describes expected behavior of employees and affiliates and serves as a backstop for situations not specifically addressed in policy

As you read through the list, you may notice that some of the documents listed tend to conflict with our description of policies as high-level documents and seem to better fit the definition of a standard in the next section. That's a reasonable conclusion to draw. CompTIA specifically includes these items as elements of information security policy while many organizations would move some of them, such as password requirements, into standards documents.

Standards

Standards provide mandatory requirements describing how an organization will carry out its information security policies. These may include the specific configuration settings used for a common operating system, the controls that must be put in place for highly sensitive information, or any other security objective. Standards are typically approved at a lower organizational level than policies and, therefore, may change more regularly.

For example, the University of California at Berkeley maintains a detailed document titled the Minimum Security Standards for Electronic Information, available online at security.berkeley.edu/minimum-security-standards-electronic-information. This document divides information into four different data protection levels (DPLs) and then describes what controls are required, optional, or not required for data at different levels using a detailed matrix. An excerpt from this matrix appears in Figure 16.2.

The standard then provides detailed descriptions for each of these requirements with definitions of the terms used in the requirements. For example, requirement 3.1 in Figure 16.2 simply reads “Secure configurations.” Later in the document, UC Berkeley expands this to read “Resource Custodians must utilize well-managed security configurations for hardware, software, and operating systems based on industry standards.” It goes on to defined “well-managed” as

• Devices must have secure configurations in place prior to deployment.
• Any deviations from defined security configurations must be approved through a change management process and documented. A process must exist to annually review deviations from the defined security configurations for continued relevance.
• A process must exist to regularly check configurations of devices and alert the Resource Custodian of any changes.

This approach provides a document hierarchy that is easy to navigate for the reader and provides access to increasing levels of detail as needed. Notice also that many of the requirement lines in Figure 16.2 provide links to guidelines. Clicking on those links leads to advice to organizations subject to this policy that begins with this text:

UC Berkeley security policy mandates compliance with Minimum Security Standards for Electronic Information for devices handling covered data. The recommendations below are provided as optional guidance.

This is a perfect example of three elements of the information security policy framework working together. Policy sets out the high-level objectives of the security program and requires compliance with standards, which includes details of required security controls. Guidelines provide advice to organizations seeking to comply with the policy and standards.

In some cases, organizations may operate in industries that have commonly accepted standards that the organization either must follow due to a regulatory requirement or choose to follow as a best practice. Failure to follow industry best practices may be seen as negligence and can cause legal liability for the organization. Many of these industry standards are expressed in the standard frameworks discussed later in this chapter.

Procedures

Procedures are detailed, step-by-step processes that individuals and organizations must follow in specific circumstances. Similar to checklists, procedures ensure a consistent process for achieving a security objective. Organizations may create procedures for building new systems, releasing code to production environments, responding to security incidents, and many other tasks. Compliance with procedures is mandatory.

For example, Visa publishes a document titled What To Do If Compromised (usa.visa.com/dam/VCOM/download/merchants/cisp-what-to-do-if-compromised.pdf) that lays out a mandatory process that merchants suspecting a credit card compromise must follow. Although the document doesn't contain the word procedure in the title, the introduction clearly states that the document “establishes procedures and timelines for reporting and responding to a suspected or confirmed Compromise Event.” The document provides requirements covering the following areas of incident response:

• Notify Visa of the incident within three days
• Provide Visa with an initial investigation report
• Provide notice to other relevant parties
• Provide exposed payment account data to Visa
• Conduct PCI forensic investigation
• Conduct independent investigation
• Preserve evidence

Each of these sections provides detailed information on how Visa expects merchants to handle incident response activities. For example, the forensic investigation section describes the use of Payment Card Industry Forensic Investigators (PFI) and reads as follows:

Upon discovery of an account data compromise, or receipt of an independent forensic investigation notification, an entity must:

• Engage a PFI (or sign a contract) within five (5) business days.
• Provide Visa with the initial forensic (i.e., preliminary) report within ten (10) business days from when the PFI is engaged (or the contract is signed).
• Provide Visa with a final forensic report within ten (10) business days of the completion of the review.

There's not much room for interpretation in this type of language. Visa is laying out a clear and mandatory procedure describing what actions the merchant must take, the type of investigator they should hire, and the timeline for completing different milestones.

Organizations commonly include the following procedures in their policy frameworks:

• Monitoring procedures that describe how the organization will perform security monitoring activities, including the possible use of continuous monitoring technology
• Evidence production procedures that describe how the organization will respond to subpoenas, court orders, and other legitimate requests to produce digital evidence
• Patching procedures that describe the frequency and process of applying patches to applications and systems under the organization's care

Of course, cybersecurity teams may decide to include many other types of procedures in their frameworks, as dictated by the organization's operational needs.

Guidelines

Guidelines provide best practices and recommendations related to a given concept, technology, or task. Compliance with guidelines is not mandatory, and guidelines are offered in the spirit of providing helpful advice. That said, the “optionality” of guidelines may vary significantly depending on the organization's culture.

In April 2016, the chief information officer (CIO) of the state of Washington published a 25-page document providing guidelines on the use of electronic signatures by state agencies. The document is not designed to be obligatory but, rather, offers advice to agencies seeking to adopt electronic signature technology. The document begins with a purpose section that outlines three goals of the guideline:

1. Help agencies determine if, and to what extent, their agency will implement and rely on electronic records and electronic signatures.
2. Provide agencies with information they can use to establish policy or rule governing their use and acceptance of digital signatures.
3. Provide direction to agencies for sharing of their policies with the Office of the Chief Information Officer (OCIO) pursuant to state law.

The first two stated objectives line up completely with the function of a guideline. Phrases like “help agencies determine” and “provide agencies with information” are common in guideline documents. There is nothing mandatory about them and, in fact, the guidelines explicitly state that Washington state law “does not mandate that any state agency accept or require electronic signatures or records.”

The third objective might seem a little strange to include in a guideline. Phrases like “provide direction” are more commonly found in policies and procedures. Browsing through the document, the text relating to this objective is only a single paragraph within a 25-page document, reading

The Office of the Chief Information Officer maintains a page on the OCIO.wa.gov website listing links to individual agency electronic signature and record submission policies. As agencies publish their policies, the link and agency contact information should be emailed to the OCIO Policy Mailbox. The information will be added to the page within 5 working days. Agencies are responsible for notifying the OCIO if the information changes.

Reading this paragraph, the text does appear to clearly outline a mandatory procedure and would not be appropriate in a guideline document that fits within the strict definition of the term. However, it is likely that the committee drafting this document thought it would be much more convenient to the reader to include this explanatory text in the related guideline rather than drafting a separate procedure document for a fairly mundane and simple task.

Exceptions and Compensating Controls

When adopting new security policies, standards, and procedures, organizations should also provide a mechanism for exceptions to those rules. Inevitably, unforeseen circumstances will arise that require a deviation from the requirements. The policy framework should lay out the specific requirements for receiving an exception and the individual or committee with the authority to approve exceptions.

The state of Washington uses an exception process that requires the requestor document the following information:

• Standard/requirement that requires an exception
• Reason for noncompliance with the requirement
• Business and/or technical justification for the exception
• Scope and duration of the exception
• Risks associated with the exception
• Description of any supplemental controls that mitigate the risks associated with the exception
• Plan for achieving compliance
• Identification of any unmitigated risks

Many exception processes require the use of compensating controls to mitigate the risk associated with exceptions to security standards. The Payment Card Industry Data Security Standard (PCI DSS) includes one of the most formal compensating control processes in use today. It sets out three criteria that must be met for a compensating control to be satisfactory:

1. The control must meet the intent and rigor of the original requirement.
2. The control must provide a similar level of defense as the original requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against.
3. The control must be “above and beyond” other PCI DSS requirements.

For example, an organization might find that it needs to run an outdated version of an operating system on a specific machine because software necessary to run the business will only function on that operating system version. Most security policies would prohibit using the outdated operating system because it might be susceptible to security vulnerabilities. The organization could choose to run this system on an isolated network with either very little or no access to other systems as a compensating control.

The general idea is that a compensating control finds alternative means to achieve an objective when the organization cannot meet the original control requirement. While PCI DSS offers a very formal process for compensating controls, the use of compensating controls is a common strategy in many different organizations, even those not subject to PCI DSS. Compensating controls balance the fact that it simply isn't possible to implement every required security control in every circumstance with the desire to manage risk to the greatest feasible degree.

In many cases, organizations adopt compensating controls to address a temporary exception to a security requirement. In those cases, the organization should also develop remediation plans designed to bring the organization back into compliance with the letter and intent of the original control.

NIST Cybersecurity Framework

The National Institute for Standards and Technology (NIST) is responsible for developing cybersecurity standards across the U.S. federal government. The guidance and standard documents they produce in this process often have wide applicability across the private sector and are commonly referred to by nongovernmental security analysts due to the fact that they are available in the public domain and are typically of very high quality.

In 2014, NIST released a Cybersecurity Framework designed to assist organizations attempting to meet one or more of the following five objectives:

• Describe their current cybersecurity posture.
• Describe their target state for cybersecurity.
• Identify and prioritize opportunities for improvement within the context of a continuous and repeatable process.
• Assess progress toward the target state.
• Communicate among internal and external stakeholders about cybersecurity risk.

The NIST framework includes three components:

• The Framework Core, shown in Figure 16.3, is a set of five security functions that apply across all industries and sectors: identify, protect, detect, respond, and recover. The framework then divides these functions into categories, subcategories, and informative references. Figure 16.4 shows a small excerpt of this matrix in completed form, looking specifically at the Identify (ID) function and the Asset Management category. If you would like to view a fully completed matrix, see NIST's document Framework for Improving Critical Infrastructure Cybersecurity.
• The framework implementation tiers assess how an organization is positioned to meet cybersecurity objectives. Table 16.1 shows the framework implementation tiers and their criteria. This approach is an example of a maturity model that describes the current and desired positioning of an organization along a continuum of progress. In the case of the NIST maturity model, organizations are assigned to one of four maturity model tiers.
• Framework profiles describe how a specific organization might approach the security functions covered by the framework core. An organization might use a framework profile to describe its current state and then a separate profile to describe its desired future state.

The NIST Cybersecurity Framework provides organizations with a sound approach to developing and evaluating the state of their cybersecurity programs.

ISO 27001

The International Organization for Standardization (ISO) publishes ISO 27001, a standard document titled “Information technology—Security techniques—Information security management systems—Requirements.” This standard includes control objectives covering 14 categories:

• Information security policies
• Organization of information security
• Human resource security
• Asset management
• Access control
• Cryptography
• Physical and environmental security
• Operations security
• Communications security
• System acquisition, development, and maintenance
• Supplier relationships
• Information security incident management
• Information security aspects of business continuity management
• Compliance with internal requirements, such as policies, and with external requirements, such as laws

The ISO 27001 standard was once the most commonly used information security standards, but it is declining in popularity outside of highly regulated industries that require ISO compliance. Organizations in those industries may choose to formally adopt ISO 27001 and pursue certification programs where an external assessor validates their compliance with the standard and certifies them as operating in accordance with ISO 27001.

Control Objectives for Information and Related Technologies (COBIT)

The Control Objectives for Information and Related Technologies (COBIT) is a set of best practices for IT governance developed by the Information Systems Audit and Control Association (ISACA). COBIT divides information technology activities into four domains:

• Plan and Organize
• Acquire and Implement
• Deliver and Support
• Monitor and Evaluate

COBIT addresses each of these four domains of technology by providing five COBIT framework components:

• COBIT framework
• Process descriptions
• Control objectives
• Management guidelines
• Maturity models

Information Technology Infrastructure Library (ITIL)

The Information Technology Infrastructure Library (ITIL) is a framework that offers a comprehensive approach to IT service management (ITSM) within the modern enterprise. ITIL covers five core activities:

• Service Strategy
• Service Design
• Service Transition
• Service Operation
• Continual Service Improvement

Figure 16.5 shows how these activities fit together in the ITIL service life cycle. Although it is not widely used as a cybersecurity framework, many organizations choose to adopt ITIL ITSM practices and then include cybersecurity functions within their ITIL implementation.

Security Control Categories

Security controls are categorized based on their mechanism of action—the way that they achieve their objectives. There are three different categories of security control:

• Technical controls enforce confidentiality, integrity, and availability in the digital space. Examples of technical security controls include firewall rules, access control lists, intrusion prevention systems, and encryption.
• Operational controls include the processes that we put in place to manage technology in a secure manner. These include user access reviews, log monitoring, and vulnerability management.
• Managerial controls are procedural mechanisms that focus on the mechanics of the risk management process. Examples of administrative controls include periodic risk assessments, security planning exercises, and the incorporation of security into the organization's change management, service acquisition, and project management practices.

Organizations should select a set of security controls that meets their control objectives based on the criteria and parameters that they either select for their environment or have imposed on them by outside regulators. For example, an organization that handles sensitive information might decide that confidentiality concerns surrounding that information require the highest level of control. At the same time, they might conclude that the availability of their website is not of critical importance. Given these considerations, they would dedicate significant resources to the confidentiality of sensitive information while perhaps investing little, if any, time and money protecting their website against a denial-of-service attack.

Many control objectives require a combination of technical, operational, and management controls. For example, an organization might have the control objective of preventing unauthorized access to a datacenter. They might achieve this goal by implementing biometric access control (technical control), performing regular reviews of authorized access (operational control), and conducting routine risk assessments (managerial control).

Security Control Types

CompTIA also divides security into types, based on their desired effect. The types of security control include

• Preventive controls intend to stop a security issue before it occurs. Firewalls and encryption are examples of preventive controls.
• Detective controls identify security events that have already occurred. Intrusion detection systems are detective controls.
• Corrective controls remediate security issues that have already occurred. Restoring backups after a ransomware attack is an example of a corrective control.
• Deterrent controls seek to prevent an attacker from attempting to violate security policies. Vicious guard dogs and barbed wire fences are examples of deterrent controls.
• Physical controls are security controls that impact the physical world. Examples of physical security controls include fences, perimeter lighting, locks, fire suppression systems, and burglar alarms.
• Compensating controls, discussed earlier in this chapter, are designed to mitigate the risk associated with exceptions made to a security policy.

Activity 16.1: Policy Documents

Match the following policy documents with their descriptions.

Activity 16.2: Using a Cybersecurity Framework

Download and read the current version of the NIST Framework for Improving Critical Infrastructure Cybersecurity (nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf).

Choose a specific category from the framework core that appears in Table 2 at the end of the document. If you are currently employed, describe how your organization addresses each of the subcategories for that function and category. If you are not currently employed, perform the same analysis for an organization with which you are familiar to the best of your ability.

Activity 16.3: Compliance Auditing Tools

The Payment Card Industry Data Security Standard (PCI DSS) includes detailed testing procedures for each one of the standard's requirements.

Download a copy of the current PCI DSS standard from the PCI Security Standards Council website (www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss). Find the section of the standard that includes requirements for password construction (section 8.2.3 in PCI DSS version 3.2.1).

Describe the testing procedures that an auditor would follow to determine whether an organization is in compliance with this requirement.

1. Joe is authoring a document that explains to system administrators one way that they might comply with the organization's requirement to encrypt all laptops. What type of document is Joe writing?
   1. Policy
   2. Guideline
   3. Procedure
   4. Standard
2. Which one of the following statements is not true about compensating controls under PCI DSS?
   1. Controls used to fulfill one PCI DSS requirement may be used to compensate for the absence of a control needed to meet another requirement.
   2. Controls must meet the intent of the original requirement.
   3. Controls must meet the rigor of the original requirement.
   4. Compensating controls must provide a similar level of defense as the original requirement.
3. What law creates cybersecurity obligations for healthcare providers and others in the health industry?
   1. HIPAA
   2. FERPA
   3. GLBA
   4. PCI DSS
4. Which one of the following is not one of the five core security functions defined by the NIST Cybersecurity Framework?
   1. Identify
   2. Contain
   3. Respond
   4. Recover
5. What ISO standard applies to information security management controls?
   1. 9001
   2. 27001
   3. 14032
   4. 57033
6. Which one of the following documents must normally be approved by the CEO or similarly high-level executive?
   1. Standard
   2. Procedure
   3. Guideline
   4. Policy
7. Greg recently conducted an assessment of his organization's security controls and discovered a potential gap: the organization does not use full-disk encryption on laptops. What type of control gap exists in this case?
   1. Detective
   2. Corrective
   3. Deterrent
   4. Preventive
8. What law governs the financial records of publicly traded companies?
   1. GLBA
   2. SOX
   3. FERPA
   4. PCI DSS
9. What type of security policy often serves as a backstop for issues not addressed in other policies?
   1. Account management
   2. Data ownership
   3. Code of conduct
   4. Continuous monitoring
10. Which one of the following would not normally be found in an organization's information security policy?
    1. Statement of the importance of cybersecurity
    2. Requirement to use AES-256 encryption
    3. Delegation of authority
    4. Designation of responsible executive
11. Darren is updating the organization's risk management process. What type of control is Darren creating?
    1. Operational
    2. Technical
    3. Corrective
    4. Managerial
12. Which one of the following control models describes the five core activities associated with IT service management as service strategy, service design, service transition, service operation, and continual service improvement?
    1. COBIT
    2. TOGAF
    3. ISO 27001
    4. ITIL
13. What compliance obligation applies to merchants and service providers who work with credit card information?
    1. FERPA
    2. SOX
    3. HIPAA
    4. PCI DSS
14. Which one of the following policies would typically answer questions about when an organization should destroy records?
    1. Data ownership policy
    2. Account management policy
    3. Password policy
    4. Data retention policy
15. While studying an organization's risk management process under the NIST Cybersecurity Framework, Rob determines that the organization adapts its cybersecurity practices based on lessons learned and predictive indicators derived from previous and current cybersecurity activities. What tier should he assign based on this measure?
    1. Tier 1
    2. Tier 2
    3. Tier 3
    4. Tier 4
16. Which one of the following security policy framework components does not contain mandatory guidance for individuals in the organization?
    1. Policy
    2. Standard
    3. Procedure
    4. Guideline
17. Tina is creating a set of firewall rules designed to block denial-of-service attacks from entering her organization's network. What type of control is Tina designing?
    1. Technical control
    2. Physical control
    3. Managerial control
    4. Operational control
18. Allan is developing a document that lists the acceptable mechanisms for securely obtaining remote administrative access to servers in his organization. What type of document is Allan writing?
    1. Policy
    2. Standard
    3. Guideline
    4. Procedure
19. Which one of the following is not a common use of the NIST Cybersecurity Framework?
    1. Describe the current cybersecurity posture of an organization.
    2. Describe the target future cybersecurity posture of an organization.
    3. Communicate with stakeholders about cybersecurity risk.
    4. Create specific technology requirements for an organization.
20. Shelly is writing a document that describes the steps that incident response teams will follow upon first notice of a potential incident. What type of document is she creating?
    1. Policy
    2. Standard
    3. Guideline
    4. Procedure