FIPS 140-3 is not a security guarantee, and auditors know it
1–10 of 30 posts
Re: FIPS 140-3 is not a security guarantee, and auditors know it
#2[dead]
Re: FIPS 140-3 is not a security guarantee, and auditors know it
#3Why does the tone have to be ragebait? This is just a basic overview of what compliance looks like.
Re: FIPS 140-3 is not a security guarantee, and auditors know it
#4Huh, I don't know about the world of HSMs or crypto and their audits, but in FedRAMP SaaS, you absolutely have to run everything with FIPS mode enabled, there are strong guarantees that need to be in place and audited.
Re: FIPS 140-3 is not a security guarantee, and auditors know it
#5Why does the tone have to be ragebait? This is just a basic overview of what compliance looks like.
because for most use cases FIPS-140 have been waste of time for everyone involved
Re: FIPS 140-3 is not a security guarantee, and auditors know it
#6Why does the tone have to be ragebait? This is just a basic overview of what compliance looks like.
At this point, I'd rather be waterboarded than do any more compliance. Especially in this heat.
Re: FIPS 140-3 is not a security guarantee, and auditors know it
#7Huh, I don't know about the world of HSMs or crypto and their audits, but in FedRAMP SaaS, you absolutely have to run everything with FIPS mode enabled, there are strong guarantees that need to be in place and audited.
If the requirement causes a massive security hole, the lawyers will probably tell you that knowingly allowing a security hole from a liability perspective is worse than turning off something an audit will flag.
Re: FIPS 140-3 is not a security guarantee, and auditors know it
#8Huh, I don't know about the world of HSMs or crypto and their audits, but in FedRAMP SaaS, you absolutely have to run everything with FIPS mode enabled, there are strong guarantees that need to be in place and audited.
> That lag creates a perverse choice every vendor of validated modules eventually faces: ship the security fix now and fall off the validated list for a year or more, or keep shipping the validated build with the known flaw. Customers whose contracts require an active certificate are, in effect, paying the vendor to choose the second option.
That's what the blog post says about why/when FIPS is turned off, although I'm not sure I completely agree with this take. All forms of compliance in all industries (not just IT) is like this. Otherwise we get a lot of cowboy solutions.
This is why compliance does not operate in a silo. There's the baseline (when FIPS is on) and then there's the real world configuration that the business must carefully accept along with its own risks. This is why you have your own employees auditing and collaborating with everyone else involved in the decisions. That can often include the client wanting your services that depend on the HSMs. I'm not understanding what all the frustration is about unless some people have just never left their silo.
If your client is the government, then of course they're going to be very strict about FIPS. We're all at least in agreement that FIPS sucks because it moves at a glacial pace. There's a reason the phrase: "good enough for government work" means mediocre.
Re: FIPS 140-3 is not a security guarantee, and auditors know it
#9Huh, I don't know about the world of HSMs or crypto and their audits, but in FedRAMP SaaS, you absolutely have to run everything with FIPS mode enabled, there are strong guarantees that need to be in place and audited.
FedRAMP actually has a bunch of workarounds for the problems of FIPS.
In the "FedRAMP Policy for Cryptographic Module Selection and Use" (https://www.fedramp.gov/resources/documents/FedRAMP_Policy_f...), there are a ton of gems that make it clear that the FedRAMP folks are fed up with the CMVP process backlog. The most explicit is:
"FRR9: CSPs shall determine if updating to a newer version of the software, whether or not its cryptographic modules are FIPS validated, would eliminate the vulnerabilities; if it would, CSPs shall promptly update if that is feasible."
Re: FIPS 140-3 is not a security guarantee, and auditors know it
#10Huh, I don't know about the world of HSMs or crypto and their audits, but in FedRAMP SaaS, you absolutely have to run everything with FIPS mode enabled, there are strong guarantees that need to be in place and audited.
FedRAMP actually has a bunch of workarounds for the problems of FIPS. In the "FedRAMP Policy for Cryptographic Module Selection and Use" ( https://www.fedramp.gov/resources/documents/FedRAMP_Policy_f... ), there are a ton of gems that make it clear that the FedRAMP folks are fed up with the CMVP process backlog. The most explicit is: "FRR9: CSPs shall determine if updating to a newer version of the software, whether…
How is that “a problem with FIPS?”
In layman’s terms that basically says if there’s a 0-day, patch first and we’ll worry about validation later.
You could say that’s “an issue” with literally every software package that has a support contract on earth. I can’t count how many times in my career we had to apply a patch release that wasn’t “officially ga” because of a zero day. That’s common sense, not a FIPS issue.