Concept of Operations (CONOPS): The Unified CSRMC Gateway (UCG)

Date: December 11, 2025

Subject: Proposal for an Inter-Agency eMASS Data Clearing House to Accelerate CSRMC Authorization

To: Defense Counterintelligence and Security Agency (DCSA) / Defense Information Systems Agency (DISA)

From: [Your Organization/Name]

1. Executive Summary

The National Industrial Security Program (NISP), established by Executive Order 12829, mandates rigorous security standards for industrial contractors and government agencies. While the Enterprise Mission Assurance Support Service (eMASS) has successfully digitized risk management, the Department of War has recently transitioned to the Cybersecurity Risk Management Construct (CSRMC). This new framework emphasizes a 5-phase lifecycle (Design, Build, Test, Onboard, Operations) and focuses on dynamic, automated, and continuous risk management.

This Concept of Operations (CONOPS) proposes the development of the Unified CSRMC Gateway (UCG). This clearing house will act as a central API gateway connecting disparate eMASS installations across the Military. UCG serves as the critical enabler for the CSRMC by automating the "Reciprocity" and "Inheritance" tenets, allowing Authorizing Officials (AOs) to leverage pre-validated data to accelerate the Onboard phase and achieve true Speed to Capability.

The Unified CSRMC Gateway transforms reciprocity from a policy aspiration into a measurable, automated enterprise capability.

2. Current Operating Environment (COE)

Currently, DCSA and DISA are adapting to the CSRMC process. However, the workflow remains linear and isolated, creating bottlenecks that hinder the Construct's goals.

1. Standardization without Reciprocity: Initiatives like the DoD Enterprise DevSecOps Reference Design provide DoD Cloud Infrastructure as Code (IaC) templates (Phase 1: Design). Agencies deploy these mathematically identical environments (Phase 2: Build), but the downstream benefit is lost.

2. The "Test" Phase Bottleneck: Despite identical builds, the Test Phase often involves redundant, manual assessments for every new instance, ignoring the statistical probability of security established by the template.

3. Delayed Onboarding: The Onboard Phase, intended to activate continuous monitoring immediately, is delayed by months as AOs review packages de novo.

4. Inefficiency: Evaluation teams re-test validated configurations, and AOs review packages as if they are novel, directly contradicting the CSRMC tenets of Automation and Reciprocity.

3. Problem Statement

The lack of horizontal communication between eMASS instances results in:

• Stalled CSRMC Lifecycle: The velocity gained in "Design" and "Build" is lost during "Test" and "Onboard."

• Wasted Man-Hours: Duplicate data entry and testing for standard DoD Cloud IaC configurations.

• Inconsistent Standards: One AO may accept a configuration that another rejects, despite identical technical baselines derived from the same source code.

3.1 Clarification of Scope and Non-Goals

This CONOPS does not propose changes to Authorizing Official (AO) authority, risk ownership, or local decision-making.

The Unified CSRMC Gateway (UCG) is not intended to centralize Authorization to Operate (ATO) decisions, override AO judgment, or introduce a single approving authority across the Department. Risk acceptance remains the sole responsibility of the designated AO for each system.

Additionally, the UCG does not expose system-level operational details, mission context, network topology, or organizational attribution. Its function is limited to the aggregation and comparison of anonymized technical compliance artifacts for the purpose of enabling reciprocity and inheritance as defined by existing policy.

The problem addressed by this CONOPS is not insufficient AO authority, but the lack of an enterprise mechanism to surface and reuse pre-existing, validated technical evidence across organizational boundaries.

The UCG does not centralize ATO authority, mandate reciprocity acceptance, or override mission-specific risk decisions.

4. Proposed Concept: The UCG Clearing House

4.1. Operational Overview

The UCG is a "Middleware Clearing House"—a secure API Gateway that acts as the CSRMC Compliance Engine. It connects user (ISSO/Assessor) workflows with the global ecosystem of eMASS installations, indexing values to enable "Blind Reciprocity."

4.2. Functional Architecture

The system operates on a Query-Response model with a strict Anonymization Layer.

4.2.1. Standardized Input Ingestion (The "Trusted Baseline")

The UCG is optimized to ingest data from known, immutable sources such as DoD Cloud IaC templates.

• When an agency deploys a system using a verified DoD Cloud IaC template, the UCG recognizes the unique signature (hash) of that deployment.

• This establishes the "Trusted Baseline" required for the Build Phase (IOC).

4.2.2. The API Gateway

The Gateway ingests connection requests from local eMASS installations. It allows an ISSO to upload a "candidate file" (e.g., a STIG Checklist, ACAS scan result, or IaC Template Hash) and query the Clearing House.

4.2.3. The Anonymization Engine (The "Black Box")

This is the core innovation of the UCG.

• Input: The engine receives data from all connected eMASS nodes (Agency A, Base B, Contractor C).

• Sanitization: It systematically strips all metadata that could identify the source (IPs, Unit Names, FQDNs).

• Output: The engine presents a "Statistical Assurance Indicator" based on aggregate data, facilitating the Reciprocity tenet. This does not replace AO judgment; it augments it with objective enterprise evidence.

4.3. Concept of Use (Use Case)

