Can you clearly define what makes up your sensitive data environment? 

   Zone-Based Model To Apply A Data-Centric Security Approach For Scoping Sensitive & Regulated Data   

ComplianceForge is a leader in cybersecurity and data protection compliance documentation, including NIST 800-171 and Cybersecurity Maturity Model Certification (CMMC), and in conjunction with metaSCRM, built this scoping guide as a free resource to help educate organizations that must comply with laws, regulations and contracts to protect sensitive and regulated data.

 

This is an evolution of the CUI Scoping Guide that ComplianceForge previously published. This new version includes Controlled Unclassified Information (CUIscoping considerations, but expands on the model to address a broader category of sensitive and regulated data. This document can be used to help companies define what is in scope to comply with NIST SP 800-171 and appropriately prepare for a CMMC assessment, since a significant step towards becoming NIST SP 800-171 compliant and being able to pass a CMMC assessment is understanding the scope of the CUI environment.

The Unified Scoping Guide (USG) is intended to help organizations define the scope of the sensitive data where it is stored, transmitted and/or processed. This guide will refer to both sensitive and regulated data as “sensitive data” to simplify the concept this document is focused on. This approach is applicable to the following sensitive data types:

  • Controlled Unclassified Information (CUI)

  • Personally Identifiable Information (PII)

  • Cardholder Data (CHD)

  • Attorney-Client Privilege Information (ACPI)

  • Export-Controlled Data (ITAR / EAR)

  • Federal Contract Information (FCI)

  • Protected Health Information (PHI)

  • Intellectual Property (IP)

  • Student Educational Records (FERPA)

  • Critical Infrastructure Information (CII)

   Scoping Is A Due Diligence Activity   

Failure to adequately perform due diligence in scoping activities may lead to every system, application and service in your organization to be considered in scope and require applicable statutory, regulatory and/or contractual controls. The old adage of “if you fail to plan, you plan to fail” is very applicable in this scenario, so taking the time to document assets and data flows is of the utmost importance to ensure an accurate understanding of the people, processes and technology involved exists.

In practical terms, security and data protection controls exist to protect an organization’s data. Requirements for asset management do not primarily exist to protect the inherent value of the asset, but the data it contains, since assets are merely data containers. Assets, such as laptops, servers and network infrastructure are commodities that can be easily replaced, but data residing on those devices cannot. This concept of being data-centric is crucial to understand when developing, implementing and governing a cybersecurity and privacy program, since it provides guidelines to establish the scope for control applicability.

This model categorizes system components according to several factors:

  • Whether sensitive data is being stored, processed or transmitted;

  • The functionality that the system component provides (e.g. access control, logging, antimalware, etc.); and

  • The connectivity between the system and the sensitive data environment. 

CMMC CUI Scoping Guide.jpg

The model utilizes eight (8) zones to categorize system components, based on the interaction with sensitive data. This model highlights the different types of risks associated with each zone. This approach makes it evident which systems, applications and services must be appropriately protected, due to the risk posed to sensitive data. The Sensitive Data Environment (SDE) encompasses the people, processes and technologies that store, process and transmit sensitive data: 

  • Store – When sensitive data is inactive or at rest (e.g., located on electronic media, system component memory, paper)

  • Process – When sensitive data is actively being used by a system component (e.g., entered, edited, manipulated, printed, viewed)

  • Transmit – When sensitive data is being transferred from one location to another (e.g., data in motion).

This guide is not endorsed by any statutory or regulatory body. This is merely an unofficial model that ComplianceForge and metaSCRM compiled to help organizations comply with their cybersecurity and data privacy compliance needs. 

   Segmentation Considerations  

It is important to understand that without adequate network segmentation (e.g., a flat network) the entire network would be expected to be in scope for an assessment. Network segmentation should be viewed as a very beneficial process to isolate system components that store, process or transmit sensitive data from systems that do not. Adequate network segmentation may reduce the scope of the SDE and overall reduce the scope of an assessment. It is important to point out that Zero Trust Architecture (ZTA) still has scoping requirements and is not a “magic bullet” to eliminate scoping requirements. Examples of mechanisms that provide controlled access include firewalls, routers, hypervisors, micro-segmentation (e.g., ZTA), etc.

 

To eliminate ambiguity surrounding the term “segmentation” in terms of sensitive data enclave scoping, this guide uses one of the two following terms:

  • Isolation – No logical access. This is achieved when network traffic between two assets is not permitted.

  • Controlled Access – Logical access is permitted. This is achieved when access between assets is restricted to defined parameters.

    • Controlled access is more common than isolation.

    • Restrictions may include logical access control, traffic type (e.g., port, protocol or service), the direction from which the connection is initiated (e.g., inbound, outbound), etc.

   Rationalizing Data Scoping Recommendations  

When evaluating the available guidance that exists to perform appropriate scoping activities, the Payment Card Industry Data Security Standard (PCI DSS) reigns, due to its long-established and internationally-recognized practices for protecting cardholder data (e.g., credit and debit cards). PCI DSS v1.0 was first published in 2004, so it has nearly two decades of guidance for “what looks right” to scope environments that require the implementation of PCI DSS controls to protect the confidentiality and integrity of cardholder data. The Payment Card Industry Security Standards Council (PCI SSC) publishes an authoritative scoping guide for merchants to leverage for PCI DSS compliance efforts. This PCI SSC scoping guidance is based on real-world threats and practical lessons-learned on how segmentation can be used to minimize scoping, due to limiting the ability of threats to negatively impact cardholder data.

 

Since PCI DSS is data-centric, that scoping guidance can be directly applied to other forms of data that require protection. This guide leveraged the outstanding concepts that PCI Resources published in its PCI DSS Scoping Model and Approach[2] by applying that scoping methodology to other types of sensitive data.

 

PCI DSS is a well-established and widely-adopting standard for protecting cardholder data (e.g., credit and debit cards). PCI DSS v1.0 was first published in 2004, so there is nearly two decades of guidance for “what looks right” to scope environments that require the implementation of PCI DSS controls to protect the confidentiality and integrity of cardholder data. From the perspective of PCI DSS, if scoping is done poorly, an organization’s entire network may be in-scope, which means PCI DSS requirements would apply uniformly throughout the entire company’s network. In these scenarios, PCI DSS compliance can be prohibitively expensive or even technically impossible. However, when the network is intelligently designed with security in mind, the Cardholder Data Environment (CDE) can be a small fraction of the company's network, which makes compliance much more achievable and affordable.

 

When you look at sensitive data compliance scoping, it has some similarities to PCI DSS:

  • PCI DSS is focused on protecting the confidentiality and integrity of cardholder data, which is where credit/debit card data is stored, processed and transmitted.

  • Statutory, regulatory and contractual obligations to protect sensitive data require controls to be implemented on the applicable environment(s) (e.g., system, application, service, etc.) where the sensitive data is stored, processed or transmitted. This is how PCI DSS applies its controls from a scoping perspective.

  • Cardholder data is considered “infectious” from the perspective of scoping. Without proper segmentation and clear business processes, other forms of sensitive data can “infect” the entire network and greatly expand the scope of compliance and audits.

   What This Guide Does Address  

Identifying and addressing the people, processes and technologies around sensitive data is a necessary part of any cybersecurity and data protection (privacy) program. This guide focuses on categorizing the system components that comprise a company's computing environment and helps with the following: 

  • Assists in determining which system components fall in and out of scope.

  • Facilitates constructive communication between your company and an assessor/regulator by providing a reasonable methodology to describe your technology infrastructure and sensitive data environment.

  • Provides a means to categorize the various different types of assets, each with a different risk profile associated with it.

  • Provides a starting point to potentially reduce the scope of sensitive data by re-architecting technologies to isolate and control access to the sensitive data environment.

 

This model categorizes system components according to several factors:

  • Whether sensitive data is being stored, processed or transmitted;

  • The functionality that the system component provides (e.g. access control, logging, antimalware, etc.); and

  • The connectivity between the system and the Sensitive Data Environment (SDE).

   What This Guide Does Not Address  

This guide does not define which statutory, regulatory and/or contractual controls are required for each category. Since every organization is different, it is up to each organization and its assessor to determine the nature, extent and effectiveness of each control to adequately mitigate the risks to sensitive data.