nist 800-171 & cmmc compliance scoping guideexamples.complianceforge.com/nist-800-171/nist...

Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.

NIST 800-171 & Cybersecurity Maturity Model Certification

(CMMC) Compliance Scoping Guide for Controlled Unclassified

Information (CUI)

Version 2020.1


Table of Contents Executive Summary ...................................................................................................................................................... 3

Understanding The Intent of NIST 800-171 & CMMC ...................................................................................................... 4 Addressing Confidentiality, Integrity, Availability & Safety (CIAS) ............................................................................................................. 4 Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012........................................................................................... 4 Controlled Unclassified Information (CUI) ................................................................................................................................................. 5 Cybersecurity Maturity Model Certification (CMMC) ................................................................................................................................ 5

Scoping NIST 800-171.................................................................................................................................................... 6 What This Guide Does Address .................................................................................................................................................................. 6 What This Guide Does Not Address ........................................................................................................................................................... 6 Segmentation Considerations .................................................................................................................................................................... 6 NIST 800-171 / CMMC Due Diligence & Due Care Steps ........................................................................................................................... 7

Scoping Categories ....................................................................................................................................................... 8 Category 1: Contaminated ......................................................................................................................................................................... 9 Category 2: Segmenting ............................................................................................................................................................................. 9 Category 3: Security Tools ......................................................................................................................................................................... 9 Category 4: Connected .............................................................................................................................................................................. 9 Category 5: Out-of-Scope ........................................................................................................................................................................ 10 In-Scope Matrix ........................................................................................................................................................................................ 11 System-to-System Communications ........................................................................................................................................................ 11 CUI Scoping Decision Tree ....................................................................................................................................................................... 12

Appendix A – Documentation To Support NIST 800-171 Compliance & CMMC .............................................................. 13 Cybersecurity Documentation Components ............................................................................................................................................ 13 NIST 800-171 In a Nutshell ....................................................................................................................................................................... 14 NIST 800-171 Specific Documentation .................................................................................................................................................... 14 Cybersecurity Documentation Hierarchy – Understanding How Cybersecurity Documentation Is Connected ...................................... 15 Example NIST 800-171 Cybersecurity Documentation ............................................................................................................................ 16

Appendix B – Utilizing SP-CMM To Identify A Capability Maturity “Sweet Spot” ........................................................... 17 Negligence Considerations ...................................................................................................................................................................... 17 Risk Considerations .................................................................................................................................................................................. 17 Process Review Lag Considerations ......................................................................................................................................................... 17 Stakeholder Value Considerations ........................................................................................................................................................... 17 CMM 0 – Not Performed ......................................................................................................................................................................... 18 CMM 1 – Performed Informally ............................................................................................................................................................... 18 CMM 2 – Planned & Tracked ................................................................................................................................................................... 19 CMM 3 – Well-Defined ............................................................................................................................................................................ 19 CMM 4 – Quantitatively Controlled ......................................................................................................................................................... 20 CMM 5 – Continuously Improving ........................................................................................................................................................... 20 Example CMM Reporting ......................................................................................................................................................................... 21


EXECUTIVE SUMMARY This document is intended to help companies comply with NIST 800-171 and prepare for a Cybersecurity Maturity Model Certification (CMMC) audit. Part of the process of becoming compliant with this regulation is understanding the scope of the Controlled Unclassified Information (CUI) environment. Given that there are similarities between scoping for NIST 800-171 and the Payment Card Industry Data Security Standard (PCI DSS), we leveraged the outstanding concepts that the PCI Resources published in their PCI DSS Scoping Model and Approach1 by applying the scoping methodology to NIST 800-171. When you look at NIST 800-171 compliance scoping, it has some similarities to PCI DSS:

PCI DSS is focused on protecting the Cardholder Data Environment (CDE), which is where payment card data is stored, processed and transmitted.

NIST 800-171 is focused on protecting the CUI environment, which is where sensitive data (in regard to US national security) is stored, processed or transmitted.

Both cardholder data and CUI are considered “infectious” from the perspective of scoping. Without proper segmentation and clear business processes, CUI “infects” the entire network and greatly expands the scope of compliance and audits.

From the perspective of PCI DSS, if scoping is done poorly, a company's entire network may be in-scope as the CUI, which means PCI DSS requirements would apply uniformly throughout the entire company. 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 CDE can be a small fraction of the company's network, which makes compliance much more achievable and affordable. We feel that NIST 800-171 should be viewed in the very same manner. This guide is not endorsed by the National Institute of Science and Technology (NIST) or any other organization. This is merely an unofficial guide that ComplianceForge compiled to help companies comply with NIST 800-171. If you are unsure what CUI is, we highly recommend that you visit the US government’s authority on the matter, the US Archive’s CUI Registry - https://www.archives.gov/cui/registry.