Scenario: A Receiving Organization (e.g., a defense contractor) needs an ATO for a Red Hat Enterprise Linux 9 web server deployed via a Granting Organization's (e.g., DISA HaCC) DoD Cloud IaC template.

1. Initiation (Build Phase): The Receiving Organization deploys the server using the approved DoD Cloud IaC template.

2. Query: In eMASS, the ISSO selects "Search UCG" and provides the Template ID/Hash.

3. Matching: The Clearing House recognizes the DoD Cloud IaC signature.

4. The Return (Test Phase Acceleration): The system returns a comprehensive report:

   • "Template Match: DoD Cloud IaC - Azure Web App v2.1."

   • "Identical configuration values found in 4,200 active ATO packages."

   • "Compliance Rate: 99.9%."

5. Onboard: The UCG returns a High-Confidence Match Report that may be used by the Authorizing Official as supporting evidence in accordance with the DoD Cybersecurity Reciprocity Playbook, AO Consortium guidance, and local risk acceptance thresholds.

6. Operations: The system activates automated continuous monitoring immediately.

5. Security & Privacy (OPSEC)

The primary concern for a centralized repository is the potential for an adversary to map the government's entire network topology. UCG addresses this via Data Decoupling.

• Value-Only Storage: The Clearing House does not store the "who" or "where." It only stores the "what."

• One-Way Hashing: Source Agency IDs are hashed upon ingestion.

• Need-to-Know: Participating agencies cannot browse the database; they can only query against specific technical artifacts they already possess.

6. Operational Benefits

Benefit Category

Description

Speed

Reduces package creation time from months to days by importing pre-validated narratives and values.

Cost Savings

Massive reduction in labor hours for ISSOs and Security Control Assessors (SCAs).

Standardization

Incentivizes the use of DoD Cloud IaC and other approved baselines to achieve faster authorization times.

Blind Reciprocity

Allows agencies to trust the data without needing to establish formal MOUs with every other agency, as the trust is brokered by the Clearing House logic.

7. Strategic Alignment with CSRMC & Policy

The UCG is explicitly designed to operationalize the Cybersecurity Risk Management Construct (CSRMC) and the DoD Cybersecurity Reciprocity Playbook (March 2024).

7.1. Alignment with the CSRMC 5-Phase Lifecycle

The UCG acts as the accelerator that moves systems from Build to Operations by compressing the middle phases.

• Phase 1: Design: UCG establishes a repository of "Trusted Baselines" derived from approved secure designs.

• Phase 2: Build (IOC): UCG validates that the deployed system matches the "Secure Design" hash, confirming IOC integrity.

• Phase 3: Test (FOC): UCG replaces redundant manual control validation activities with automated comparison against previously validated enterprise evidence. (Evidence of Previous Testing).

• Phase 4: Onboard: UCG provides the "High Confidence Match" report, giving AOs the assurance needed to authorize immediate onboarding.

• Phase 5: Operations: By accelerating the previous phases, UCG ensures systems reach the Operations phase faster, activating real-time dashboards and alerting mechanisms sooner.

7.2. Operationalizing CSRMC Strategic Tenets

The UCG fulfills multiple foundational principles of the Construct:

• Reciprocity: UCG converts this policy concept into a technical reality by providing objective, cryptographic proof that systems are identical, removing human bias.

• Automation: UCG streamlines the authorization process, replacing manual searches with automated API queries.

• Enterprise Services and Inheritance: UCG acts as the transfer mechanism for inheritance, allowing local systems to instantly inherit "Gold Standard" controls from Enterprise Services.

• DevSecOps: UCG integrates with the development process by validating that deployed infrastructure matches the output of secure DevSecOps pipelines.

7.3. Regulatory Compliance (DoD Reciprocity Playbook)

• Facilitating "AO Consortium": UCG provides the data transparency required for an AO Consortium to function effectively.

• Automating Reciprocity Search: UCG evolves the eMASS search function from a manual tool to an automated, API-driven process.

• Dispute Resolution: UCG mitigates the risk of reciprocity refusal by providing irrefutable data evidence, reducing the "10-day refusal window."

8. Implementation Roadmap

1. Phase 1: Pilot Program (DCSA Only) – Connect NISP eMASS instances to normalize contractor data and integrate DoD Cloud IaC template hashes.

2. Phase 2: The Gateway Build – Develop the API structure and the Anonymization/Sanitization algorithms.

3. Phase 3: Joint Integration – Connect DISA and Service-level eMASS instances.

4. Phase 4: Full Operational Capability (FOC) – Automated recommendations and AI-assisted trend analysis and anomaly detection based on aggregate enterprise data.

9. Conclusion

The current authorization process is bottlenecked by the inability to leverage the collective work of the DoD and Industrial Base. The UCG concept transforms the process from a manual, linear effort into a data-driven, automated ecosystem. By leveraging standardized inputs like DoD Cloud IaC and aligning directly with the CSRMC Lifecycle and Tenets, DCSA and DISA can achieve the speed of operations required by modern warfare while maintaining the highest levels of information security.
UCG acts as a force multiplier for Authorizing Officials, enabling enterprise-scale reciprocity without increasing risk ownership or staffing requirements.