Huntress and DEFCERT Are Streamlining CMMC Assessment Prep

What we built

Our team at DEFCERT collaborated with the team at Huntress to build resources that partners and “Organizations Seeking Assessment” (OSAs) can use to satisfy more shared CMMC requirements. With our initial batch of CMMC resources, we wanted to provide documentation, forms, and job aids covering the CMMC and NIST 800-171 requirements, presenting common problems. On the Huntress Hub, you’ll find:

A Shared Responsibility Matrix (SRM) that includes Huntress capabilities, partner actions, and client actions, so stakeholders can more easily understand their contribution to meeting a NIST 800-171A objective.
An Operations Plan with all partner/client actions from the SRM, along with the names of other CMMC resource documents provided in this initial release.
A straightforward Interconnection Security Agreement to document interconnections between the Huntress Managed Security Platform and client systems, make sure Sensitive Data Mode is adopted, and satisfy NIST 800-171 requirements for external system connections (requirements 3.1.3 and 3.1.20).
Editable Baseline Configurations for the Huntress platform and individual organizations, so partners can gain agreement on defined security configuration settings (requirements 3.4.1 and 3.4.2).
A Security Operations Approvals document used to capture decisions made by clients and fulfilled by partners, as a way to supplement existing policies and documentation.
Checklists, scheduled review templates, and other documents designed to target and simplify recurring CMMC activities.

These initial resources represent the documents and tools that organizations can benefit from early in their CMMC implementation, with continued benefits as they’re leveraged during ongoing compliance activities.

Why we built it

Several DEFCERT team members come from an “External Service Provider” (ESP/MSP/MSSP) background. When we sat down to talk about the difficulties of meeting clients’ CMMC requirements as a service provider, some common problems emerged:

Organizations struggle with asset categorization, especially when a third-party MSP or MSSP is involved.
MSP relationships aren’t documented in NIST-friendly formats because cost-effective services don’t always include robust documentation for all decisions, activities, and compliance outcomes.
Unclear expectations lead to finger-pointing later, especially if “who does what” isn’t found in service level agreements (SLAs).

Based on this, we needed to flatten the learning and adoption curve for clients and partners.

Problem: Organizations struggle with asset categorization

The CMMC program (found in 32 CFR 170) lays out definitions of different asset types, including CUI Assets, Security Protection Assets, and Contractor Risk Managed Assets. However, CMMC Third Party Assessment Organizations (C3PAOs) must agree with your asset categorization before proceeding with a CMMC Level 2 assessment. If a Security Protection Asset (SPA) is capable of handling CUI, then a C3PAO’s lead assessor needs to be confident that you can prevent it.

Solution: Documenting Sensitive Data Mode

All I can say is that Sensitive Data Mode is a case study on how to meet compliance requirements while preserving security capabilities. The Huntress development team reached deep into their own stack and built a kill switch to limit which file extensions a SOC analyst can pull from hosts using the Huntress agent. With that step complete, the solution was pretty straightforward:

Identify the file extensions representing CUI in your organization.
Confirm your CUI file extensions are already on the Blocked Extensions list maintained by Huntress. If not, have them added.
Ask Huntress support to enable Sensitive Data Mode for your account. Once activated, it can’t be changed by you or the Huntress SOC.

We’ve successfully used the Huntress Sensitive Data Mode documentation in scoping calls with CMMC Third Party Assessment Organizations (C3PAOs) to demonstrate why Huntress can operate as a Security Protection Asset (SPA) in a CMMC assessment scope without the risk of becoming a CUI Asset and requiring a FedRAMP Moderate authorization.

Screenshot demonstrating file types excluded when Sensitive Data Mode is enabled

Problem: MSP relationships aren’t documented in NIST-friendly formats

NIST 800-171A assessment objectives require organizations to identify, define, or specify things (time periods, types of users, frequencies, etc.) related to a security control, and then prove it’s implemented based on those inputs. When organizations are working with a partner, like an MSP (External Service Providers, as CMMC calls them), a distinct challenge emerges:

The natural place to document the “rules” for a security control is in a company policy.
MSPs don’t have policy-level authority over their client.
Organizations aren’t necessarily going to change their policy structure, quality management system, or process flow to accommodate their MSP.

These factors lead to friction points when documenting NIST implementations, especially when organizations are looking to make progress quickly. How can we get organizations and their MSPs quite literally “on the same page?”

Solution: “Just enough” documentation for key decisions

We created document templates to capture key decisions (definitions, expected behaviors, preapprovals, etc.) that organizations can use as proof in their CMMC assessments, all without necessarily displacing existing client policies and other documents. We recommend using these templates as audit proofs and “screenshot fodder” when collecting evidence for 800-171A objectives that require you to write something down and act accordingly.

Problem: Unclear Expectations Lead to Finger-Pointing Later

We’re not going to say that all Service Level Agreements (SLAs) are bad, but we’ve certainly seen agreements that don’t clearly define the role clients have in arriving at a CMMC certification. If partner organizations send out generic “we do CMMC” messaging, it can lead to heartburn and headaches during the later stages of a NIST 800-171 implementation, when clients assume “the MSP had this covered.”

Solution: A Shared Responsibility Matrix (SRM) that Considers All Parties

We structured the Huntress Shared Responsibility Matrix (SRM) and its associated Operations Plan to say more of the quiet parts out loud. The SRM contains a column for Huntress capabilities, partner actions, and client actions. There’s no question when success depends on a partner or client, since those activities are listed separately. Ultimately, comparing these responsibilities side by side should prompt more honest and informed discussions about resource planning, level of effort, and who might be blocking progress if they aren’t fulfilling their end of shared responsibilities.

Screenshot demonstrating the SRM