1PCI Resources - PCI DSS Scoping Model and Approach https://www.pciresources.com/pci-dss-scoping-model-and-approach/

https://www.archives.gov/cui/registry

https://www.pciresources.com/pci-dss-scoping-model-and-approach/


UNDERSTANDING THE INTENT OF NIST 800-171 & CMMC If you are new to NIST 800-171, it is intended to help "non-federal entities" (e.g., government contractors) comply with reasonably-expected security requirements by using the systems and practices that government contractors already have in place, rather than trying to use government-specific approaches. NIST 800-171 also provides a standardized and uniform set of requirements for all Controlled Unclassified Information (CUI) security needs, tailored to non-federal systems, allowing government contractors to comply and consistently implement safeguards for the protection of CUI. When it comes down to it, NIST 800-171 is designed to address common deficiencies in managing and protecting unclassified information.

ADDRESSING CONFIDENTIALITY, INTEGRITY, AVAILABILITY & SAFETY (CIAS) Protecting the systems that process, store and transmit CUI is of critical importance. Therefore, safeguards must exist to offset possible threats to the confidentiality, integrity and availability of CUI and the systems that enable access to it. This used to be considered the “CIA Triad,” but now it also has a safety component. This concept forms the foundation of what cybersecurity measures are implemented to protect:

CONFIDENTIALITY – Confidentiality addresses preserving restrictions on information access and disclosure so that access is limited to only authorized users and services.

INTEGRITY – Integrity addresses the concern that sensitive

data has not been modified or deleted in an unauthorized and undetected manner.

AVAILABILITY – Availability addresses ensuring timely and

reliable access to and use of information. SAFETY – Safety addresses reducing risk associated with

embedded technologies that could fail or be manipulated by nefarious actors.

DEFENSE FEDERAL ACQUISITION REGULATION SUPPLEMENT (DFARS) 252.204-7012 DFARS 252.204-7012 establishes the need to protect CUI by providing "adequate” protective measures that are commensurate with the consequences and probability of loss, misuse, or unauthorized access to, or modification of information. This DFARS clause requires compliance with NIST 800-171 on all “Covered Contractor Information Systems.”

Covered Contractor Information System (CCIS) means an unclassified information system that is owned, or operated by or for, a contractor and that processes, stores, or transmits “Covered Defense Information.”

Covered Defense Information (CDI) means unclassified "Controlled Technical Information" or other information, as described in the Controlled Unclassified Information (CUI) Registry.

Controlled Technical Information (CTI) means technical information with military or space application that is subject to controls on the access, use, reproduction, modification, performance, display, release, disclosure, or dissemination.

Examples of technical information include, but are not limited to:

Research and engineering data Engineering drawings Associated lists, specifications, standards, process sheets, manuals, technical reports, technical orders, catalog-item

identifications, data sets, studies and analyses and related information, and Computer software executable code and source code.


CONTROLLED UNCLASSIFIED INFORMATION (CUI) NIST 800-171 requires private companies to protect the confidentiality of CUI where it is stored, transmitted and/or processed. The CUI requirements within NIST 800-171 are directly linked to NIST 800-53 MODERATE baseline controls and are intended for use by federal agencies in contracts or other agreements established between those agencies and government/DoD contractors, as it applies to:

When CUI is resident in non-federal information systems and organizations; When information systems where CUI resides are not used or operated by contractors of federal agencies or other organizations

on behalf of those agencies; and Where there are no specific safeguarding requirements for protecting the confidentiality of CUI prescribed by the authorizing

law, regulation, or government-wide policy for the CUI category or subcategory listed in the CUI Registry.

