CMMC Kill Chain - A Prioritized Approach

The concept of creating a “Kill Chain” was to create a proof of concept for an efficient way to plan out a roadmap to successfully pass a NIST 800-171 / CMMC assessment. The end result is a viable approach for anyone to use in order to create a prioritized project plan for NIST 800-171 / CMMC pre-assessment activities.

The concept of a kill chain is simply that it is easier to stop and prevent further damage if those malicious activities are discovered earlier, rather than later. When you look at NIST 800-171 / CMMC's zero tolerance for deficiencies, if you have a single deficiency in a process or practice, you will fail your NIST 800-171 / CMMC assessment. Given that reality, the intention of using the NIST 800-171 & CMMC Kill Chain is that if you apply a prioritized, phased approach towards pre-assessment activities, it is possible to avoid rework and cascading failures by addressing dependencies earlier in the process. The bottom line is this model breaks down NIST 800-171 / CMMC in major steps, which can then be translated into a project plan.

Key Takeaways - CMMC Kill Chain - A Prioritized Approach

The Kill Chain is a prioritized, phased project plan for NIST 800-171 / CMMC pre-assessment activities. Available in both R3 (22 phases) and R2/CMMC 2.0 (23 phases) versions.
CMMC has zero tolerance for deficiencies. A single failure means you fail the assessment. The Kill Chain addresses dependencies early to prevent cascading rework.
The model frontloads governance (context, policies, scoping, risk management) before moving to technical controls, because governance mistakes are the most expensive to fix later.
Key dependency logic: risk management before change management, logging infrastructure before secure configurations, secure configs before IAM, maintenance before vulnerability management.
Internal audit comes last. It serves as a pre-assessment function to validate how well controls are implemented.

Why A Kill Chain?

A Prioritized Approach to NIST 800-171 & CMMC

This project was approached from the perspective of, “If I was hired at a company, what would my plan be to start from nothing to get a company to where it could pass an assessment?” All of the NIST 800-171 / CMMC controls are addressed within the NIST 800-171 & CMMC Kill Chain, but it is clear that the prioritization and “bucketing” of practices into phases is a subjective endeavor and not everyone may agree with this approach. Just understand that every organization is different and you will invariably need to modify the approach to fit your specific needs.

Two Versions Available

NIST 800-171 R3; and
CMMC 2.0 / NIST 800-171 R2.

NIST 800-171 Rev 3 Kill Chain Phases

Prioritized Steps To Implement NIST SP 800-171 Rev 3

Based on the NIST 800-171 R3 Kill Chain, there are twenty-two (22) prioritized phases an organization should take to implement NIST 800-171 Rev 3. It is important to note that this transition plan to NIST 800-171 Rev 3 frontloads a lot of cybersecurity governance processes, since those governance practices will help prevent controls from being reworked:

Step 1

ESTABLISH CONTEXT FOR CYBERSECURITY & DATA PROTECTION

This phase has four (4) sub-components:

Define the organization's applicable statutory, regulatory and contractual obligations for cybersecurity and data protection (e.g., DFARS, FAR, ITAR, etc.).
Define what Controlled Unclassified Information (CUI) and/or Federal Contract Information (FCI) is for your specific business case (based on the contract).
Identify the necessary People, Processes, Technology, Data & Facilities (PPTDF) that are necessary and appropriately sized.
Develop & implement a resource plan (e.g., business plan, budget, road map, etc.) to meet the organization's unique compliance obligations.

Step 2

IMPLEMENT GOVERNANCE PRACTICES

This phase has two (2) sub-components:

Develop, implement and maintain policies and standards to address applicable statutory, regulatory and contractual obligations.
Prioritize objectives from the resource plan for People, Processes, Technology, Data & Facilities (PPTDF) requirements.

Step 3

ESTABLISH THE COMPLIANCE SCOPE

This phase has five (5) sub-components:

Create a Data Flow Diagram (DFD) that shows how CUI flows from the DoD all the way down to subcontractors.
Create and maintain a detailed asset inventory for all systems, applications and services for both in-scope and out-of-scope assets.
Create a detailed network diagram that includes where CUI is stored, transmitted and/or processed.
Inventory External Service Providers (ESP) to determine ESP access to CUI and/or in-scope systems, applications and/or services.
Define roles and responsibilities for internal and external systems, applications and services.

Step 4

RISK MANAGEMENT PRACTICES

This phase has five (5) sub-components:

Develop & implement an organization-wide Risk Management Program (RMP) to identify, assess and remediate risk. POA&M deficiencies to prioritize, resource and remediate.
Document and maintain a Cybersecurity Supply Chain Risk Management (C-SCRM) Plan that is specific to the CUI environment.
Develop and implement acquisition strategies, contract tools, and procurement methods to operationalize the C-SCRM Plan
Enforce C-SCRM requirements across the supply chain.
Establish a process for identifying and addressing weaknesses or deficiencies in the supply chain elements and processes.

Step 5

DOCUMENT THE CUI AND/OR FCI ENVIRONMENT

This phase has three (3) sub-components:

Start populating the System Security Plan (SSP). POA&M deficiencies to prioritize, resource and remediate.
Create and maintain a Plan of Action & Milestone (POA&M) to track and remediate deficiencies.
Perform a gap assessment from applicable statutory, regulatory and contractual obligations. POA&M deficiencies to prioritize, resource and remediate.

Step 6

IDENTIFY COMPLIANCE STAKEHOLDERS

This has two subcomponent steps:

Identify compliance stakeholders (including control owners and control operators) and formally assign those individuals roles and responsibilities. From a governance perspective, this can be simplified in a Responsible, Accountable, Supporting, Consulted and Informed (RASCI) matrix.
Work with Human Resources (HR) to ensure personnel security requirements are integrated into HR operations. POA&M deficiencies to prioritize, resource and remediate.
Define and implement processes to securely handle CUI wherever CUI is stored, processed and/or transmitted
Ensure control owners / operators develop, implement and maintain procedures to operationalize the organization's policies & standards.
POA&M deficiencies to prioritize, resource and remediate.

Step 7

DATA PROTECTION PRACTICES

This involves developing and implementing data protection practices to limit logical and physical access to CUI and/or FCI. POA&M deficiencies to prioritize, resource and remediate.

Step 8

SEGMENTED NETWORK ARCHITECTURE

This involves implementing a network architecture that ensures it is built on secure engineering principles and enclaves to protect sensitive information (e.g., FCI/CUI). POA&M deficiencies to prioritize, resource and remediate.

Step 9

CHANGE MANAGEMENT (CM)

This involves developing and implementing Change Management (CM) practices, including a Change Control Board (CCB). POA&M deficiencies to prioritize, resource and remediate.

Step 10

INCIDENT RESPONSE (IR)

This involves developing and implementing Incident Response (IR) capabilities to detect, respond and recover from incidents (e.g., Incident Response Plan (IRP)). POA&M deficiencies to prioritize, resource and remediate.

Step 11

SITUATIONAL AWARENESS (SA)

This involves developing and implementing Situational Awareness (SA) capabilities through threat intelligence, log collection and analysis (e.g., SIEM, XDR, etc.). POA&M deficiencies to prioritize, resource and remediate.

Step 12

SECURE BASELINE CONFIGURATIONS (SBC)

This involves developing and implementing Secure Baseline Configurations (SBC) (e.g., hardening standards) for all technology platforms (e.g., servers, workstations, network gear, applications, databases, etc.). POA&M deficiencies to prioritize, resource and remediate.

Step 13

IDENTITY & ACCESS MANAGEMENT (IAM)

This involves developing and implementing Identity & Access Management (IAM) capabilities to address "least privilege" and Role-Based Access Control (RBAC). POA&M deficiencies to prioritize, resource and remediate.

Step 14

PROACTIVE MAINTENANCE

This involves developing and implementing proactive maintenance practices. POA&M deficiencies to prioritize, resource and remediate.

Step 15

ATTACK SURFACE MANAGEMENT (ASM)

This involves developing and implementing Attack Surface Management (ASM) practices to identify and remediate vulnerabilities. POA&M deficiencies to prioritize, resource and remediate.

Step 16

IT ASSET MANAGEMENT (ITAM)

This involves developing and implementing IT Technology Asset Management (ITAM) practices. POA&M deficiencies to prioritize, resource and remediate.

Step 17

LAYERED NETWORK DEFENSES

This involves developing and implementing layered network security for Defense-in-Depth (DiD) practices. POA&M deficiencies to prioritize, resource and remediate.

Step 18

BUSINESS CONTINUITY & DISASTER RECOVERY (BC/DR)

This involves developing and implementing Business Continuity / Disaster Recovery (BC/DR) capabilities. POA&M deficiencies to prioritize, resource and remediate.

Step 19

CRYPTOGRAPHIC KEY MANAGEMENT

This involves developing and implementing cryptographic key management and data encryption capabilities. POA&M deficiencies to prioritize, resource and remediate.

