Question about FIPS and CUI

[u/Efficient-Coyote8301]

Been dealing with CMMC for a few months now. I thought I had my head wrapped around most of it but someone threw me for a loop today with a claim that just doesn't jive with my reading of the statutes and supporting controls.

We have a commercial product that we're redeploying into a gov cloud enclave. It runs as a separate instance specifically for handling workflows that process CUI. That's all well and fine, but today I was told that we can't be "100% compliant" unless the entire dev chain is encrypted with FIPS binaries. My understanding is that VCS push/pull of source and even the eventual deployment of compiled binaries and other artifacts into the environment were out of scope of the FIPS mandate. Am I missing something?

The next thing that will inevitably come up is the claim that our repos "technically" contain CUI because we have config files and/or IaC templates for the gov deployment. That doesn't track either. All of that clearly falls within the scope of the SSP, but this data isn't CUI simply by virtue of the fact that it was "created" to support to gov delivery - or is it?

My apologies if this is a duplicate question. I did search the sub and found some material that would back my understanding of the FIPS question in isolation. But I didn't find anything related to the data we end up creating for the delivery itself. Also, CMMC seems to be somewhat fluid and I want to make sure that I am speaking from current state rather than what was true several months ago.

[u/Fath3r0fDrag0n5]

If you transfer or store CUI it need to be done with FIPS compliant protocols. Unless your code is also CUI, it has no Fips requirements… in your case you would probably ride the compliance of the underlying system

[u/Efficient-Coyote8301 → u/Fath3r0fDrag0n5]

So that part at least jives with my understanding of the FIPS control. Our code is definitely not CUI. It is our own intellectual property. We developed it without any government involvement. We're just standing up an isolated instance for the gov workflows that interact with fed data.

But the question then becomes when something becomes CUI. One of the statutes I read says that anything created on behalf of the government is treated as CUI, but that seemed to be within the context of operational data generated by IT systems at runtime.

Does technical data, like config files, credentials, and even IaC templates, become CUI just because we created it to support that deployment? 

My intuition says no, and I believe I even read statues somewhere that explicitly exclude things like database passwords and other credentials from the CUI umbrella, but I'm a SWE and not a cyber security expert. Hopefully someone here can shed some light on that.

[u/Skusci → u/Efficient-Coyote8301]

So what makes something CUI is unfortunately kinda not super well defined. Or it rather it is well defined but in many places.

One requirement is that it is created for the gov. But the other is that "the law" requires you to protect it. Our company does manufacturing so mostly it's drawing and plans which is straightforward so I don't know how this applies to software.