CYBERSECURITY MATURITY MODEL CERTIFICATION (CMMC) For a more detailed explanation of CMMC, please visit: https://www.complianceforge.com/cybersecurity-maturity-model-certification-cmmc/ CMMC is a vehicle the US Government is using to implement a tiered approach to audit contractor compliance with NIST SP 800-171, based on five different levels of maturity expectations. DoD contractors have been required to comply with NIST 800-171 since January 1, 2018. In the past two years, the DoD grappled with the low rate of NIST 800-171 compliance across the Defense Industrial Base (DIB) and CMMC was created to remedy that systemic issue of non-compliance by both primes and their subs. Interestingly, when NIST 800-171 was initially launched, the DoD would not accept any form of 3rd-party audit for evidence of NIST 800-171 compliance, but that is exactly what CMMC does, so a lot has changed in the past two years from how NIST 800-171 adoption was initially envisioned. Think of CMMC as a procurement gate that a contractor must pass to even be eligible to bid on, win or participate on a contract - without a valid CMMC certification (Level 1 through 5), the prime and/or sub will be barred from the contract. It is conservatively-estimated that between 200,000-300,000 organizations will be in scope for CMMC, with many of those not being considered traditional defense contractors. The reason for that is the trickle-down effect of third-parties that have the ability to impact the confidentiality and/or integrity of Controlled Unclassified Information (CUI) where it is stored, transmitted and/or processed. This trickle-down will impact small organizations from IT support to bookkeepers and even janitorial support services, in addition to component manufacturers that fall in the supply chain. Based on version 1.0 of the CMMC, there are 5 levels and each has its own specific set of controls that will be in scope for a CMMC audit. Each level of CMMC maturity has increasing expectations:

CMMC Level 1: 17 Controls CMMC Level 2: 72 Controls (includes Level 1 controls) CMMC Level 3: 130 Controls (includes Level 2 controls) CMMC Level 4: 156 Controls (includes Level 3 controls) CMMC Level 5: 171 Controls (includes Level 4 controls)

https://www.complianceforge.com/cybersecurity-maturity-model-certification-cmmc/

https://www.complianceforge.com/cybersecurity-maturity-model-certification-cmmc/


SCOPING NIST 800-171 This guide provides a structured methodology for determining which systems, applications and services in a company’s IT infrastructure are within scope for NIST 800-171 compliance. This guide categorizes system components according to several factors:

Whether CUI 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 CUI environment.

This NIST 800-171 scoping guide can be used by both large and small companies to help critically evaluate the system components that comprise the scope of assessment. The primary difference between large and small companies will be the number of system components that are evaluated.

WHAT THIS GUIDE DOES ADDRESS Addressing the people, processes and technologies around CUI is a necessary part of any NIST 800-171 compliance 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 a CMMC assessor by providing a reasonable methodology

to describe your technology infrastructure and CUI 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 NIST 800-171 and CMMC by re-architecting technologies to isolate

and control access to the CUI environment.

WHAT THIS GUIDE DOES NOT ADDRESS This guide does not define what NIST 800-171 controls are required for each category. Since every company is different, it is up to each company and its assessor to determine the nature, extent and effectiveness of each control to adequately mitigate the risks to CUI. Additionally, NIST 800-171 identifies organization-level Non-Federal Organization (NFO) controls in Appendix E that organizations must evaluate for applicability.

SEGMENTATION CONSIDERATIONS It is important to understand that without adequate network segmentation (e.g., a flat network) the entire network is in scope of NIST 800-171 and a CMMC audit. Network segmentation should be viewed as a very beneficial process to isolate system components that store, process, or transmit CUI from systems that do not. Adequate network segmentation may reduce the scope of the CUI environment and overall reduce the scope of a NIST 800-171 audit. To eliminate ambiguity surrounding the term “segmentation” in terms of NIST 800-171 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.

o Controlled access is more common than isolation. o 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. Examples of mechanisms that provide controlled access include firewalls, routers, hypervisors, etc.


NIST 800-171 / CMMC DUE DILIGENCE & DUE CARE STEPS Before you can get any use from this guide, you need to do the following steps:

1. Document the System Security Plan (SSP) to clearly identify what makes up the CUI environment. This includes dataflows and all instances where CUI is stored, transmitted and processed.

2. Create a logical network diagram of your network(s), including any third-party services, cloud instances and remote access methods. Both a high-level and low-level diagram is expected:

o A high-level diagram can be “cartoonish” to depict broad concepts. o A low-level diagram needs to be detailed and identify the ports, protocols and services that are used across the CUI

environment. This information should match what exists in applicable Access Control Lists (ACLs). 3. Document an inventory of all systems, applications and services:

o Servers o Workstations o Network devices o Mobile devices o Databases o Third-party service providers o Cloud instances o Major applications (including what servers and databases they depend on)

Note: If you are not willing to do the work to do these three steps, you can stop reading this document and assume that every system, application and service in your organization will be considered in scope for NIST 800-171 and CMMC audits. The old adage of “if you fail to plan, you plan to fail” is very applicable in this scenario.


SCOPING CATEGORIES The CUI environment encompasses the systems, applications and services that store, process and transmits CUI.