Step 20

PHYSICAL SECURITY

This involves developing and implementing physical security practices. POA&M deficiencies & document procedures.

Step 21

SECURITY AWARENESS TRAINING

This involves developing and implementing training & awareness to ensure a security-minded workforce. POA&M deficiencies & document procedures. POA&M deficiencies to prioritize, resource and remediate.

Step 22

INTERNAL AUDIT (IA)

This involves developing and implementing an "internal audit" or Information Assurance (IA) capability to govern controls. POA&M deficiencies & document procedures. POA&M deficiencies to prioritize, resource and remediate.

NIST 800-171 Rev 3 Kill Chain Background

Background On The Logic Used In The NIST 800-171 R3 Kill Chain Model

Here is a quick explanation on some of the reasoning used for this version of the Kill Chain model:

If you fail to establish context (e.g., facts & assumptions), your entire premise for compliance operations may be incorrect and that could lead you down the wrong path. From a due diligence perspective, establishing context for cybersecurity and data protection should be a holistic endeavor to define all applicable laws, regulations and contractual obligations for cybersecurity and data protection. This enables your organization to implement proper governance practices (e.g., scope of compliance, stakeholders, supply chain protections, etc.).

You can't legitimately assess changes, vulnerabilities, threats, etc. without first having a handle on risk management and a defined risk threshold. Risk management is the key building block that other practices rely upon.

Once you have solid risk management practices, it is necessary to have Change Management (CM) matured to a state where it supports IT and business processes. CM is needed to legitimately alter other practices and you need to be able to document your changes and track open issues in a POA&M (e.g., evidence of due care).

Developing and implementing organization-wide data protection practices are crucial to limit logical and physical access to sensitive/regulated data (e.g., FCI, CUI, etc.). Technology is meant to follow practice, not the other way around where practices are modified to fit technology limitations. This means that technology should enable business practices to make the business more efficient, instead of technology solutions being implemented that hinder business practices.

With the understanding of how business practices are meant to be supported, it should be possible to implement a segmented network architecture that can minimize the scope of compliance, while also supporting secure business practices.

From there, the assumption is that you will discover issues so incident response capability needs to exist.

Situational awareness (e.g., event logging, centralized/automated log review, etc.) s next and needs to exist before secure configurations, since logs need to get sent somewhere. You need to have this logging infrastructure in place before you get into secure configurations.

Secure configurations and centralized management (e.g., STIGs, group policies, etc.) almost go hand-in-hand, but before you can centrally manage configurations, they need to be defined and standardized.

Next, identity and access management needs to be locked down to ensure aspects of least privilege and Role Based Access Control (RBAC) are implemented. The reason IAM comes after secure configurations is due to troubleshooting - if you have "gold standard" secure builds to work from, it is easier to then assign permissions that will work with those builds. The alternative is your new configs break your IAM/RBAC, which is bad. Avoid that.

You realistically can’t do vulnerability management without first having solid maintenance capabilities, so maintenance needs to be formalized with change control integrations. Maintenance needs to be tied into change management, which has a risk management component to it.

The concept of vulnerability management is broad and is best summed up by the term “attack surface management” where you are doing what you can to minimize the ways an adversary can attack. This relies on maintenance practices and change management being in place and operating.

From there, the remaining phases are relatively subjective - it really is. However, the “internal audit” function realistically needs to come last where control validation testing assesses how well controls are implemented. This can help serve as a pre-audit function.

NIST 800-171 Rev 2 Kill Chain Phases

Prioritized Steps To Implement NIST SP 800-171 Rev 2

The CMMC 2.0 & NIST 800-171 R2 version of the CMMC Kill Chain introduces the theory of constraints as it applies to your technical and business limitations. Here is information on the 23 phases of the NIST 800-171 R2 / CMMC Kill Chain (these correspond to the picture diagram):

Step 1

Define What CUI Is For Your Specific Business Case

This should be self-explanatory and is based on your contract(s).

Step 2

Establish The Scope of The CMMC Assessment Boundary

This has four subcomponent steps:

Create a Data Flow Diagram (DFD) that shows how CUI flows from the DoD all the way down to subcontractors;
Create a detailed asset inventory for all systems, applications and services for both in-scope and out-of-scope assets;
Create a detailed network diagram that includes where CUI is stored, transmitted and/or processed; and
Inventory Third-Party Service Providers (TSP) to determine TSP access to CUI and/or in-scope systems, applications and/or services.

Step 3

Document The Environment

This has two subcomponent steps:

Start populating the System Security Plan (SSP); and
Create a Plan of Action & Milestone (POA&M) to track and remediate deficiencies.

Step 4

Define The Network Architecture

Step 5

Plan, Identify Gaps & Prioritize Resources

This has six subcomponent steps:

Define applicable statutory, regulatory and contractual obligations (including DFARS, FAR, NIST 800-171 and CMMC);
Perform a gap assessment from applicable statutory, regulatory and contractual obligations;
Develop & implement policies and standards to address applicable statutory, regulatory and contractual obligations;
Identify the necessary People, Processes & Technology (PPT) that are necessary and appropriately sized;
Develop & implement a resource plan (e.g., business plan, budget, road map, etc.) to meet compliance obligations; and
Prioritize objectives from the resource plan for PPT requirements. POA&M any deficiencies from this phase.

Step 6

Develop Procedures

This has two subcomponent steps:

Develop & implement procedures to implement policies & standards; and
Define processes to securely handle CUI. POA&M any deficiencies from this phase.

Step 7

Risk Management

Develop & implement a Risk Management Program (RMP) to identify, assess and remediate risk. POA&M deficiencies & document procedures.

Step 8

Change Control

Develop & implement change control processes, including a Change Control Board (CCB). POA&M deficiencies & document procedures.

Step 9

Incident Response

Develop & implement incident response capabilities to detect, respond and recover from incidents. POA&M deficiencies & document procedures.

Step 10

Situational Awareness

Develop & implement situational awareness capabilities through log collection and analysis (e.g., SIEM). POA&M deficiencies & document procedures.

Step 11

System Hardening

Identify, build & implement secure baseline configurations (e.g., hardening standards) for all technology platforms. POA&M deficiencies & document procedures.

Step 12

Centralized Management

Build & implement Group Policy Objects (GPOs) for Microsoft Active Directory (AD). POA&M deficiencies & document procedures.

Step 13

Identity & Access Management

Develop & implement Identity & Access Management (IAM) to address "least privilege" and Role-Based Access Control (RBAC). POA&M deficiencies & document procedures.

Step 14

Maintenance

Develop & implement proactive maintenance practices. POA&M deficiencies & document procedures.

Step 15

Attack Surface Management / Vulnerability Management

Develop & implement Attack Surface Management (ASM) practices. POA&M deficiencies & document procedures.

Step 16

Asset Management

Develop & implement technology asset management practices. POA&M deficiencies & document procedures.

Step 17

Personnel Security

Work with Human Resources (HR) to ensure personnel security requirements are integrated into HR operations. POA&M deficiencies & document procedures.

Step 18

Network Security

Develop & implement network security practices. POA&M deficiencies & document procedures.

Step 19

Business Continuity

Develop & implement business continuity capabilities. POA&M deficiencies & document procedures.

Step 20

Cryptography

Develop & implement cryptographic key management and data encryption capabilities. POA&M deficiencies & document procedures.

Step 21

Physical Security

Develop & implement physical security practices. POA&M deficiencies & document procedures.

Step 22

Security Awareness Training

Build and maintain a security-minded workforce through training & awareness. POA&M deficiencies & document procedures.

Step 23

Internal Audit

Build and maintain an "internal audit" or Information Assurance (IA) capability to govern controls. POA&M deficiencies & document procedures.

NIST 800-171 Rev 2 Kill Chain Background

Background On The Logic Used In The NIST 800-171 R2 / CMMC 2.0 Kill Chain Model

Here is a quick explanation on some of the reasoning used for this version of the Kill Chain model:

Once you have solid risk management practices, change control is the second most important phase to address, since that is needed to legitimately alter other practices and you need to be able to document your changes and track open issues in a POA&M (e.g., evidence of due care).

From there, the assumption is that you will discover issues so incident response capability needs to exist (note - DFARS incident reporting requirements already apply if you currently store, process and/or transmit CUI as part of a DoD contract).

Event logging/SIEM is next and needs to exist before secure configurations, since logs need to get sent somewhere. You need to have this logging infrastructure in place before you get into secure configurations.

Secure configurations and centralized management (e.g., GPOs) almost go hand-in-hand, but before you can centrally manage configurations, they need to be defined and standardized.

Next, identity and access management needs to be locked down to ensure aspects of least privilege and RBAC are implemented. The reason IAM comes after secure configurations is due to troubleshooting - if you have "gold standard" secure builds to work from, it is easier to then assign permissions/RBAC that will work with those builds. The alternative is your new configs break your IAM/RBAC, which is bad. Avoid that.