Perhaps never a true guarantee, but level 4 HSMs are still impressive.
> The 4769 HSM has been verified to meet the FIPS 140-2 Level 4 requirements by protecting against attacks that include penetration of the secure module, side-channel attacks, and environmental failure protection (power or temperature manipulation). From the time of manufacture, the hardware is fully self-protecting. If tamper sensors detect a possible attack, all critical keys and other sensitive data are immediately destroyed and the HSM is rendered permanently inoperable. Note therefore that the 4769 HSM must be maintained at all times within the temperature, humidity, and barometric pressure ranges specified.
Huh, 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."
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.
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.
> 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.
> The 4769 HSM has been verified to meet the FIPS 140-2 Level 4 requirements by protecting against attacks that include penetration of the secure module, side-channel attacks, and environmental failure protection (power or temperature manipulation). From the time of manufacture, the hardware is fully self-protecting. If tamper sensors detect a possible attack, all critical keys and other sensitive data are immediately destroyed and the HSM is rendered permanently inoperable. Note therefore that the 4769 HSM must be maintained at all times within the temperature, humidity, and barometric pressure ranges specified.
https://public.dhe.ibm.com/security/cryptocards/pciecc4/docs...
My friends in Christ, a aerodynamic object need only contend with 7 degrees of freedom, and occasional take-offs and landings.
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."
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.
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.