Store – When CUI is inactive or at rest (e.g., located on electronic media, system component memory, paper) Process – When CUI is actively being used by a system component (e.g., entered, edited, manipulated, printed, viewed) Transmit – When CUI is being transferred from one location to another (e.g., data in motion).

There is no official guidance or methodology from NIST of the DoD on categorizing assets as being either in or out of the scope for NIST 800-171. Given that lack of guidance and a need for businesses to demonstrate both due care and due diligence with their NIST 800-171 compliance operations, this guide defines five (5) categories of system components and highlights the different types of risks associated with each category. This approach makes it more evident which system components are the most important to protect, based on the types of risk posed to CUI. CATEGORIZING ASSETS ACCORDING TO ACCESS When viewing NIST 800-171 scoping, there are five (5) categories of assets for CUI purposes.

1. Contaminated: The first category is systems, services and applications that clearly store, transmit and/or process CUI, CTI or CDI.

2. Segmenting: The second category is “segmenting systems” that provide access (e.g., firewall, hypervisors, etc.) 3. Security Tools: The third category are “security tools” that directly impact the integrity of category 1 and 2 assets (e.g., Active

Directory, centralized antimalware, vulnerability scanners, IPS/IDS, etc.). 4. Connected. The fourth category are connected systems. These are systems, applications or services that have some direct or

indirect connection into the CUI environment. Systems, applications and services that may impact the security of (for example, name resolution or web redirection servers) the CUI environment are always in scope. Essentially, it something can impact the security of the CUI, it is in scope.

5. Out-of-Scope. The fifth category are out-of-scope systems that are completely isolated from the CUI systems. For these, always remember that.


CATEGORY 1: CONTAMINATED All systems, applications and services that store, transmit or process CUI are Category 1 devices. These systems that come into contact with CUI are the main assets that NIST 800-171 is trying to protect.

CATEGORY 2: SEGMENTING All network devices or hypervisors that provide segmentation functions are Category 2 devices. This category involves systems that provide segmentation and prevent "CUI contamination" from the CUI environment to uncontrolled environments. Typically, these are network firewalls that implement some form of Access Control List (ACL) to restrict logical access into and out of the CUI environment.

Note: If network segmentation is in place and is being used to reduce the scope of NIST 800-171 and a CMMC audit, 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. These two NIST 800-171 controls address the concept of segmenting:

3.1.3 Control the flow of CUI in accordance with approved authorizations. 3.13.1 Monitor, control, and protect communications (e.g., information transmitted or received by organizational systems) at

the external boundaries and key internal boundaries of organizational systems.

CATEGORY 3: SECURITY TOOLS All systems that provide security-related services or IT-enabling services that may affect the security of the CUI 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: Identity and Directory Services (Active Directory, LDAP) Domain Name Systems (DNS) Network Time Systems (NTP) Patch management systems Vulnerability & patch management systems Anti-malware management systems File Integrity Management (FIM) systems Data Loss Prevention (DLP) systems Performance monitoring systems Cryptographic key management systems Remote-access or Virtual Private Network (VPN) systems Multi-factor Authentication (MFA) systems Mobile Device Management (MDM) systems Log management and Security Incident Event Management (SIEM) systems Intrusion Detection Systems/ Intrusion Prevention Systems (IDS/IPS)

CATEGORY 4: CONNECTED Any system that has some capability to communicate with systems, applications or services within the CUI environment is a Category 4 device. A “connected” system, application or service should be considered in scope for NIST 800-171 since it is not completely isolated. If it can potentially impact the security of the CUI, it is in scope for NIST 800-171.

There are two sub-categories of connected devices:

Directly Connected Indirectly Connected


4-A: DIRECTLY CONNECTED This sub-category addresses any system that is “connected to” the CUI environment is considered a directly-connected system. Any system outside of the CUI environment that is capable of communicating with a system that stores, transmits or processes CUI (e.g., asset within the CUI environment) is a Category 4-A device.

Note – For systems outside of the CUI environment that have periodic outbound connections from the CUI environment that do not involve the transfer of CUI 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 the CUI. 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. 4-B: INDIRECTLY CONNECTED

This sub-category addresses any system that does not have any direct access to CUI systems (e.g., isolated from the CUI environment). Any system that has access to Connected or Segmenting systems and that could affect the security of the CUI environment is a Category 4-B 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 CUI environment, therefore breaching the security controls applicable to the CUI environment.

