What Are Security Protection Assets (SPAs)?
SPAs are the tools, systems, and personnel that provide security functions or capabilities within the CMMC assessment scope of an Organization Seeking Certification (OSC). They protect CUI assets and the broader infrastructure that supports them.
A Few Examples of SPAs:
Firewalls: Devices or software that regulate network traffic, blocking unauthorized access.
Personnel: System administrators responsible for patching, configuring security systems, and managing changes, Facility Security Officer, Guards
Security Software: Multi-factor authentication (MFA), antivirus, and scanning tools.
Physical Security Systems: Gates, Key card systems, locked server rooms, and other access control mechanisms.
An SPA could process CUI, making it both a security protection asset and a CUI asset. In cases where something is in multiple categories, assessors will apply the stricter requirements of the 2 categories.
How Should SPAs Be Protected?
Documentation:
Asset Inventory: Document SPAs with details such as serial numbers, configurations, and assigned roles.
System Security Plan (SSP):
• Detail how SPAs meet applicable CMMC requirements.
• Include SPAs in the network diagram, showing their interactions with other assets.
Access Control:
• Implement role-based access restrictions for personnel managing SPAs.
• Secure physical access to facilities housing SPAs.
Configuration and Maintenance:
• Regularly update SPA configurations to address vulnerabilities.
• Perform periodic reviews to ensure continued compliance.
What Is Security Protection Data (SPD)?
SPD refers to the security-relevant data generated, processed, or stored by SPAs that helps protect an OSC’s environment. SPD plays a crucial role in enabling security functions and often contains sensitive information that requires robust protections.
Some Examples of SPD:
Configuration Data: Settings required for SPAs to operate effectively, baselines.
Log Files: Generated by firewalls, antivirus programs, and other SPAs to track security events.
Vulnerability Status / Scan Results: Data related to in-scope asset vulnerabilities.
Passwords: Credentials granting access to in-scope environments.
SPD Isn’t CUI by default: While SPD often supports the protection of CUI, not all SPD qualifies as CUI. Contractors must make this distinction during assessments and in documentation.
If SPD, such as general system logs, does not contain specific details that are considered CUI under NARA’s definitions, it is not CUI.
If SPD contains specific details or information that falls under a CUI category, it must be treated as CUI. For example, if a security log captures access attempts to a system processing CUI, that log may then become CUI.
How Should SPD Be Protected?
Classification and Documentation:
Determine whether SPD contains CUI.
If SPD contains sensitive information, align its protection level with applicable CUI requirements.
Track SPD flows in the SSP and asset inventory.
Describe encryption, access controls, and incident response plans related to SPD in the SSP.
Even if SPD is not classified as CUI, contractors must provide assessors with evidence to demonstrate that proper controls and processes are in place to evaluate SPD and protect CUI.
Encryption:
Use FIPS-validated encryption to protect SPD containing CUI during storage and transmission.
Access Control:
• Limit access to personnel authorized to manage or analyze SPD.
• Implement physical and logical controls to restrict unauthorized access.
External Service Providers (ESPs):
If an ESP handles SPD that is not CUI, the ESP itself does not need a CMMC assessment or certification. However, an ESP that is not a CSP may voluntarily request an assessment from a C3PAO.
If the ESP only handles SPD that is not CUI, the SPD’s protection falls under the OSC’s assessment scope. The OSC is responsible for demonstrating that proper controls and processes are in place to evaluate and protect the SPD. The ESP’s services are assessed as part of the OSC’s CMMC assessment as a Security Protection Asset. The assessment ensures that the OSC’s security policies, procedures, and practices are being followed. The OSC’s System Security Plan should document the use of the ESP, its relationship to the OSC, and the services provided, and include the ESP’s service description and customer responsibility matrix (CRM). The CRM outlines the responsibilities of both the OSC and the ESP for the services that are provided.
ESPs that are also Cloud Service Providers (CSPs)
FedRAMP Requirement: A CSP that processes, stores, or transmits CUI, including when that CUI is also considered to be SPD, has to meet the Federal Risk and Authorization Management Program (FedRAMP) requirements., which is mandated by the Defense Federal Acquisition Regulation Supplement (DFARS) clause 252.204-7012. The CSP must be authorized at the FedRAMP Moderate baseline or higher.
The CSP is considered an extension of the OSC’s environment and the services provided by the CSP are within the scope of the OSC’s assessment.
OSC’s Responsibility: Although the CSP is responsible for its own compliance, the OSC is still responsible for documenting how the OSC meets its requirements assigned in the CSP’s Customer Responsibility Matrix (CRM). The OSC must have a CRM from the CSP. The CRM outlines the responsibilities of both the OSC and the CSP. The OSC’s System Security Plan must document or refer to the security requirements from the CRM.
No Credit for Non-Compliant CSPs: A C3PAO can only give credit to a FedRAMP authorized CSP (at the FedRAMP Moderate or higher baseline). Any requirements dependent on a CSP that does not meet the FedRAMP requirements are considered NOT MET.
The OSC is responsible for determining if a CSP that is not FedRAMP authorized meets the requirements for FedRAMP Moderate equivalency as specified in DoD policy.
CMMC Level 3: For CMMC Level 3 certification, if the OSC uses a CSP, the OSC must demonstrate that they are protected by the CSP via a Customer Implementation Summary/Customer Responsibility Matrix (CIS/CRM) and associated Body of Evidence (BOE). The BOE must show whether the OSC or the CSP is responsible for meeting each requirement.
Can An Organization Seeking Certification can generate its own Security Protection Data?
SPD is a byproduct of security functions. An OSC’s security controls and processes create SPD. This can include system logs, vulnerability scan results, and configuration data for security tools. It could include reports that contain this information.
On-prem assets that generate SPD are considered Security Protection Assets (SPA) and are within the scope of a CMMC assessment. Security Protection Assets are used to protect CUI, and so must be included in the CMMC assessment scope and be protected according to the CMMC requirements.
If the SPD contains or is considered CUI, it must be protected and handled according to CUI requirements, including meeting the requirements of DFARS clause 252.204-7012.
The Important Stuff:
1. Understand the Categories:
• Distinguish between SPAs, SPD, and other asset types. Misclassification can lead to compliance gaps.
2. Document Thoroughly:
• Proper documentation of SPAs and SPD in the SSP, inventory, and network diagrams is critical for a successful assessment.
3. Evaluate Risks:
• Regularly review and document risks associated with SPAs and SPD, especially when engaging external providers.
4. Plan for Incidents:
• Have clear, actionable processes to respond to incidents involving SPD or SPAs, ensuring continued protection of CUI.
5. Leverage External Resources:
• For SPD stored with ESPs, ensure the ESP’s compliance and use CRMs to clarify shared responsibilities.