FIPS compliance should be used when the customer demands FIPS compliance, and at no other time. It does not make your software more secure. The federal government has many reasons for its Information Processing Standards, and actual security isn't high up the list.
> FIPS compliance is a great idea that makes the entire software supply chain safer
Yes, gotta implement that Dual_EC_DRBG compatibility.
FIPS compliance is not a great idea, the benefits are questionable and possibly nonexistent. It's also significantly worse advice than simple "implement decent modern crypto", you can do all kinds of really bizarre stuff and still be FIPS compliant.
>FIPS compliance is not a great idea, the benefits are questionable and possibly nonexistent.
I counter about the benefits of FIPS. If you don't do it, you don't get paid by the government for whatever contract you have. Many people find getting paid to be beneficial.
Now, it's not the vast majority of applications, but I'm sure there are a significant number of developers on HN that are working on applications that need to meet FedRamp requirements and posts like this point out potential pitfalls on what needs enabled.
Not much different when dealing with stuff like STIGs. A large number of them are highly questionable and may only apply to very specific applications, yet you see barely trained button pushers saying you need to follow them. If you're aware of them when writing your application it will save a bunch of implementation headaches when it ends up in the field.
FIPS is what happens when idiots get promoted and start reading too much LinkedIn CISO slop.
If a customer demands FIPS compliance charge them out the ass for it. Its not inherently secure, it requires in some cases massive re-engineering of product and toolchains, and mostly seems to be an ask from clueless deep pocketed Fortune 500 companies looking to minimize liability claims after a breach by being able to point at their FIPS compliance.
FIPS compliance should be used when the customer demands FIPS compliance, and at no other time. It does not make your software more secure. The federal government has many reasons for its Information Processing Standards, and actual security isn't high up the list.
> FIPS compliance is a great idea that makes the entire software supply chain safer
Yes, gotta implement that Dual_EC_DRBG compatibility.
FIPS compliance is not a great idea, the benefits are questionable and possibly nonexistent. It's also significantly worse advice than simple "implement decent modern crypto", you can do all kinds of really bizarre stuff and still be FIPS compliant.
>FIPS compliance is not a great idea, the benefits are questionable and possibly nonexistent.
I counter about the benefits of FIPS. If you don't do it, you don't get paid by the government for whatever contract you have. Many people find getting paid to be beneficial.
Now, it's not the vast majority of applications, but I'm sure there are a significant number of developers on HN that are working on applications that need to meet FedRamp requirements and posts like this point out potential pitfalls on what needs enabled.
Not much different when dealing with stuff like STIGs. A large number of them are highly questionable and may only apply to very specific applications, yet you see barely trained button pushers saying you need to follow them. If you're aware of them when writing your application it will save a bunch of implementation headaches when it ends up in the field.
FIPS is what happens when idiots get promoted and start reading too much LinkedIn CISO slop.
If a customer demands FIPS compliance charge them out the ass for it. Its not inherently secure, it requires in some cases massive re-engineering of product and toolchains, and mostly seems to be an ask from clueless deep pocketed Fortune 500 companies looking to minimize liability claims after a breach by being able to point at their FIPS compliance.