CATEGORY 5: OUT-OF-SCOPE Any system, application or service that is not a CUI-contaminated, segmenting or connected system is a Category 5 asset. These assets are considered out-of-scope for NIST 800-171 compliance. These out-of-scope assets must be completely isolated (no connections whatsoever) from CUI 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:

1. System components do NOT store, process, or transmit CUI/CTI/CDI. 2. System components are NOT on the same network segment or in the same subnet or VLAN as systems, applications or processes

that store, process, or transmit CUI 3. System component cannot connect to or access any system in the CUI environment. 4. System component cannot gain access to the CUI environment, nor impact a security control for a system, application or service

in the CUI environment via an in-scope system.


IN-SCOPE MATRIX The following chart summarizes the concept of what is and is not in scope:

SYSTEM-TO-SYSTEM COMMUNICATIONS The following chart summarizes the concept of what communications are or are not in-scope for NIST 800-171.

Note – For systems outside of the CUI environment that have periodic outbound connections from the CUI environment that do not involve the transfer of CUI 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 the CUI. 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.


CUI SCOPING DECISION TREE The following decision tree provides a logical walk-through to determine if an asset is in scope or not:


APPENDIX A – DOCUMENTATION TO SUPPORT NIST 800-171 COMPLIANCE & CMMC The purpose of a company’s cybersecurity documentation is to prescribe a comprehensive framework for:

Creating a clearly articulated approach to how your company handles cybersecurity. Protecting the confidentiality, integrity, availability and safety of data and systems on your network. Providing guidance to help ensure the effectiveness of security controls that are put in place to support your company’s

operations. Helping your users to recognize the highly-networked nature of the current computing environment to provide effective

company-wide management and oversight of those related cybersecurity risks. Documentation works best when it is simple and concise. Conversely, documentation fails when it is overly wordy, complex or difficult for users to find the information they are seeking. When you picture this from a hierarchical perspective, everything builds off of the policy and all of the components of cybersecurity documentation build off each other to make a cohesive approach to addressing a requirement:

CYBERSECURITY DOCUMENTATION COMPONENTS Cybersecurity documentation is comprised of six (6) main parts:

(1) Core policy that establishes management’s intent; (2) Control objective that identifies leading practices; (3) Standards that provides quantifiable requirements; (4) Controls identify desired conditions that are expected to be met; (5) Procedures / Control Activities establish how tasks are performed to meet the requirements established in standards and to

meet controls; and (6) Guidelines are recommended, but not mandatory.

Note - From a framework perspective, NIST 800-171 is more closely aligned with NIST 800-53 than others. This falls in more of a “moderate” category for cybersecurity controls, which would be reasonably-expected in nearly any industry.


NIST 800-171 IN A NUTSHELL When you break down NIST 800-171 CUI requirements into how they are operationalized by people, processes or technology, you see that there are a lot of controls that are either administrative or related to technical configurations. Very few realistically require the purchase of new hardware or software to meet these compliance requirements, so NIST 800-171 accomplished through improving processes and configuring existing technologies to meet compliance requirements.

NIST 800-171 SPECIFIC DOCUMENTATION When you look at NIST 800-171, it contains mappings to both NIST 800-53 and ISO 27002. Only NIST 800-53 controls provide complete mapping to the NIST 800-171 CUI and NFO controls, so NIST 800-53 should serve as the aligned framework when building your organization’s cybersecurity documentation. The NIST Cybersecurity Framework would be considered to lightweight to address NIST 800-171 compliance obligations.


CYBERSECURITY DOCUMENTATION HIERARCHY – UNDERSTANDING HOW CYBERSECURITY DOCUMENTATION IS CONNECTED It all starts with influencers – these influencers set the tone and establish what is considered to be due care for information security operations. For external influencers, this includes statutory requirements (laws), regulatory requirements (government regulations) and contractual requirements (legally-binding agreements) that companies must address. For internal influencers, these are business-driven and the focus is more on management’s desire for consistent, efficient and effective operations. When that is all laid out properly, your company’s cybersecurity documentation show flow like this where your policies are linked all the way down to metrics: http://examples.complianceforge.com/ComplianceForge%20Hierarchical%20Cybersecurity%20Governance%20Framework.pdf

ComplianceForge sells several different options for NIST 800-171 compliance documentation, based on your needs:

NIST 800-171 Compliance Program (NCP) – designed for smaller organizations; Written Information Security Program (WISP) – designed for organizations that want to closely align with NIST 800-53; and Digital Security Program (DSP) – enterprise solution for organizations that need to comply with a wide variety of requirements.

http://examples.complianceforge.com/ComplianceForge%20Hierarchical%20Cybersecurity%20Governance%20Framework.pdf

