The Cybersecurity Maturity Model Certification (CMMC) will introduce third-party verification of cybersecurity requirements. Organizations may turn to governance, risk, and compliance (GRC) applications to organize artifacts. A few years ago, a blog summarized the requirements for CMMC-focused GRC applications. The author has since led his own company to become one of the first authorized CMMC Third Party Assessor Organizations (C3PAO).
Here are the key criteria identified for Software as a Service (SaaS) GRC applications:
Evaluate compliance for each system of type at the assessment objective level.
Associate evidence to each assessment objective and system of type pairing.
Roll up each pairing to determine the assessment objective compliance.
Roll up each assessment objective to determine the security requirement compliance.
Generate a system of systems report
In this post, we take a closer look at how these features create assurance traceability. We’ve also created a virtual demonstration showing our tool handling these requirements.
Table of Contents
System Compliance at the Assessment Objective Level
Systems and Systems of Type
Systems process, store, and transmit CUI. They also include components that provide security protections. Footnote number nine at the bottom of page 2 of NIST SP 800-171 includes a few system component examples:
Mainframes
Workstations
Servers
Input and output devices
Network Components
Operating systems
Virtual machines
Applications
Table 2 of the CMMC Level 2 Scoping Guide grouped security protect assets into three types of assets:
Image Source: CMMC Level 2 Scoping Guide
Systems of type are groupings of systems based on common characteristics. For example, a system of type may include all WIndows PCs running the same operating system. Organizations should prepare for a review of any in-scope systems. The assessor will pick which devices to evaluate. The assessment depth will likely fall into the focused or comprehensive definitions. This covers a representative or sufficiently large sample of systems.
Assessment Objective Level
Special Publication (SP) 800-171 contains 110 security requirements. NIST tailored these for non-federal organizations to protect controlled unclassified information (CUI). SP 800-171A contains the corresponding assessment procedures. Each requirement has an assessment objective consisting of one or more determination statements. There are 320 determination statements related to the 110 CUI security requirements.
In the example below, a single security requirement has six corresponding determination statements:
Image Source: NIST SP 800-171A
Evaluating Compliance
Now that we have a common understanding of systems and assessment objectives, let’s discuss applicability. Most requirements in SP 800-171 originate from SP 800-53. The guidance from the control baseline SP 800-53B is helpful to define applicability. Summarizing from chapter 2, page 10 of NIST SP 800-53B:
Controls may not apply to every component in the system. Controls are applicable only to components that support the security functions addressed. For example, auditing controls only apply to components of a system that provide auditing capabilities.
An applicability matrix identifies components of the system applicable for each requirement. Here is an awesome open-source CMMC applicability matrix.
Let’s take requirement 3.5.3 multi-factor authentication (MFA) as an example. According to the Defense Industrial Base Cybersecurity Assessment Center (DIBCAC), it is the second most failed requirement. This practice, according to the DIBCAC, applies to any network access. Meaning any connection to a system outside of the box you’re working in requires MFA.
This includes all system components that process, store, and transmit CUI or provide security protections. A non-exhaustive list of components may include:
Servers & Workstations
Mobile & Storage Devices
Applications & Services
Identity & Directory Services
Physical Access Control System
Firewalls
Data Loss Prevention Systems
Virtual Private Network
Configuration Management Databases
Intrusion Detection Systems
Vulnerability Scanners
Security Incident Event Management
CMMC GRC Tools should account for implementation within all applicable system components. The input should allow for implementation variations among components. Capturing the pairing of system components and assessment objectives creates granularity. The system should calculate compliance based on applicable components meeting all assessment objectives.
Associating Evidence
Most GRC tools have the ability to upload or link to artifacts. The inability to pair system components and assessment objectives dilutes reporting functionality. Establishing relationships between artifacts, system components, and assessment objectives creates the desired specificity.
The first step in our evidence workflow pairs assessment objectives and system components. The second step captures a process summary describing the implementation. The final step captures the artifacts as either an attachment or link.
The draft CMMC Assessment Process (CAP) references anticipated evidence in section 1.5. Organization should provide a preliminary list of evidence mapped to the CMMC practices. Capturing the relationship of evidence to assessment objectives and system components enables detailed reporting. In our system, a query populates an exportable table to show these relationships.
Assessment Objective Roll Up
Pairing system components with assessment objectives enables compliance roll up for each objective. We’ll use 3.5.3 as the example again. If all applicable system components meet objective (a), roll up calculates objective (a) as met.
Our evidence workflow calculates the status of each objective on the first step. As seen below, we have met the first three objectives for all system components. The fourth objective is only partially met.
Image Source: K2 Compliance
Security Requirement Roll Up
The second roll up occurs at the security requirement level. To comply with a requirement, the organization must satisfy all assessment objectives.
We present this information using a donut chart for each security requirement. The doughnut chart contains a number of sections based on the applicable system components. The color of each section corresponds to the compliance status of that component.
Image Source: K2 Compliance
System Security Plan
The most daunting compliance artifact is the system security plan (SSP). These reports are often in the hundreds of pages. The bulk of the document details the implementation of the security requirements. CMMC GRC applications have the potential to reduce composition time and standardize formatting.
We tailored the FedRAMP Moderate Template. It was the only one that incorporated assessment objectives when describing implementations. We modified the table within each security requirement detailing the implementation. We populate this table with information submitted in the evidence workflow.
The A.O. column identifies selected assessment objectives. The scoping consideration column identifies the pairing of those objectives to system components. The process details the narrative provided by the organization seeking assessment.
Image Source: K2 Compliance
Conclusion
We’ve met with hundreds of organizations over the past several years who were at various stages of implementing SP 800-171. Most small businesses lack the subject matter expertise to implement and document these requirements. We do not recommend GRC tools as an alternative to contracting a subject matter expert. Small businesses may benefit from GRC tools if paired with a subject matter expert. Once populated, less technical staff may keep up compliance using the capabilities provided by the tool.
Mid-size to large organizations usually have in-house or contracted subject matter experts. There is growing adoption of GRC applications focused on SOC 2 and other frameworks. This has led to increased automation and cross-walking capabilities. Automation requires connectivity between in-scope system components and the cloud-hosted GRC application. This connectivity may move the GRC application into scope for CMMC assessments. Cloud-hosted applications with logical access to the system may require FedRAMP Moderate authorizations. Cross-walking increases the risk of oversimplifying requirements.
Enterprise organizations may have other challenges, such as managing programs with disparate SSPs. They tend to have dedicated security officers responsible for compliance within each program. Without a central GRC solution, teams may duplicate efforts documenting common controls. Lack of standardization and reporting reduces compliance visibility.
If you haven’t had a chance to see a virtual demonstration of our tool, feel free to use the link below. We review the scope applicability mechanism that connects system components to security requirements. We document two security requirements to show the granularity of the evidence workflow. We close by producing an artifact map and system security plan.
