Is A GRC Tool A Security Protection Asset (SPA)?

In compliance-related matters there is no room for opinion since the letter of the law, regulation and/or contractual obligation is what matters. Reading into “intent” is unprofessional conduct on behalf of an auditor/assessor and is grounds to raise ethical concerns over their conduct. Even the CMMC Code of Professional Conduct section 2.2(f) requires those in the CMMC Ecosystem to base "evaluative decisions on factual evidence and standardized processes while avoiding personal opinions or biases that could influence outcomes." Additionally, Section 2.7(a) also requires "relying upon, and adhering to, the authoritative CMMC references of 32 CFR Part 170" to further avoid opinion.

CMMC Scoping Example – SPAs & SPD

Among Cybersecurity Maturity Model Certification (CMMC) practitioners, there are divided thoughts on the extent of applicability in terms of Security Protection Assets (SPAs) and associated Security Protection Data (SPD). For a specific example question: “Is a Governance, Risk & Compliance (GRC) tool a SPA? Is the data that is stored, processed and/or transmitted in a GRC tool SPD?”

Compliance Starts With Authoritative Definitions

Compliance starts with authoritative definitions, since words have specific meanings that can be different based on the law, regulation or framework being assessed against. To answer the question about SPAs and SPDs, it is necessary to define the key components that make up the requirements.

In the context of CMMC, 32 CFR 170.4(b) provides several authoritative definitions:

• Security Protection Assets (SPA) means assets providing security functions or capabilities for the OSA's CMMC Assessment Scope.
• Security Protection Data (SPD) means data stored or processed by SPA that are used to protect an OSC's assessed environment. SPD is security relevant information and includes but is not limited to:
  • Configuration data required to operate a SPA;
  • Log files generated by or ingested by a SPA;
  • Data related to the configuration or vulnerability status of in-scope assets; and
  • Passwords that grant access to the in-scope environment.

For generalized cybersecurity definitions, where 32 CFR 170 does not provide a definition, the NIST Glossary is the next most reputable source for an authoritative definition on cybersecurity matters dealing with the US Government:

• Capability. A combination of mutually reinforcing security and/or privacy controls implemented by technical, physical, and procedural means. Such controls are typically selected to achieve a common information security- or privacy-related purpose.
• Configuration. The possible conditions, parameters, and specifications with which an information system or system component can be described or arranged.
• Configuration Settings. The set of parameters that can be changed in hardware, software, or firmware that affect the security posture and/or functionality of the information system.
• Common Secure Configuration. A recognized standardized and established benchmark (e.g., National Checklist Program, DISA STIGs, CIS Benchmarks, etc.) that stipulates specific secure configuration settings for a given IT platform.
• Protection Needs. [note NIST does not have a definition for “protect” so the closest definition is “protection needs”] Informal statement or expression of the stakeholder security requirements focused on protecting information, systems, and services associated with mission and business functions throughout the system life cycle.

NIST’s Glossary does not have a definition of what a Governance, Risk & Compliance (GRC) tool performs, but does have a reference to several other NIST documents that do provide a definition of what a GRC is:

• NIST SP 800-37 Rev 2 states that “commercially available governance, risk, and compliance (GRC) tools can be employed to reduce or eliminate hard copy documentation.”
• NIST SP 800-47 Rev 1 states that “a tracking system provides a method to log and track information exchange outside of the authorization boundary. Examples of tracking systems include but are not limited to internal spreadsheets or databases; Governance, Risk, and Compliance (GRC) tools or other automated tools; and keeping up-to-date control implementation information in a system security plan. Note that requirements for tracking information exchanges may be addressed as part of other types of agreements (e.g., ISA and IEA).”

Of applicability to CMMC, NIST SP 800-171 Rev 3 states that GRC tools are used to manage "documentation artifacts." NIST SP 800-171 Rev 3 states “artifacts may be in formats other than documents (e.g., databases, Governance, Risk, and Compliance [GRC] tools, or Open Security Controls Assessment Language [OSCAL])” where:

• Assessment objects identify the specific items being assessed and can include specifications, mechanisms, activities, and individuals.
• Specifications are the documented artifacts (e.g., plans, policies, procedures, requirements, functional and assurance specifications, design documentation, and architectures) associated with a system.
• Mechanisms are the hardware, software, and firmware safeguards implemented within a system.
• Activities are the protection related actions supporting a system that involve people (e.g., conducting system backup operations, exercising an incident response plan, and monitoring network traffic).
• Individuals are the people applying the specifications, mechanisms, or activities described above.”

Does A GRC Tool Provide “Security Functions or Capabilities” For CMMC?

From the NIST SP 800-37 definition of what a GRC tool does, it is a “tracking system” that provides a method to log and track information. While some GRC tools may try to offer specialized CMMC services, a traditional GRC tool does not provide a “security function or capability” within the CMMC assessment boundary – it provides “meta security data” that is simply information about security controls (e.g., status of controls, assigned control owner(s), location of evidence, etc.). It is unreasonable to stretch the definition of “protection” to describe the role of a GRC tool, since it merely provides a reference to what is being performed and not actually providing the control implementation.

Does that mean a screenshot of config files assigned to a control in a GRC tool would constitute SPD? No. From a reasonable person’s perspective, a screenshot is not the actual configuration file that is “stored or processed by SPA that are used to protect an OSC's assessed environment.” That screenshot is meta security data, where the GRC tool only references that data from a different source that would be a SPA.

Additionally, from a Devil’s Advocate perspective for the “Is a config file SPD?” debate, those arguing for a config file to be considered SPD would be hard pressed to defend that position if an organization was using default CIS Benchmarks or DISA STIGs for their configurations. Their logic would be that a publicly available “common secure configurations” guide would be considered SPD. A reasonable interpretation of a scenario where a GRC tool references the use of CIS Benchmarks or DISA STIGs and in that case the mention of using those common secure configurations would not be SPD, based on 32 CFR 170.