https://www.complianceforge.com/product/nist-800-171-compliance-program/

https://www.complianceforge.com/product/nist-800-53-based-security-documentation-wisp/

https://www.complianceforge.com/product/comprehensive-digital-security-program/

http://examples.complianceforge.com/ComplianceForge%20Hierarchical%20Cybersecurity%20Governance%20Framework.pdf

https://www.complianceforge.com/nist-800-171-compliance-bundles/


EXAMPLE NIST 800-171 CYBERSECURITY DOCUMENTATION Complying with the requirements from DFARS goes beyond just having policies and standards. When you break down the requirements to comply with NIST 800-171, you see how ComplianceForge's products address a specific DFARS/NIST 800-171 compliance need. In the chart, "NFO" stands for Non-Federal Organization. NFO controls are required for contractors and are called out in Appendix E of NIST 800-171. Below are examples of how a cybersecurity documentation should look for NIST 800-171 compliance:

ComplianceForge Product DFARS Requirement Written Information Security Program (WISP); NIST 800-171 Compliance Program (NCP) or Digital Security Program (DSP) [addresses high-level policies & standards]

252.204-7008 252.204-7012

NIST 800-171 (multiple NFO controls)

Cybersecurity Standardized Operating Procedures (CSOP)

252.204-7008 252.204-7012

NIST 800-171 (multiple NFO controls)

Vendor Compliance Program (VCP)

252.204-7008 252.204-7012

NIST 800-171 NFO PS-7

Cybersecurity Risk Management Program (RMP)

252.204-7008 252.204-7012

NIST 800-171 NFO RA-1

Cybersecurity Risk Assessment Template (CRA)

252.204-7008 252.204-7012

NIST 800-171 3.11.1

Vulnerability & Patch Management Program (VPMP)

252.204-7008 252.204-7012

NIST 800-171 3.11.2

Integrated Incident Response Program (IIRP)

252.204-7008 252.204-7009 252.204-7010 252.204-7012

NIST 800-171 3.6.1

Security & Privacy By Design (SPBD)

252.204-7008 252.204-7012

NIST 800-171 NFO SA-3

System Security Plan (SSP)

252.204-7008 252.204-7012

NIST 800-171 3.12.4

Continuity of Operations Plan (COOP)

252.204-7008 252.204-7012

NIST 800-171 3.6.1

Secure Baseline Configurations (SBC)

252.204-7008 252.204-7012

NIST 800-171 3.4.1

Control Validation Testing (CVT)

252.204-7008 252.204-7012

NIST 800-171 NFO CA-1

Cybersecurity Business Plan (CBP) CMMC CA.4.163

https://www.complianceforge.com/product/nist-800-53-based-security-documentation-wisp/

https://www.complianceforge.com/product/nist-800-171-compliance-program/

https://www.complianceforge.com/product/comprehensive-digital-security-program/

https://www.complianceforge.com/product/iso-27002-nist-800-53-nist-csf-procedures-csop/

https://www.complianceforge.com/product/it-security-vendor-compliance-program/

https://www.complianceforge.com/product/cybersecurity-risk-management-program-rmp/

https://www.complianceforge.com/product/cybersecurity-information-security-risk-assessment-template/

https://www.complianceforge.com/product/vulnerability-patch-management-program-vpmp/

https://www.complianceforge.com/product/cybersecurity-incident-response-program-cirp/

https://www.complianceforge.com/product/security-by-design-privacy-by-design/

https://www.complianceforge.com/product/nist-800-171-system-security-plan-ssp-poam-template/

https://www.complianceforge.com/product/continuity-of-operations-plan/

https://www.complianceforge.com/product/secure-baseline-configuration-sbc

https://www.complianceforge.com/product/control-validation-testing-information-assurance-template

https://www.complianceforge.com/product/cybersecurity-business-plan-CA_4_163/


APPENDIX B – UTILIZING SP-CMM TO IDENTIFY A CAPABILITY MATURITY “SWEET SPOT” The Security & Privacy Capability Maturity Model (SP-CMM) from the Secure Controls Framework (SCF) draws upon the high-level structure of the Systems Security Engineering Capability Maturity Model v2.0 (SSE-CMM), since we felt it was the best model to demonstrate varying levels of maturity for people, processes and technology at a control level. If you are unfamiliar with the SSE-CMM, it is well-worth your time to read through the SSE-CMM Model Description Document that is hosted by the US Defense Technical Information Center (DTIC). For most organizations, the “sweet spot” for maturity targets is between CMM 2 and 4 levels. What defines the ideal target within this zone is generally based on resource limitations and other business constraints, so it goes beyond just the cybersecurity and privacy teams dictating targets. Identifying maturity targets is meant to be a team effort between both technologists and business stakeholders. From a business consideration, the increase in cost and complexity will always require cybersecurity and privacy leadership to provide a compelling business case to support any maturity planning needs. Speaking in terms the business can understand is vitally important.

