The Unified Scoping Guide (USG) is a free resource that 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 model categorizes system components according to several factors:
This is an evolution of the CUI Scoping Guide that ComplianceForge previously published. This new version is updated to reflect the DoD's CMMC 2.0 Level 2 Scoping Guidance that includes Controlled Unclassified Information (CUI) scoping 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:
|
|
When viewing scoping, there are nine (9) zones for sensitive data compliance purpose.
Zone 1: All systems, applications and services that store, transmit and/or process sensitive data are Category 1 devices. These systems that interact with sensitive data are the main assets that sensitive data are trying to protect
Zone 2: All network devices or hypervisors that provide segmentation functions are Category 2 devices. This category involves systems that provide segmentation and prevent "sensitive data contamination" from the sensitive data environment to uncontrolled environments. Typically, these are firewalls or segmentation technology that implement some form of Access Control List (ACL) to restrict logical access into and out of the sensitive data environment. This can also include Zero Trust Architecture (ZTA) components that provide micro-segmentation services
Note: If network segmentation is in place and is being used to reduce the scope of an assessment, expect the assessor to verify that the segmentation is adequate to reduce the scope of the assessment. the more detailed the documentation your assessor will require to adequately review the implemented segmenting solution.
Zone 3: All systems that provide security-related services or IT-enabling services that may affect the security of the sensitive data environment are Category 3 devices. There are systems that can impact configurations, security services, logging, etc. that can be in a dedicated security subnet or on the corporate LAN.
These include, at a minimum:
Zone 4: Any system that has some capability to communicate with systems, applications or services within the sensitive data environment is a Category 4 device. A “connected” system, embedded technologies, application or service should be considered in scope for since it is not completely isolated. If it can potentially impact the security of sensitive data, it is in scope.
There are two sub-categories of connected devices:
Zone 4A: This sub-category addresses any system that is “connected to” the sensitive data environment is considered a directly-connected system. Any system outside of the sensitive data environment that is capable of communicating with a system that stores, transmits or processes sensitive data (e.g., asset within the sensitive data environment) is a Category 4A device.
Note: For systems outside of the sensitive data environment that have periodic controlled and managed outbound connections from the sensitive data environment that do not involve the transfer of regulated data (sensitive data), there is a case to argue that the system could be ruled out-of-scope since it cannot have an impact on the security of sensitive data. In cases like this, some form of Data Loss Prevention (DLP) tool may be warranted to act as a compensating control to further demonstrate how the asset would be out-of-scope.
Zone 4B: This sub-category addresses any system that does not have any direct access to sensitive data systems (e.g., not interacting with the sensitive data environment). Any system that has access to Connected or Segmenting systems and that could affect the security of the sensitive data environment is a Category 4B device.
An example of an indirectly connected system would be that of an administrator's workstation that can administer a security device (Active Directory, firewall, etc.) or upstream system that feeds information to connected systems (e.g. patching system, DNS, etc.). In the case of a user directory, an administrator could potentially grant himself/herself (or others) rights to systems in the sensitive data environment, therefore breaching the security controls applicable to the sensitive data environment.
Zone 5: Any system, application or service that is not a sensitive data-contaminated, segmenting or connected system is a Category 5 asset. These assets are considered out-of-scope for sensitive data. These out-of-scope assets must be completely isolated (no connections whatsoever) from sensitive data systems, though they may interact with connected systems (and can even reside in the same network zone with connected systems).
Four (4) tests must be considered to confirm that a system is out-of-scope and considered a Category 5 asset. This amounts to ensuring that the asset does not fall under the previously defined categories:
Zone 6: This category addresses enterprise-wide security controls that exist outside of just the sensitive data environment. Within this category are the corporate-wide security practices that affect both cyber and physical security, including security-related policies, standards and procedures that affect the entire organization.
Zone 7: Sensitive data in the supply chain needs to be taken seriously and this category addresses External Service Providers (ESPs). The formal contracts between your organization its ESPs dictate the logical and physical access those ESP have to the organization’s facilities, systems and data. The “flow down” considerations of sensitive data must be addressed with each ESP to clearly identify the ESPs’ ability to directly or indirectly influence the sensitive data environment.
Examples of ESPs that may have sensitive data flow down requirements:
Zone 8: This category addresses subcontractors necessary to perform the in-scope contract. While a subcontractor is a third-party, a subcontractor is party to the actual execution of the contract where the subcontractor may create, access, receive, store and/or transmit sensitive data.
Zone 9: This category addresses ESP providing cloud computing services that enable ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. A CSP can be identified by its function, since the cloud model is composed of five (5) essential characteristics, three (3) service models and four (4) deployment models:
Essential Characteristics:
Service Models:
Deployment Models:
?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:
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:
This guide is not endorsed by any statutory or regulatory body. This is merely an unofficial model that ComplianceForge compiled to help organizations comply with their cybersecurity and data privacy compliance needs.
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:
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:
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:
This model categorizes system components according to several factors:
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.
Secure Controls Framework (SCF)
Secure Controls Framework (SCF) "Premium Content" - Expertise-Class Policies, Control Objectives, Standards, Guidelines, Controls & Metrics. Product Walkthrough Video This short product walkthrough video is designed to give a brief overview about...
ComplianceForge - NIST 800-171 & CMMC
NIST 800-171 R2 & R3 / CMMC 2.0 Editable & Affordable Cybersecurity Documentation This short product walkthrough video is designed to give a brief overview about what the NCP is to help answer common questions we receive. Includes...
Determining the scope of controls (e.g., assessment boundary) is different than determining control...
As a Chief Information Security Officer (CISO) or cybersecurity director, it is likely that you been...
The release of the Cybersecurity & Data Protection Assessment Standards (CDPAS) is important to the...
There is a "materiality ecosystem" that exists within modern cybersecurity risk management discussio...
