CMMC Kill Chain - Creating A Project Plan For Your CMMC Assessment

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

Why “CMMC 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 CMMC's 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 CMMC 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 CMMC into 24 major steps, which can then be translated into a 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 an assessment?” All of the CMMC practices and processes are addressed within the 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.

Applying The Kill Chain Model To CMMC

You might be asking yourself how a kill chain model applies to CMMC. The root issue pertains to the situation facing many IT & cybersecurity professionals who are looking at 2021 with dread: These front-line IT/cybersecurity practitioners currently do not know where to start, let alone what path they need to follow to pass a CMMC assessment. There is a plethora of "What is CMMC?" 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 CMMC" in realistic terms. The CMMC 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. This model will also be added to the CMMC Center of Awesomeness website if you are looking for it in the future. You can also download it by clicking on the image below to get a PDF version of the graphic and description. 

CMMC Project Planning Tool

The premise of the CMMC 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 CMMC assessment. Errors or misguided adventures with people, processes and technology earlier in CMMC practice/process implementation activities will have cascading effects, so the CMMC Kill Chain is meant to provide a model for prioritizing CMMC-related pre-assessment activities. The CMMC Kill Chain breaks down CMMC into 24 major steps, which can then be translated into a project plan. 

CMMC Kill Chain Phases

Here is information on the 24 phases of the CMMC Kill Chain (these correspond to the picture diagram):

1. Define What CUI Is For Your Specific Business Case. This should be self-explanatory and is based on your contract(s).
2. Establish The Scope of The CMMC Assessment Boundary. This has four subcomponent steps: (1) Create a Data Flow Diagram (DFD) that shows how CUI flows from the DoD all the way down to subcontractors; (2) Create a detailed asset inventory for all systems, applications and services for both in-scope and out-of-scope assets; (3) Create a detailed network diagram that includes where CUI is stored, transmitted and/or processed; and (4) Inventory Third-Party Service Providers (TSP) to determine TSP access to CUI and/or in-scope systems, applications and/or services.
3. Document The Environment. This has two subcomponent steps: (1) Start populating the System Security Plan (SSP); and (2) Create a Plan of Action & Milestone (POA&M) to track and remediate deficiencies.
4. Define The 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 & document procedures.
5. Plan, Identify Gaps & Prioritize Resources. This has six subcomponent steps: (1) Define applicable statutory, regulatory and contractual obligations (including DFARS, FAR, NIST 800-171 and CMMC); (2) Perform a gap assessment from applicable statutory, regulatory and contractual obligations; (3) Develop & implement policies and standards to address applicable statutory, regulatory and contractual obligations; (4) Identify the necessary People, Processes & Technology (PPT) that are necessary and appropriately sized; (5) Develop & implement a resource plan (e.g., business plan, budget, road map, etc.) to meet compliance obligations; and (6) Prioritize objectives from the resource plan for PPT requirements. POA&M any deficiencies from this phase.
6. Develop Procedures. This has two subcomponent steps: (1) Develop & implement procedures to implement policies & standards; and (2) Define processes to securely handle CUI. POA&M any deficiencies from this phase.
7. Risk Management. Develop & implement a Risk Management Program (RMP) to identify, assess and remediate risk. POA&M deficiencies & document procedures.
8. Change Control. Develop & implement change control processes, including a Change Control Board (CCB). POA&M deficiencies & document procedures.
9. Incident Response. Develop & implement incident response capabilities to detect, respond and recover from incidents. POA&M deficiencies & document procedures.
10. Situational Awareness. Develop & implement situational awareness capabilities through log collection and analysis (e.g., SIEM). POA&M deficiencies & document procedures.
11. System Hardening. Identify, build & implement secure baseline configurations (e.g., hardening standards) for all technology platforms. POA&M deficiencies & document procedures.
12. Centralized Management. Build & implement Group Policy Objects (GPOs) for Microsoft Active Directory (AD). POA&M deficiencies & document procedures.
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.
14. Maintenance. Develop & implement proactive maintenance practices. POA&M deficiencies & document procedures.
15. Attack Surface Management / Vulnerability Management. Develop & implement Attack Surface Management (ASM) practices. POA&M deficiencies & document procedures.
16. Asset Management. Develop & implement technology asset management practices. POA&M deficiencies & document procedures.
17. Personnel Security. Work with Human Resources (HR) to ensure personnel security requirements are integrated into HR operations. POA&M deficiencies & document procedures.
18. Network Security. Develop & implement network security practices. POA&M deficiencies & document procedures.
19. Business Continuity. Develop & implement business continuity capabilities. POA&M deficiencies & document procedures.
20. Cryptography. Develop & implement cryptographic key management and data encryption capabilities. POA&M deficiencies & document procedures.
21. Physical Security. Develop & implement physical security practices. POA&M deficiencies & document procedures.
22. Threat Intelligence. Develop & implement a threat intelligence capability. POA&M deficiencies & document procedures.
23. Security Awareness Training. Build and maintain a security-minded workforce through training & awareness. POA&M deficiencies & document procedures.
24. Internal Audit. Build and maintain an "internal audit" or Information Assurance (IA) capability to govern controls. POA&M deficiencies & document procedures.

Background On The Logic Used In This Model

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

• 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, 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.
• 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 & CMMC Documentation Done Right - Scalable Solutions That Are Affordable, Comprehensive & Efficient

We leverage the Hierarchical Cybersecurity Governance Framework to develop the necessary documentation components that are key to being able to demonstrate evidence of due diligence and due care for our clients. This methodology towards documentation acknowledges the interconnectivity that exists between policies, control objectives, standards, guidelines, controls, risks, procedures & metrics. This documentation model works well with ISO 27002, NIST CSF, NIST 800-171, NIST 800-53, FedRAMP, CIS CSC Top 20, PCI DSS, Secure Controls Framework (SCF) and other control frameworks. 

Essentially, ComplianceForge simplified the concept of the hierarchical nature of cybersecurity and privacy documentation that you can see in the downloadable diagram shown below. This helps demonstrate the unique nature of these components, as well as the dependencies that exist. You can download the example to better understand how we write our documentation that links policies all the way down to metrics. This is a great solution for any organization currently using or migrating to a Governance, Risk & Compliance (GRC) or Integrated Risk Management (IRM) platform to help automate their governance practices.

NIST 800-171 is intended to force contractors to adhere with reasonably-expected security requirements that have been in use by the US government for years. NIST 800-171 establishes a basic set of expectations and maps these requirements to NIST 800-53, which is the de facto standard for US government cybersecurity controls. In some ways, this is a good thing since the US government is not reinventing the wheel with new requirements. Instead, the DoD selected moderate-level controls from an existing set of recognized best practices, commonly used throughout the DoD and Federal agencies. In the long run, this will help both the US government and private businesses speak the same language for cybersecurity. 

The bottom line is NIST 800-171 creates a standardized and uniform set of requirements for all Controlled Unclassified Information (CUI) security needs. This is designed to address common deficiencies in managing and protecting unclassified information by that is being stored, transmitted or processed by private businesses.