NEGLIGENCE CONSIDERATIONS Without the ability to demonstrate evidence of both due care and due diligence, an organization may be found negligent. In practical terms, the “negligence threshold” is between CMM 1 and CMM 2. The reason for this is at CMM 2, practices are formalized to the point that documented evidence exists to demonstrate reasonable steps were taken to operate a control.

RISK CONSIDERATIONS Risk associated with the control in question decreases with maturity, but noticeable risk reductions are harder to attain above CMM 3. Oversight and process automation can decrease risk, but generally not as noticeably as steps taken to attain CMM 3.

PROCESS REVIEW LAG CONSIDERATIONS Process improvements increase with maturity, based on shorter review cycles and increased process oversight. What might have been an annual review cycle to evaluate and tweak a process can be near real-time with Artificial Intelligence (AI) and Machine Learning (ML).

STAKEHOLDER VALUE CONSIDERATIONS The perceived value of security controls increases with maturity. However, perceived value tends to decrease after CMM 3 since the value of the additional cost and complexity becomes harder to justify to business stakeholders. Companies that are genuinely focused on being industry leaders are ideal candidates for CMM 5 targets to support their aggressive business model needs.

https://www.securecontrolsframework.com/sp-cmm

https://www.securecontrolsframework.com/

https://apps.dtic.mil/dtic/tr/fulltext/u2/a393329.pdf


The six SP-CMM levels are:

CMM 0 – Not Performed CMM 1 – Performed Informally CMM 2 – Planned & Tracked CMM 3 – Well-Defined CMM 4 – Quantitatively Controlled CMM 5 – Continuously Improving

CMM 0 – NOT PERFORMED This level of maturity is defined as “non-existence practices,” where the control is not being performed.

There are no identifiable work products of the process. CMM 0 practices, or a lack thereof, are generally considered to be negligent. The reason for this is if a control is reasonably-expected to exist, by not performing the control that would be negligent behavior. The need for the control could be due to a law, regulation or contractual obligation (e.g., client contract or industry association requirement).

CMM 1 – PERFORMED INFORMALLY This level of maturity is defined as “ad hoc practices,” where the control is being performed, but lacks completeness & consistency.

Base practices of the process area are generally performed. The performance of these base practices may not be rigorously planned and tracked. Performance depends on individual knowledge and effort. There are identifiable work products for the process.

CMM 1 practices are generally considered to be negligent. The reason for this is if a control is reasonably-expected to exist, by only implementing ad-hoc practices in performing the control that could be considered negligent behavior. The need for the control could be due to a law, regulation or contractual obligation (e.g., client contract or industry association requirement). Note – The reality with a CMM 1 level of maturity is often:

For smaller organizations, the IT support role only focuses on “break / fix” work or the outsourced IT provider has a limited scope in its support contract.

For medium / large organizations, there is IT staff but there is no management focus to spend time on the control.


CMM 2 – PLANNED & TRACKED This level of maturity is defined as “requirements-driven practices,” where the expectations for controls are known (e.g., statutory, regulatory or contractual compliance obligations) and practices are tailored to meet those specific requirements.

Performance of the base practices in the process area is planned and tracked. Performance according to specified procedures is verified. Work products conform to specified standards and requirements.

CMM 2 practices are generally considered to be “audit ready” with an acceptable level of evidence to demonstrate due diligence and due care in the execution of the control. CMM 2 practices are generally targeted on specific systems, networks, applications or processes that require the control to be performed for a compliance need (e.g., PCI DSS, HIPAA, NIST 800-171, etc.). It can be argued that CMM 2 practices focus more on compliance over security. The reason for this is the scoping of CMM 2 practices are narrowly-focused and are not organization-wide. Note – The reality with a CMM 2 level of maturity is often:

For smaller organizations: o IT staff have clear requirements to meet applicable compliance obligations or the outsourced IT provider is properly

scoped in its support contract to address applicable compliance obligations. o It is unlikely that there is a dedicated cybersecurity role and at best it is an additional duty for existing personnel.

