The TLDRs of CUI, DIB/NSIB, CMMC, OSCAL, and STIGs

We’ve written several articles about the updated CMMC certification process for the Defense Industrial Base (DIB) and the National Security Industrial Base (NSIB) and why it's important for Confidential Unclassified Information (CUI) protection.

Below are some summaries:

CUI (Full Document: Safeguarding Controlled Unclassified Information (CUI))

• CUI stands for Confidential Unclassified Information. It is information that is not classified but still needs to be protected.

• CUI can include business plans, financial data, and trade secrets.

• The Cybersecurity Maturity Model Certification (CMMC) program is designed to protect CUI by requiring companies and subcontractors that work with the Department of Defense (DoD) to implement cybersecurity standards at progressively advanced levels.

• OSCAL can help protect CUI by providing a standardized, data-centric framework for documenting, implementing, and assessing high-level security controls. This can help organizations manage their security risks and ensure CUI is protected from unauthorized disclosure or modification.

• Low-level security controls applied to the systems that store and transmit CUI need to be protected by STIGs and CCEs - something beyond OSCAL at this time.

DIB/NSIB (Full Document: The DIB, NSIB, and CMMC 2.0)

• These are the organizations that handle CUI and fall under CMMC.

• The Defense Industrial Base (DIB) is a network of private-sector and government-run facilities, capabilities, and activities essential for the production, development, and maintenance of military weapons systems and technology.

• The National Security Industrial Base (NSIB) is a broader concept than the DIB. It includes traditional defense contractors and suppliers but also encompasses a wide range of industries and sectors that contribute to overall national security. This includes technology sectors, research and development communities, academia, and various other industries that may not directly deal with traditional military defense. However, they are crucial to the nation’s overall technological and strategic superiority.

CMMC (Full Document: CMMC 2.0 Plain and Simple)

• CMMC stands for Cybersecurity Maturity Model Certification.

• CMMC 2.0 is an updated version of CMMC that aims to enhance cybersecurity, minimize costs, and align with widely accepted standards.

• CMMC 2.0 has streamlined certification requirements, reducing levels from five to three and aligning closely with National Institute of Standards and Technology (NIST) standards.

• It emphasizes self-assessments at certain levels, increases oversight of third-party assessors, and allows conditional certifications under specific circumstances.

Differences from CMMC 1.0:

• CMMC 2.0 has fewer compliance levels, simplifying certification processes.

• CMMC 2.0 introduces waivers to CMMC requirements, allowing organizations to address specific cybersecurity challenges.

• CMMC 2.0 aligns with NIST cybersecurity standards, ensuring higher security and resilience against cyber threats.

The Uses of OSCAL for CMMC Compliance (Full Document: The Impact of OSCAL on CMMC Compliance)

The Open Security Controls Assessment Language (OSCAL) is utilized within Cybersecurity Maturity Model Certification (CMMC) to enhance assessment methodologies by:

• Providing a common means to identify and standardize assessment information, thereby streamlining and homogenizing the processes of documenting, implementing, and assessing security controls.

• Transitioning the legacy approach to security plan generation and management to a data-centric approach, allowing for greater automation and verification.

• Enabling real-time automated security controls assessment enhances security capabilities within the framework.

• Improving system security assessments, decreasing assessment-related labor, and enhancing information sharing.

• Contributing to the overall improvement of security controls implementation within the CMMC framework.

However, OSCAL doesn't provide a bridge between high-level controls and low-level system configuration controls.

The Limitations of OSCAL for CMMC Compliance (Full Document: What’s missing in both OSCAL content and OSCAL technical implementations?)

With the above said, OSCAL doesn’t include a methodology for describing low-level system security controls. Those are described by STIGs and CCEs.

•  STIGs (Security Technical Implementation Guides) are a set of security controls to be followed. They are generally considered best practices created by the U.S. government. STIGs "lock down" a system to meet minimum security standards.

•  CCE (Common Configuration Enumeration) is a set of details that tell you if a control has been applied to a system or software. CCE was created by the National Institute of Standards and Technology (NIST) and is used to automate the assessment of security controls.

We agree with an article by Bill Weber that bridging OSCAL to STIGs requires a common cause for creating libraries of controls that can be consumed within the OSCAL framework. This involves showing a common commitment to developing, expressing, and auditing from this control set. The SCAP CCE and STIG communities can come together to achieve this goal.

What the Unified Compliance Team is Doing to Help

• Unified Compliance (UC) is releasing its UCF 4.0 product with enhanced API support. It is taking an AI-forward, community-based approach to mapping high-level OSCAL content to low-level STIG and CCE content.

• The UC team is building out an advanced, patented, API suite to extract, transform, enrich, and map high-level OSCAL and other content to low-level STIGs, CCEs, and other technical content.