How Ceph helps protect CUI at rest for NIST SP 800-171 requirement 03.13.08
A defense contractor or other nonfederal organization storing controlled unclassified information (CUI) on Ceph needs to know whether the platform can support requirement 03.13.08, which calls for cryptographic mechanisms that prevent unauthorized disclosure of CUI in transmission and in storage. Ceph provides the building blocks: encryption at rest for OSDs, and the msgr2 secure mode, which encrypts all post-authentication traffic between cluster daemons and clients with AES-GCM and adds integrity checks. Those are capabilities of the platform, not a finding that your environment satisfies the requirement. DeployOpen configures and documents these settings in your infrastructure and prepares the evidence an assessor will ask for. It does not issue assessment results or certifications; independent assessors do that.
The version question comes first. NIST published SP 800-171 Rev. 3 on 14 May 2024 and it remains the current NIST version, but CMMC Level 2 assesses the Rev. 2 requirement 3.13.8, identified as SC.L2-3.13.8 and worth 3 points, and 32 CFR 170.21 does not allow that requirement on a POA&M for Conditional status. A July 2026 Department of War statement said Rev. 2 will be enforced in the interim, and contract clauses may name a specific revision. Confirm with your contracting officer which revision applies to each contract, and map your evidence to both numbering schemes until that is settled.
Several parts stay open after the platform is configured. Ceph's encryption at rest and msgr2 settings do not, by themselves, establish FIPS validation of the cryptographic modules in use; confirm with your assessor and the Ceph and operating system documentation whether the modules in your build are validated and how they are operated. Key custody is also yours to define: decide whether keys sit in an external KMS, who holds administrative rights to them, and how rotation and recovery are logged. Finally, the scoring impact depends on the assessor's review of your full system security plan, not on the storage configuration alone. Ask DeployOpen for a written scope that names these decisions before the build begins.
Mapping 03.13.08 and SC.L2-3.13.8 to Ceph configuration
This table maps NIST SP 800-171 Rev. 3 requirement 03.13.08 and its CMMC Level 2 counterpart SC.L2-3.13.8 to the Ceph features that protect CUI in transit and in storage. Read each row for the capability, the configuration it needs and the controls that stay with your organization. The main takeaway is that Ceph supplies the cryptographic mechanisms, while key custody, scope decisions and assessor evidence remain your responsibility.
| Requirement | Ceph capability | Configuration needed | Customer responsibility |
|---|---|---|---|
| NIST SP 800-171 Rev. 3, 03.13.08 | Cryptographic mechanisms for CUI in transmission and in storage | Combine msgr2 secure mode, OSD encryption and RGW encryption where CUI is stored | Define which systems hold CUI and document the mechanism chosen for each path |
| CMMC SC.L2-3.13.8 (Rev. 2, 3 points) | Same protection objective, assessed against Rev. 2 under 32 CFR 170.14 | Retain evidence of configuration and test results in final form | Assessor decides MET status; a POA&M cannot cover this objective for Conditional status |
| msgr2 secure mode on port 3300 | AES-GCM encryption of post-authentication traffic with integrity checks | Set the ms mode options to secure for cluster, service and client traffic; confirm exact keys in Tentacle or Squid docs | Confirm legacy v1 connections are blocked and verify with a traffic capture |
| Encryption at rest on OSDs | Encrypted OSDs for data on drives, configured through cephadm OSD service specifications | Set encryption in the OSD spec and confirm the exact key name in current docs | Manage key custody, escrow, rotation and the recovery process for lost keys |
| RGW server-side encryption | Encryption of objects written through the S3 API with keys from a configured key backend | Configure the RGW encryption settings and key backend; confirm exact option names and SSL requirements | Choose the key service, enforce encryption through bucket policy and cover copies made outside the cluster |
| Dashboard single sign-on | SAML 2.0, or OAuth2 when the Management Gateway and OAuth2 Proxy services run | Configure the identity provider, TLS for the dashboard and the chosen SSO method | Enforce multi-factor authentication at the identity provider and limit administrator accounts |
What Ceph encryption at rest and msgr2 secure mode actually cover
Ceph protects CUI in two separate layers, and only one of them addresses storage. Messenger v2 secure mode, enabled through the msgr2 protocol on port 3300, encrypts all traffic between daemons and clients after authentication, using AES-GCM with integrity checks. That addresses the transmission half of 03.13.08. Encryption at rest is a different mechanism: it is applied to OSDs (typically through dm-crypt on the drives) or to objects handled by the Ceph Object Gateway (RGW) with server-side encryption. Neither layer substitutes for the other, and a reviewer will ask for evidence of both.
Secure mode does nothing for data sitting on disks, in snapshots, in backups or in replicas. A CUI file written to an unencrypted OSD is still readable by anyone who obtains a drive, whatever the wire looked like. Conversely, encrypted OSDs do not stop plaintext from crossing the network if a client connects over the legacy v1 protocol or a path is left unencrypted. The practical task is to find those gaps. Check which protocol each client actually negotiates, confirm that the secure mode setting is enforced rather than merely preferred in your release, and inventory replication, mirroring and multisite channels, since each must be verified separately.
Confirm every setting against the documentation for the exact release you run, because option names, defaults and enforcement behavior differ between versions. Start with the Ceph messenger v2 documentation and the Ceph Object Gateway documentation for encryption options. Then test: capture traffic on a non-production cluster to confirm that payloads are not visible in clear text, and record the results as evidence. Treat any client that cannot negotiate secure mode as an open finding until it is retired or documented as a formal exception.
Which evidence the assessor will ask for and how to keep it
An assessor testing the Ceph encryption requirement will ask for configuration, custody and test records that show the protection is in place and operating. Each card below names one item to collect, and each must be in final form before the assessment, because drafts do not count toward MET.
msgr2 secure mode configuration export
Export the effective messenger settings from the monitors and OSDs, showing that secure mode is required rather than merely allowed for cluster traffic. Capture the configuration as it stood on the assessment date, with the command output and the time it was run. Check that the export covers every daemon class that carries CUI, including RGW and client connections that use the v2 protocol on port 3300. An export showing only the default is not enough.
Encryption settings per pool or OSD
Record which pools, OSDs or RGW buckets hold CUI and how each one is encrypted at rest, including the encryption setting and the key scope used. Map each CUI data set to its storage location so the assessor can trace a system boundary without guessing. Note any pool that stores CUI without encryption and resolve it before the assessment.
Cephadm service specifications
Keep the cephadm service specs and host definitions under version control, since they show how daemons, placement and security settings were deployed. Each spec should match the running cluster, so compare the stored files with the output of the orchestrator when you collect evidence. Dated, signed changes to these files help show that encryption settings were not altered without review.
Key custody records
Document who creates, stores, rotates and retires the encryption keys, and where the key material is held. Name the roles with access and show how that access is limited and logged. Confirm the key management design with your team and your assessor before you describe it in the system security plan, since the controls around keys depend on your environment.
Change records for encryption settings
Keep tickets or approvals for every change to encryption, transport security, key rotation and cluster upgrades that touch them. Each record should state the change, the approver, the date and the verification result. Assessors look for a pattern of controlled change, so a gap of unexplained configuration drift is a finding risk.
Test results showing ciphertext on disk
Keep a dated test that writes a known marker into an encrypted pool, then reads the raw device or OSD data and shows that the marker is not recoverable in plaintext. Repeat the test after each upgrade or key rotation. Store the test script, its inputs, the output and the person who ran it, so the result can be reproduced in the assessment.
Configuration sequence for a CUI-scoped Ceph cluster
This sequence takes a Ceph cluster from an undefined storage estate to one where CUI boundaries, encryption paths and administrative access are defined, configured and checked against evidence an assessor can review. Each step closes with an output that feeds the next.
Define the CUI boundary and data flows
Before any cluster is built, the organization lists which systems create, store, process or transmit CUI, and which Ceph pools, RGW buckets, RBD images and CephFS file systems will hold it. The team draws the data flows between clients, gateways, monitors, OSD hosts and backup targets, and records which administrators can reach each component. The step is complete when the boundary diagram and a data flow inventory are approved by the system owner and the compliance lead. Anything outside the boundary is kept on separate pools or clusters so that scoping decisions stay simple later.
Deploy with cephadm on a supported release
Deploy the cluster with cephadm on a release the Ceph project still maintains. The Ceph releases page lists Tentacle (20.2.x, first released November 18, 2025, latest 20.2.4, estimated end of life June 1, 2027) and Squid (19.2.x, first released September 26, 2024, latest 19.2.7, estimated end of life October 31, 2026). Choose the release with an end-of-life date that outlasts your planned operating period, and confirm the current end-of-life dates on the releases page before you commit. Record the exact version in the baseline, since patch levels change security posture. The step is complete when
ceph versionsshows one version across all daemons and the cluster reports HEALTH_OK.Enforce msgr2 secure mode
Set the messenger to msgr2 and enable secure mode so that all post-authentication traffic between daemons and clients is encrypted with AES-GCM and checked for integrity. Configure monitors to listen on the v2 port, and verify that clients and gateways connect with secure mode rather than falling back to an unencrypted connection. Document the configuration keys you set and the client versions that support them, because older clients may fail to connect and teams often respond by weakening the setting. The step is complete when a packet capture between a client and an OSD host shows no readable payload and the cluster configuration matches the recorded baseline.
Enable at-rest encryption and confirm the key path
Enable encryption at rest for the OSDs that will hold CUI, and decide where the keys are generated, stored and escrowed. Confirm which key management service the cluster uses, who holds administrative rights to it, and how keys are rotated and recovered. Test the path end to end by writing a known string to an encrypted pool, reading it back, and confirming that the key is retrieved from the expected source. Encryption on the OSDs alone may not satisfy every control that covers stored data, so record which objects and buckets rely on encryption at the storage layer and which need application-level protection. The step is complete when the key path diagram and a recovery test are signed off.
Restrict RGW and Dashboard access
Limit who can reach the Ceph Object Gateway and the Ceph Dashboard. For RGW, create separate users for each application and administrator, scope their policies to the buckets they need, and confirm the S3 endpoints accept only the encrypted front-end you have configured. For the Dashboard, decide whether single sign-on through SAML 2.0 is used, and if OAuth2 is needed, confirm that cephadm runs the Management Gateway and OAuth2 Proxy services in your release. Remove default accounts and restrict the management network to named administrator hosts. The step is complete when an access review lists every human and service account, its scope and its owner, and an unauthorized client request is refused in a test.
Capture baseline configuration
Export the cluster configuration, the cephadm service specifications, the msgr2 and encryption settings, the release version, the CRUSH map, the pool definitions and the access lists into version-controlled files. Store a dated copy outside the cluster so that changes can be compared later. Record who approved each setting and the reason it was chosen. Assessors look for evidence that a configuration existed and was controlled, so the baseline should be readable without the cluster running. The step is complete when the baseline is committed, its hash is recorded, and a second administrator can reproduce the view from the files alone.
Run a verification test for encryption on disk and in transit
Run a test that proves data is protected in both places. Write a known marker to a CUI pool through a client and then search the raw OSD block devices for the plaintext; it should not appear. Capture traffic on the network path between the client and the OSD hosts and confirm that the payload is not readable and that the connection uses msgr2 secure mode. Repeat the test for an RGW bucket over HTTPS. Keep the commands, captures, timestamps and results as evidence, and repeat the test after each upgrade or key rotation. The step is complete when every test passes and the results are filed with the baseline. Consider engaging an independent assessor early to review the method, since a self-written test is only as strong as its design.
Settling the FIPS questions before you claim encryption
FIPS 140 validation belongs to a cryptographic module, not to Ceph as a product, so the section of your System Security Plan that covers 03.13.08 has to name the specific module that performs encryption for each data path. For Ceph at rest, that usually means finding out which library handles the dm-crypt or LUKS layer on each OSD host, whether a FIPS mode is enabled in the host operating system, and which libraries the Ceph daemons and the client tools call for cryptography. The same question applies to msgr2 secure mode, where AES-GCM is used by the Ceph messenger, and to any RGW server-side encryption or external key management you add. Each of these is a separate answer, and a claim that Ceph is FIPS validated does not settle any of them.
Start by asking your Ceph vendor or support channel, and your Linux distribution vendor, which cryptographic module each component invokes in your exact versions, and whether that module is listed as validated on the NIST Cryptographic Module Validation Program. Ask for the certificate number and the validated version, then confirm that the build you run matches the validated build. Check whether the validation covers the algorithms and modes you configure, and whether the module is operated in its FIPS-approved mode on your hosts. Record each answer with its date, because a host patch or a Ceph upgrade can change the module in use. DeployOpen can help gather this evidence and document the module boundary, but the validation status must come from the vendor and the certificate itself, not from our assumptions or from marketing material.
Settle these questions before you write 'encrypted with FIPS-validated cryptography' into a policy, an SSP or a CMMC assessment package. An assessor will ask for the certificate, the module version in production and proof of the mode setting, and an answer you cannot support will be a finding even if the encryption itself works. If a module cannot be shown to be validated for a given path, decide whether to change the configuration, accept the gap with a documented risk decision, or plan a remediation, and record that choice in the SSP. Any remediation that cannot be finished before assessment belongs in an explicit plan, because the CMMC rules discussed elsewhere on this page do not let an unmet requirement pass on a POA&M alone.
Questions buyers ask before engaging help on CUI at rest
What does help protecting CUI at rest on Ceph cost?
DeployOpen does not publish a price list, and a quote follows from a written scope. The main cost drivers are the number of clusters and sites in scope, how many storage pools and gateways hold CUI, where encryption keys are held and who controls them, and how much evidence the assessment needs. Ask for a quote that separates one-time work (architecture, configuration, key setup, documentation) from recurring work (key rotation, patching, evidence refresh, retainers for support or testing). Ask which items are fixed scope and which depend on what your team already has.
How long does a CUI at rest Ceph project take?
Duration depends mostly on the documentation you already have. If you hold a current system security plan, a data flow diagram, cluster configuration exports and access records, the work is largely verification and gap closure. If those documents do not exist, most of the time goes into describing the system and proving each control with evidence. Timelines are agreed in the written scope, so ask for milestones tied to specific deliverables rather than a single end date. Cluster count and whether you need a separate key management service also change the schedule.
What must our team provide before the work starts?
Expect to provide the following before design begins:
- A system architecture description covering clusters, sites, monitors, gateways and the hosts that run them
- A data flow diagram showing where CUI enters, is stored, is replicated or backed up, and leaves the system
- Access records for administrators, service accounts and the identity provider, including who can reach keys and the dashboard
- Current configuration exports, cephadm service specifications and network layouts
- Your existing policies for key custody, backup, incident response and change control
The more of this exists before kickoff, the less time goes to discovery.
Can our internal team protect CUI at rest on Ceph without a partner?
Yes, if your team already runs Ceph in production and has people who understand both the storage platform and the assessment method. The work splits into platform engineering (encryption configuration, msgr2 secure mode, key handling, access control), documentation (system security plan, boundary, data flows) and evidence collection that must be final and repeatable. Teams that lack one of these areas often use a partner for a fixed-scope review or a readiness check and keep operation in-house. Decide early who owns key custody, because that decision shapes almost every control in the assessment.
Does DeployOpen certify that our Ceph environment meets NIST SP 800-171?
No. DeployOpen plans, implements, hardens and documents systems and prepares evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. For CMMC Level 2, certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. Self-assessments are performed by the organization itself. Ask any partner, including DeployOpen, to state in writing which parts of the work are preparation and which are independent assessment.
Should we assess against NIST SP 800-171 Rev. 2 or Rev. 3?
For DoD contract work under CMMC, plan against Revision 2, because 32 CFR 170.14(c)(3) makes the CMMC Level 2 requirements identical to Rev. 2 and the Department of War said on 13 July 2026 that it will enforce Rev. 2 in the interim. A DoW Class Deviation signed 3 September 2026 also names Rev. 2 in the revised DFARS 252.204-7012 clause. Rev. 3 is the current NIST version, and a FAR overhaul proposed rule would move contractors to Rev. 3 with DoW-published parameters, but that rule was not final as of October 2026. Confirm the version in your contract and with your contracting officer, and keep a mapping that covers both.
What does a written scope need to say about key custody and evidence depth?
The scope should state where encryption keys live, who can create, rotate and revoke them, and whether an external key management service holds them. It should also define evidence depth: which configuration exports, logs, test results and interview records are collected, how often they are refreshed, and who signs off that each objective is met with final evidence. Ask whether the scope covers only the CUI enclave or the whole cluster, and whether backups, snapshots and multisite copies that hold CUI are included. Those boundaries determine both the price and the assessment result.
Which Ceph features will an assessor check for transmission and storage?
Assessors will look for cryptographic mechanisms covering data in transit and at rest, and for proof that they are configured and enforced. For transit, that usually means the msgr2 secure mode on the messenger, which encrypts post-authentication traffic with AES-GCM and adds integrity checks, along with TLS or equivalent on gateways and the dashboard. For storage, it means encryption at rest with keys under your control and documented key handling. Ask your engineers to show configuration output and test results for each path, because a feature turned on in one place does not prove coverage everywhere.
How DeployOpen works on this
DeployOpen plans, builds and documents Ceph storage for CUI at rest inside your own data centers or cloud accounts, with each control mapped to the NIST SP 800-171 requirements and the CMMC Level 2 assessment objectives your assessor will test. Engagements are fixed-scope, so the boundary, deliverables and evidence list are agreed in writing before any configuration begins.
How we scope
- Define the CUI system boundary, including which pools, buckets, RBD images and CephFS filesystems hold CUI and which do not.
- Record which requirement IDs, including 03.13.08 or SC.L2-3.13.8, each encryption and transport control is expected to satisfy.
- Agree in writing whether FIPS-validated cryptography is required, and list the open questions to resolve with your assessor first.
How we build
- Deploy the cluster with cephadm, enable msgr2 secure mode, and configure at-rest encryption for the storage layers in scope.
- Test that unencrypted fallback is blocked for CUI-bearing clients, and that key handling matches the documented key management design.
- Document configuration, test results and change records in a form that supports the assessment objectives and evidence in final form.
How we hand over
- Deliver a control matrix mapping each configuration to its requirement, with the evidence source and the person who maintains it.
- Provide runbooks for key rotation, certificate renewal, cluster upgrades and verifying encryption state after host or drive replacement.
- Hand over a SSP input package, along with a list of the controls that remain your organization's responsibility or your assessor's judgment.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, so configuration drift is caught between assessments.
- Re-verify encryption and transport settings after each Ceph release upgrade, using the same test set agreed during the build.
- Ask for a written quote that lists the scope, deliverables, retainer terms and any assessor or C3PAO fees, which DeployOpen does not set.