For medium / large organizations: o IT staff have clear requirements to meet applicable compliance obligations. o There is most likely a dedicated cybersecurity role or a small cybersecurity team.

CMM 3 – WELL-DEFINED This level of maturity is defined as “enterprise-wide standardization,” where the practices are well-defined and standardized across the organization.

Base practices are performed according to a well-defined process using approved, tailored versions of standard, documented processes.

Process is planned and managed using an organization-wide, standardized process. CMM 3 practices are generally considered to be “audit ready” with an acceptable level of evidence to demonstrate due diligence and due care in the execution of the control. Unlike CMM 2 practices that are narrowly focused, CMM 3 practices are standardized across the organization. It can be argued that CMM 3 practices focus on security over compliance, where compliance is a natural byproduct of those secure practices. These are well-defined and properly-scoped practices that span the organization, regardless of the department or geographic considerations. Note – The reality with a CMM 3 level of maturity is often:

For smaller organizations: o There is a small IT staff that has clear requirements to meet applicable compliance obligations. o There is a very competent leader (e.g., security manager / director) with solid cybersecurity experience who has the

authority to direct resources to enact secure practices across the organization. For medium / large organizations:

o IT staff have clear requirements to implement standardized cybersecurity & privacy principles across the enterprise. o In addition to the existence of a dedicated cybersecurity team, there are specialists (e.g., engineers, SOC analysts, GRC,

privacy, etc.) o There is a very competent leader (e.g., CISO) with solid cybersecurity experience who has the authority to direct

resources to enact secure practices across the organization.


CMM 4 – QUANTITATIVELY CONTROLLED This level of maturity is defined as “metrics-driven practices,” where in addition to being well-defined and standardized practices across the organization, there are detailed metrics to enable governance oversight.

Detailed measures of performance are collected and analyzed. This leads to a quantitative understanding of process capability and an improved ability to predict performance.

Performance is objectively managed, and the quality of work products is quantitatively known. CMM 4 practices are generally considered to be “audit ready” with an acceptable level of evidence to demonstrate due diligence and due care in the execution of the control, as well as detailed metrics enable an objective oversight function. Metrics may be daily, weekly, monthly, quarterly, etc. Note – The reality with a CMM 4 level of maturity is often:

For smaller organizations, it is unrealistic to attain this level of maturity. For medium / large organizations:



resources to enact secure practices across the organization. o Business stakeholders are made aware of the status of the cybersecurity and privacy program (e.g., quarterly business

reviews to the CIO/CEO/board of directors). This situational awareness is made possible through detailed metrics.

CMM 5 – CONTINUOUSLY IMPROVING This level of maturity is defined as “world-class practices,” where the practices are not only well-defined and standardized across the organization, as well as having detailed metrics, but the process is continuously improving.

Quantitative performance goals (targets) for process effectiveness and efficiency are established, based on the business goals of the organization.

Continuous process improvement against these goals is enabled by quantitative feedback from performing the defined processes and from piloting innovative ideas and technologies.

CMM 5 practices are generally considered to be “audit ready” with an acceptable level of evidence to demonstrate due diligence and due care in the execution of the control and incorporates a capability to continuously improve the process. Interestingly, this is where Artificial Intelligence (AI) and Machine Learning (ML) would exist, since AI/ML would focus on evaluating performance and making continuous adjustments to improve the process. However, AI/ML are not requirements to be CMM 5. Note – The reality with a CMM 5 level of maturity is often:

For smaller organizations, it is unrealistic to attain this level of maturity. For medium-sized organizations, it is unrealistic to attain this level of maturity. For large organizations:



resources to enact secure practices across the organization. o Business stakeholders are made aware of the status of the cybersecurity and privacy program (e.g., quarterly business

reviews to the CIO/CEO/board of directors). This situational awareness is made possible through detailed metrics. o The organization has a very aggressive business model that requires not only IT, but its cybersecurity and privacy

practices, to be innovative to the point of leading the industry in how its products and services are designed, built or delivered.

o The organization invests heavily into developing AI/ML technologies to made near real-time process improvements to support the goal of being an industry leader.


EXAMPLE CMM REPORTING From an organization-wide perspective, it is possible to use the SP-CMM to report maturity across multiple domains as a way to gauge an organization’s overall maturity, as well as the maturity of each function within its cybersecurity and privacy program. With the coming of the DoD’s Capability Maturity Model Certification (CMMC) process, understanding your organization’s maturity is going to be critical to obtaining and maintaining a US government contract.

nist 800-171 & cmmc compliance scoping guideexamples.complianceforge.com/nist-800-171/nist...

Documents