NIST 800-171 R3 Kill Chain: A Phased Approach

Special thanks to the following contributors: Tom Cornelius Ryan B. Tim Trickett Mark Allers

There is an abundance of "What is NIST 800-171?" guidance on LinkedIn, webinars and on the Internet in general, but there is a lack of practical guidance of HOW you are actually supposed to "do NIST 800-171" in realistic terms. The NIST 800-171 R3 Kill Chain is designed to provide a roadmap that would be usable for (1) anyone starting out or (2) anyone wanting to double check their approach.

The concept of creating a “NIST 800-171 R3 Kill Chain” is to provide an efficient way to plan out a roadmap to successfully demonstrate compliance with NIST 800-171 R3. The result is a viable approach for anyone to use in order to create a prioritized project plan for NIST 800-171 R3 control implementation.

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 a NIST 800-171 R3 assessment?

Kill Chain Premise

Why “NIST 800-171 R3 Kill Chain” you ask? 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 how the DoD’s Cybersecurity Maturity Model Certification (CMMC) has zero tolerance for deficiencies, if you have a single deficiency in a process or practice, you will fail your CMMC assessment. Given that reality with CMMC, the intention of using the NIST 800-171 R3 Kill Chain is that if you apply a prioritized, phased approach towards CMMC-related 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 R3 control implementation into 22 major steps, which can then be translated into a viable project plan.

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 a NIST 800-171 R3 assessment?” All NIST 800-171 R3 controls are addressed within the NIST 800-171 R3 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. The result is a prioritized, phase-based approach to NIST 800-171 R3 control implementation.

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

Here is a quick explanation on some of the reasoning used for this 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.

Download The NIST 800-171 Kill Chain

There are twenty-two (22) phases of the NIST 800-171 R3 Kill Chain, some with sub-components. These map to all NIST 800-171 R3 controls.

You can download the complete NIST 800-171 R3 Kill Chain directly from: https://content.complianceforge.com/NIST-800-171-R3-Kill-Chain.pdf

Theory of Constraints (TOC)

The premise of the NIST 800-171 R3 Kill Chain is to build a viable project plan from the perspective of a prioritized listing of tasks in order to successfully prepare for and pass a NIST 800-171 R3 controls assessment. This helps establish your Critical Resources & Acquisition Path (CRAP), since errors or misguided adventures with people, processes and technology earlier in NIST 800-171 R3 control implementation activities will have cascading effects, so the NIST 800-171 R3 Kill Chain is meant to provide a model for prioritizing NIST 800-171-related pre-assessment activities.

The NIST 800-171 R3 Kill Chain breaks down NIST 800-171 R3 control implementation into 22 major steps, which can then be translated into a viable project plan.

Managing Your Critical Resources & Acquisition Path (CRAP)

As with any process, an organization’s CMMC compliance program is always vulnerable due to the ability of the “weakest link” (e.g., person, part, supplier and/or process) to cause damage and adversely affect the overall CMMC compliance program.

?The Theory of Constraints (TOC) is a management paradigm that views any manageable system as being limited in achieving more of its goals by a very small number of constraints. There is always at least one constraint in a project/initiative and TOC utilizes a process to identify the constraint(s) and restructure the rest of the organization/processes around it.

At the management level, TOC focuses on:

• Define business processes;
• stablish minimum quality requirements for people, processes and technologies;
• Establish, review and enforce contract requirements;
• Appropriately resource technical requirements; and
• Maintain situational awareness.

At the individual contributor level (e.g., analyst, engineer, technician, etc.), TOC focuses on:

• Define technical requirements;
• Identify and implement “industry recognized practices” to design, build and maintain systems, applications and services; and
• Provide metrics to management to maintain situational awareness.

Operationalizing CRAP To Your Benefit

This concept of the TOC/CRAP is operationalized through the NIST 800-171 R3 Kill Chain in multiple scenarios:

• As an assessment readiness exercise;
• Prioritization decisions for a phased implementation plan; and
• As a method for introducing a new tool or capability into an existing environment.

“Knowing your CRAP” fundamentally comes down to clearly distinguishing between facts and assumptions. This is the premise for compliance decision making.

Facts are statements of truth, or statements thought to be true. For example:

• The organization stores and processes Controlled Unclassified Information (CUI) as part of a government contract.
• NIST SP 800-171 compliance has been a requirement since 1 January 2018.
• NIST SP 800 171 R3 was released on 14 May 2024.
• The DoD issued a class deviation to delay DFARS implementation of NIST SP 800-171 R3.
• Office of Management and Budget (OMB) requires organizations to adopt the most current version of NIST one year after its release.
• Per 32 CFR § 170.19(c)(2), an External Service Provider (ESP) will be considered in scope for CMMC requirements if it meets CUI Asset and/or Security Protection Asset (SPA) criteria (e.g., stores, processes and/or transmits CUI or Security Protection Data (SPD).

Assumptions are essentially gaps in knowledge or information that need to be confirmed or denied. For example:

• Before NIST SP 800-171 R2 is deprecated in May 2025, the DoD will remove the class deviation for DFARS to transition to NIST SP 800-171 R3.
• The DoD may realize that the Defense Industrial Base (DIB) would be under undo financial pressure to adjust its technologies, ESP and business processes to treat SPD as CUI.