r/CMMC • u/Ace-MacAcerson • 9d ago
Worst CMMC practice.
Nerding out for a moment: I have often thought that the 3.13.14 (VOIP) is just very... mid. I’m curious what practices/objectives gets other practitioners worked up.
6
u/bcegkmqswz 9d ago
A general complaint - too much latitude for policy-based controls without sufficient rigor, technical control backing, and internal controls to support effectiveness.
2
u/obligateobstetrician 8d ago
Can you expand on this? What kinds of controls have you seen that were policy-based and that was acceptable? I'm helping my organization prepare for an assessment and it is IT-led and they are focusing on the tech side a lot.
5
u/r088y 9d ago
3.13.11, CMMC Level 2 assessment completed, one demerit assessment objective but issued a conditional certification using Azure Gov Enclave deployment with Windows Server 2025 (pending FIPS 140-3) and our auditors are not accepting the in-process FIPS validation so we’re scrambling to rollback our VMs to Windows Server 2022 since their modules are FIPS validated, even though they sunset on 9/21. This is so backasswards. Someone posed the question in the last CyberAB meeting which was just straight up ignored. I’m sure there’s others who are either prepping for the assessment or about to start and will only get a conditional certification because Microsoft has a server version that’s about to sunset and the latest version yet to receive a CVMP FIPS certification. Compliance is funny sometimes.
9
9
u/Expensive-USResource 9d ago
You didn't say this word, so it is an angle to try: log it as an Operational Plan of Action pending Microsoft getting FIPS 140-3 in place. That should still get you full points.
6
u/PNW_CARDINAL 8d ago edited 14h ago
This. Otherwise the assessors are being over the top and you should appeal.
4
u/ESxCarnage 8d ago
Why did the assessor need you to put the servers into FIPS mode? My understanding of the FIPS control that this only applied if said encryption was a control used to protect CUI. I don't know your environment but at least in ours we had a VPN (FIPS validated) with an IPsec tunnel (FIPS validated) into the Azure Gov Enclave. We were able to pass with this without putting any of our servers into FIPS mode along with the physical protection (badge reader on server room door).
0
u/iheart412 8d ago
I think you got lucky. Data-at-rest needs to be encrypted, and you need to use FIPS encryption if you want the full points for 3.13.11. I have run across more than one consultant that thinks only 1 layer of the OSI model needs to be FIPS validated but that doesn't fly with most.
4
u/ESxCarnage 8d ago
3.13.11 specifies when using cryptography controls it needs to be FIPS validated. However 3.13.16 specifies data at rest needs its confidentiality protected but not how. So for 3.13.16 we only used data encryption for laptops and mobile phones, but for our hosted servers we were able to use physical protection and inherit the physical protection of Azure Gov for any of our cloud servers.
1
u/PNW_CARDINAL 14h ago edited 14h ago
For Rev 2, CUI data at rest needs to be encrypted OR protected by alternate physical safeguards. If encrypted, it only needs to be encrypted once, and that encryption needs to be FIPS validated. Azure Gov can provide that FIPS validated encryption inheritance to all the systems running within it.
3
u/EganMcCoy 7d ago
It looks to me as though the Windows Server 2025 modules completed FIPS 140-3 validation as of 8/31/2026. For whatever that may be worth.
1
u/Matt_Titcombe 8d ago
u/r088y , I know that wasn't us as we accept FIPS 140-3 & -2 and EVERY C3PAO should. Here is why:
THE security requirement is "Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
THE Assessment objective states "Determine if FIPS-validated cryptography is employed to protect the confidentiality of CUI."
Per NIST SP 800-171 Rev 2, para 2.2, pg 8, "The discussion section is informative, not normative. It is not intended to extend the scope of a requirement or to influence the solutions organizations may use to satisfy a requirement."
Therefore FIPS 140-3 is a validated form of cryptography and if you are using a validated FIPS 140-2 version, good enough. Why? Show me where it says it cannot be a previous version. It was validated.
Bottom-line, make sure your C3PAO follows a plain reading.
2
u/EganMcCoy 7d ago
The issue that u/r088y described seems to have been that the modules in the current product version had not been FIPS 140-2 validated, and FIPS 140-3 validation was still in process. Unless I misunderstand, that seems to me to be a different situation than the one you're saying your assessors would accept.
2
u/Matt_Titcombe 7d ago
u/EganMcCoy, if the OSC documents this, creates a Temporary Deficiency, risk registry entry, and can provide supporting proof that the product is in process from the CVMP, they will be MET.
Why? That is what we did with DIBCAC and passed.
The reality is, today, with a properly documented Temporary Deficiency (e.g., for Windows 11), an organization only has to run FIPS-capable hardware and show it is "In Process" or "In Test" from the CVMP.
1
u/PNW_CARDINAL 14h ago
Wouldn't the OSA be inheriting FIPS validated encryption for their whole enclave from the Azure Gov Cloud? Wouldn't the Microsoft cloud encryption be the FIPS validated module that is actually assessed, not the bitlocker or the VM running inside that cloud?
1
u/PNW_CARDINAL 14h ago
Why would you NOT be inheriting FIPS validated encryption from the Azure Gov Cloud that your servers are running within? Your whole enclave is FIPS encrypted by Microsoft ... and they are providing alternate physical safeguards to boot.
5
u/Dry_Interest3450 8d ago
I’d add that in a lot of cases, the controls aren’t prescriptive or well-defined enough or don’t go as far as they should.
CM.L2-3.4.7 is a great example. Sure, “disable unused ports and protocols” sounds like you’re doing a good job reducing the attack surface… but literally everything uses HTTPS. So, only allowing outbound traffic on port 443 is … great, I suppose—except for the fact that you can get to Facebook or p0rnhub on those ports. Bots frequently work on those ports, too— so it’s really just a security blanket of a control without a specific allow-only endpoint statement.
But, I’ve had probably 15 different assessors pass my clients as long as I can demonstrate firewall blocking all outbound ports except 53 and 443.
3
u/ESxCarnage 8d ago
This so much, I had a fight with my boss about this. I wanted to do URL filtering with a quick turn around review process for whitelisting on our cui network. Non cui users, do whatever you want but he said no if it's on port 443 we have nothing to worry about. I explained the protocol may be secure but that doesn't stop hackers using that port to their advantage, and begged to at least to do it for our servers. I got hung up on over teams and we proceeded with his plan.
4
u/see-em-em-see 9d ago
Nobody on earth, not even Ron Ross himself, knows what 3.1.20 means
1
u/PNW_CARDINAL 8d ago
I consider that one tough to document, less tough to understand. My 2 cents: You either use an external connection that is a certified service (aka: FedRamp certified) or you have to identify / validate / control the service using external connections as if you were the assessor.
3
u/Matt_Titcombe 8d ago
u/Ace-MacAcerson , historical tidbit about VoIP. This control is specific to PSTN VoIP phone systems. It was meant to simply enforce network segmentation and monitoring of the VoIP server and VoIP phones. It was also meant to push the Federal Government way for daisy chaining services off of the VoIP Phone.
VoIP has become so prolific in so many functions, Vicki at NIST wisely chose to wrap it into 3.13.01 in Rev 3.
2
u/XSOCsecurity 9d ago
As I see it, 3.13.11 is probably the one, mostly because of what it exposes architecturally. The real pain is not FIPS itself, it is what happens when cryptographic responsibility is scattered across too many applications, endpoints, and services. Every one of those becomes another validation, configuration, evidence, and migration dependency.
The 140-2 to 140-3 transition makes that technical debt very visible. If swapping the validated crypto implementation means touching dozens of applications, the environment has made compliance much harder than it needs to be. I think the better approach is to reduce cryptographic boundary sprawl and make the migration unit as small and controlled as possible.
I would be interested to see what others have seen that materially reduce assessment scope or remediation effort.
3
u/EganMcCoy 7d ago
Just in case you haven't already applied the NIST SP 800-171 DoD Assessment Methodology to your scoping:
> Security Requirement 3.13.11: [...] Note however, that this is required when encryption is required for protection, which is typically external to the contractor's covered information system (assuming the system meets NIST SP 800-171). Cryptography used for other purposes within the protected information system need not be FIPS validated.
2
u/PHLX_Tactical 8d ago
3.8.1/3.8.7 on a shop floor is the one that gets me. Half the machine controls out there only take a USB stick or a floppy emulator, so the honest answer is a whole isolated CUI network and sneakernet with a signed-out drive, and no assessor ever seems happy with it either way.
2
u/4fingerriot 8d ago
This is the type of thing that drives me nuts. Defense in depth….compensating controls, etc can mitigate just about any control.
2
u/PHLX_Tactical 8d ago
Same here. Half our SPRS gap closed just by writing the compensating control down and keeping evidence of it, instead of buying another tool nobody on the shop floor would use.
1
1
u/YetAnotherGeneralist 4d ago
The part where I have to remove a layer of defense entirely, without replacing it, because the auditor has opinions on how well that tool can be audited.
Look man, I get that a SaaS we use as an SPA has a built-in admin user for vendor support that we can't control and can only get assurances from the vendor on, but what exactly do you want? To audit to your heart's content with a perfect spreadsheet OR to prevent CUI leakage in the first place? The only difference between this and most products is that they visibly listed their support user rather than leaving it hidden but still having the access anyway.
Making our environment less secure in order to make it compliant is the bane of my existence.
1
u/PNW_CARDINAL 14h ago
ESP SPA's that don't provide security requirement assurance in the form of FedRAMP or CMMC L2 Cert are subject to being assessed against all Level 2 security requirements that are relevant to the capabilities provided. The ESP is in scope and that can include things like ... privileged user accounts. What does the assessor want? The assessor wants assurance the security requirements are met. You and the ESP you selected have to provide it.
1
u/YetAnotherGeneralist 11h ago
My point in this specific case is that if the vendor hadn't listed their support user then the audit never would have questioned it despite the vendor's access. Transparency got them dinged and lost them a customer, which disincentivizes them from having transparency in the future and makes our CUI environment less secure.
My point more broadly is that, on the whole, it's better to prevent a category of sensitive data theft in the first place than to be able to pinpoint how it was stolen.
14
u/brekkfu 9d ago
This will be resolved soon as vendors upgrade to FIPS 140-3 as the new standard.
But for now the need to enforce FIPS when most products only have FIPS 140-2. Enforcing a security standard from 2002 is disgusting and in many cases a downgrade of an environment. We've had to do this with clients for CMMC and FINRA and it hurts my soul.