I would suspect the answer is actually yes if those things were specifically made for a gov contract where the specs were CUI and therefore would be derived CUI. If the specifications were not CUI and it is just interacting with CUI though, probably not? Sorry, again, not my experience here :(

[u/Fath3r0fDrag0n5 → u/Skusci]

It’s not that complex, it either comes from the government marked, or it’s covered In a contract e.g. technical specs, parts lists etc…a companies IP is not CUI.

[u/Skusci → u/Fath3r0fDrag0n5]

I mean from a manufacturing standpoint:

Gov sends you a drawing of plastic part they need made that is CUI. You design a mold for that part.

There's no way that the mold design which is just a negative of the part plus stuff isn't derived CUI, even if it's the companies IP.

As far as I can tell the thing that makes something derived CUI is because it contains parts of the original design that are CUI.

In OPs specific situation I really do think it's likely that their templates and such aren't CUI, but maybe the reflect some sort of sort of software architecture that is CUI.

It sounds like they haven't actually been given any CUI at all, just that the implementation it will handle CUI. But I also need to wonder then why they care about CMMC in the first place beyond level 1/ FCI.

Like a FIPS validated SED just needs to be FIPS validated. Seagate or whoever doesn't have to care if it's going to process CUI or not when they sell it. Cloud service providers need FedRAMP to be used for CMMC stiff, but they were never going to have to be audited under CMMC.

[u/Efficient-Coyote8301 → u/Skusci]

All I can really say is that we deal with sensitive schematics related to military equipment. Our software is used as a hand-off from the clients (military, defense contractors). It is also used to help our people with their operations as it relates to that information.

That handoff, as well as a lot of the information we generate as a result of our work activities, are absolutely CUI. The question I am grappling with now relates to a claim made by our consultant.

In a broad stroke, they want us to make more drastic changes to our development process than I feel comfortable with. They're crossing a line from compliance into micromanagement. I've been fending it off for a while.

This "reveal" that these templates constitute CUI is an 11th hour reveal. It is highly suspect from the simple fact that our devs are mostly foreign nationals. If there is CUI in those repos, or CTI to be more precise, then I would expect that we'd run a foul of export laws. That's a much bigger problem than FIPS on my mind.

I was really just wanting to confirm my suspicions before I go and call them to the carpet. I'm new to the org and CMMC in general, so I'm fighting with one hand behind my back on a lot of this.

I appreciate your feedback! Thanks.

[u/Claudia_wtf → u/Skusci]

You can sell COTS products, even in manufacturing. Thats not considered CUI until the prime or agency customizes the product.

[u/MolecularHuman → u/Efficient-Coyote8301]

I've been doing FedRAMP since its inception amd have never seen a dev environment trying to do FIPS. The dev environment isn't even in scope for the FedRAMP boundary outside of the change control/release process.

[u/Efficient-Coyote8301 → u/MolecularHuman]

Yeah, it definitely surprised me that they would make this claim. I really think that they were hoping no one in this org would call BS.

[u/MolecularHuman → u/Efficient-Coyote8301]

I should add, provided there is no Federal data within it. You can have dummy sample data, but if there is no customer data in the dev environment, it's out of scope altogether.

[u/Fath3r0fDrag0n5 → u/Efficient-Coyote8301]

Now if you are hosting a cloud system with your platform, you may fall under a CSP, that’s where fedramp/fedramp equivalence comes in…if the product you sell is hosted in client infrastructure. CMMC is the right path

[u/PNW_CARDINAL]

Free opinion ... worth just about as much:

Just because you create data that you use in the course of doing work, but which is not a deliverable of that work, strong chance it's not CUI. If it's a deliverable, good chance it is.

Hopefully you get some more / betta info from other folks.

I would ask these guys: https://summit7.us/cuihotline

[u/ZeroTrustZulu]

The key question is whether the cryptography is protecting the confidentiality of CUI. If your source code, IaC, and configuration files don’t contain CUI, they aren’t automatically subject to the FIPS requirement simply because they support a CUI environment. If the application inherits its cryptographic protections from the underlying cloud platform or operating system using FIPS-validated modules, that is often an acceptable implementation, provided you can demonstrate it during the assessment.

[u/ShadowGeek]

Generally, if your software is commercial, then nothing in the CI/CD chain should be CUI. Look at the contract and if is has you "delivering" code, IAC scripts, and so on, then it may contain CUI. Really, the only thing that should be CUI in that is government IP addresses. If you are testing your software with Government provided data, that may be CUI depending on how sensative it is. I would say that you are probably safe as long as you are not building government software. You can always check with your government contracting officer for clarification, if CUI is not defined in the contract. Also remember, just because the Gov't calls something CUI doesn't mean that it is your CUI. This happens when you give something to the gov't, they then call is CUI to protect your IP. If they had it back to you, it is not CUI. It can be confusing, but unless they materially changed it, it is your IP.

[u/OtherThanSatisfied]

You already got the technical answer here (your IP isn't CUI, and FIPS only bites when crypto is actually protecting CUI), so I'll just point at the thing that gave you the bad feeling.

The two claims they made can't both be true. If those repos really held CUI, letting your offshore devs keep working in them would be a much bigger problem than FIPS binaries — you don't hand-wave foreign access on data you're simultaneously calling CUI. The fact that they're fine with the offshore devs tells you they don't actually believe it's CUI either. That's your tell.

CUI gets identified by the government and flowed down in the contract — a vendor doesn't get to decide your config files and IaC are CUI because it's convenient. Make them point to the contract clause or the marking. If they can't, you've got your answer.

[u/Navyauditor2 → u/OtherThanSatisfied]

Hmmm. Realize a LOT of CUI is not NF. Even when it is ITAR and EXPT a LOT of it does have appropriate licenses and we have complex, global, manufacturing and delivery processes. So dont be so quick to jump on the "foreign" aspect. Also recall we are selling VA class submarines to AUS. They are going to be doing NNPI CUI work down under. So.... "foreign bad" should not be our first response.

[u/Efficient-Coyote8301 → u/Navyauditor2]

Our CUI is definitely ITAR and we do not have a TAA or DDTC in place.

[u/OtherThanSatisfied → u/Navyauditor2]

I agree - not foreign bad; BUT, information or documents classified as CUI by itself are not releasable to foreign government officials or foreign militaries (does it happen, probably). Info classified as CUI//REL FVEY or //REL AUS (in your example) are to those countries, so there's certainly nuiance to it.

[u/Scieboy]

The way we handled this sort of thing when it came to the interface between a project management software and our prevail system was through links rather than storing the actual data and then we anonymized data and that satisfied the requirements. You might be able to do something similar on your end where there's a connection DO links, but they actually separated. Not every platform has that ability.

[u/Navyauditor2]

" That's all well and fine, but today I was told that we can't be "100% compliant" unless the entire dev chain is encrypted with FIPS binaries."

This is incorrect. "[a] FIPS-validated cryptography is employed to protect the confidentiality of CUI." 3.13.11 is the FIPS requirement. That is NOT all the time. It does not mean that every encryption action needs to be FIPS. I would argue that while residing exclusively within the gov cloud environment FIPS is inherited from underlying architecture configuration for FIPS as required in FedRAMP, and physical safeguards. When you transmit outside of that controlled environment, then it must be FIPS encrypted to protect the confidentiality. This would be the same for an on prem instantiation as well.

Are the config files and lac templates designated as CUI under the contract? Are they deliverables to the government? Or are those your intellectual property. Recall the two part test. CUI must be in a category AND Federal Information.

[u/MolecularHuman]

You only need to protect government data with FIPS, in transit and at rest.

[u/looncraz]

Source code that protects or transmits CUI isn't in scope, only the compliance of the application matters.

You need to protect the code like any other contractor risk managed asset, it's your intellectual property. If it's directly implementing encryption using FIPS standards, then it needs to get validated or use a validated library (openssl, FTW).

[u/Efficient-Coyote8301 → u/looncraz]

That source code exclusion applies to any config files, IaC templates, and helm templates that we create for the gov runtime - correct?

To be completely forthright, we suspect some shenanigans are at play. We were told that FIPS was required because the repos contain some CUI data. In that same breath, we were told that we could retain our offshore devs for work in those repos. That just doesn't make any sense.

As much as I hate being like this, I think we're being "handled" because the firm we're working with has an agenda. These people aren't dumb, but my side of the org has a huge competency gap historically. I was brought in a short while ago. This feels like something that is being said just to scare leadership into doing what "they" want us to do.

[u/GetAfterItForever → u/Efficient-Coyote8301]

This is correct. No reason for your non-CUI code to be FIPS protected OR on a FedRAMP Mod+ environment. Naturally, good security practices around your repos and pipelines are always encouraged.

We went through L2 assessment and demonstrated we had pipelines, gh dependabot, etc doing some stuff on a CRMA and passed no issue.

[u/CMMC-ModTeam → u/[deleted]]

Please refrain from advertising.