hckrnws
This is the un-fun work needed to get open source software into many different parts of the enterprise and government. It's not fun, and sometimes it's not even very difficult, but its usually very tie consuming and full of arcane knowledge.
Signed, someone who was dropped a big application and asked to make it FIPS compliant ASAP.
Open, closed, it's all a bunch of fun getting working in FIPS mode. Especially 3rd party applications. They'll call a library, that calls a library that uses something not compliant.
While FIPS is a pain in the ass, can show you potential failures your software has with using ancient crypto methods that are easy to enable and completely compromise the security of your software.
but i think there's some requirements in FIPS that are really just checkbox rather than actual security. I suppose it's easier to have a list of checkboxes to tick from a compliance perspective.
> “FIPS mode” is a thing provided by OpenSSL that, well, makes it more secure
A well-configured system would either be unchanged or be made less secure by enabling FIPS mode. Nobody should ever use it without a legal requirement to do so.
How would it become less secure? Because newer crypto algos aren't in the set allowed by FIPS?
FIPS usually implies a bunch of counterproductive architectural decisions and makes it harder/slower to produce security patches.
Also, FIPS used to mandate support for an almost-certainly-backdoored cryptographically secure random number generator, and continued to do so well after it was obviously flawed:
FIPS is designed for standardization/predictability/interoperability not Security.
The only reason to turn it on is if you have a regulatory requirement to do so.
Last time I had a FIPS project, which is a long old time now, activating FIPS mode meant disabling weak ciphers but it also meant disabling stuff like DH/DHE key exchange.
It seemed to be like that because it's government, and they may want to decode their traffic at a future date, for auditing or leak detection, so 'PFS' measures were not allowed.
I am talking about FIPS 140-2 though, and almost 20 years ago!
It was still the case a few years ago. I remember working on a client-server application and documenting FIPS requirements hasn't changed all that much.
Lots of reasons. Yours is one, and another is that FIPS disallows you from patching security vulnerabilities in a timely manner.
There is also a large difference between FIPS compliant and FIPS certified. The former is running in FIPS mode and the latter is running a cryptographic module that has been inspected and verified by the CMVP.
And then the whole thing is really terrible security theater as you are technically out of certification if you apply any non-inspected updates.
> And then the whole thing is really terrible security theater as you are technically out of certification if you apply any non-inspected updates.
The days when FIPS compliance required using relatively weak ciphers and modes were lamentable. But all the other tedious box checking work arguably shows that cipher bike shedding is the real security theater. If you don't have a plan--and follow that plan--to track software origins and updates, or an ability to quickly resolve dependency issues that make it difficult to refactor or even update your systems, then you have much bigger problems than whether your latest software is using the Noise protocol or has migrated from BLAKE2 to BLAKE3.
Which is not to say that maintaining FIPS certification or FedRAMP compliance equates to good security. It's trivial to identify simplifications that would result in better operational security. But the vast majority of projects and organizations struggling to meet those standards are struggling precisely because their security posture is horrendously poor when looked at comprehensively.
The saying goes something like.
Good operational security will get you through times of bad crypto. But the converse is not true. Good crypto will not save you from bad opsec.
The typical person with a geeky interest in security will dig their heels in quite a bit when faced with the reality that most effort does, and should, go toward boring operational opsec.
OpenSSL 3 made a huge improvements in getting oneself FIPS certified, by isolating the FIPS-covered code to small auditable module that doesn't have to be updated all that much, thus letting you update OpenSSL in general while retaining CMVP-verified crypto.
Now, getting it into some of the open source code was a PITA, especially when you have things like components that depended on MD5 somewhere...
I’ve heard this approach called the “draw an imaginary and arbitrary box in your architecture diagram” approach to FIPS compliance.
Fun fact: the fips compliant stuff doesn’t have to be on the data path if you draw the rectangle correctly.
In other news, my smart refrigerator has military grade encryption, so no one can steal my sandwich.
>And then the whole thing is really terrible security theater as you are technically out of certification if you apply any non-inspected updates.
FedRAMP now prefers to use non-certified updates to been certified but vulnerable. Especially when fips module comes from company that has a "proven track record of obtaining certification"
curious to know which roles in an organization require a deep understanding of technical standards like FIPS or ISO. Is it typically expected of entry-level engineers, senior engineers, principals, tech leads, and/or project managers?
Have you ever needed to immerse yourself in a FIPS or ISO standard? Was it out of necessity for a project (just-in-time learning), or do some of you explore these standards in your spare time?
These standards are complex and mastering them is no small feat. It's interesting that people don't often brag about this expertise on their resumes. Have you ever listed such standards as part of your skill set? Why or why not?
I'm eager to hear your experiences and insights. How has your understanding of these standards impacted your career or projects?
Oooo for once, my time to shine! Or maybe, my time to shine???
> Is it typically expected of entry-level engineers, senior engineers, principals, tech leads, and/or project managers?
Working at a company that provides FedRAMP-approved services, the knowledge of FIPS within the company is a bit sparse. InfoSec definitely needed to understand it in order to explain to developers that they have to use BouncyCastle over the default java crypto provider, etc, but it took someone else to _really_ understand it and tell InfoSec that they were initially asking for the wrong thing.
Entry-level? No. Senior? At least minimal understanding of how cryptography works in their language of choice and the impact of FIPS. Principal? Same Tech leads? Not a well-defined role. Probably. Project managers? No.
> Have you ever needed to immerse yourself in a FIPS or ISO standard?
Yes. Multiple times. I argue with third-party auditors and the FedRAMP Joint Advisory Board about interpretation of these standards.
> Was it out of necessity for a project (just-in-time learning), or do some of you explore these standards in your spare time?
Necessity. See FedRAMP. However I can say ISO8601 was just for fun. ISO8601 gang represent!
> These standards are complex and mastering them is no small feat. It's interesting that people don't often brag about this expertise on their resumes.
I've seen a couple people who listed those standards or similar (FedRAMP again). Given the choice between two identical candidates while one has FedRAMP/FIPS/ISO experience I'll pick the one listing the standards.
> Have you ever listed such standards as part of your skill set? Why or why not?
I've not updated my resume since acquiring skills in the relevant standards but will probably include them when I do update my resume. They're a specialization that commands a premium when it comes to salary, if you're willing to work in the industries / companies that play in that space. Some people wouldn't include it because they truly hate working with rigorous standards.
> How has your understanding of these standards impacted your career or projects?
Understanding them has certainly proved to be a benefit to my career given how closely I work with them.
Great reply. I have some follow-on questions -
Would you market yourself as an expert on these in a job search or as a developer etc, with additional expertise? Is this an area where companies typically need people full-time, or is it better suited to short term contracts?
As someone with experience in this myself: It depends on where you want to be in the foodchain.
This comes up with companies that need to meet these standards to sell to someone in the Federal space (or someone who is selling to someone in the Federal space). They need to certify their products and maintain some level of certification.
You can be a consultant who helps companies get their products through an initial certification. You can be a full time employee who executes on designs and makes sure that no invariants get violated (which, after certification, would be a small amount of normal maintenance duties). Or you can work for a certification lab, since all of this is outsourced to a cottage industry of private companies!
This is pretty spot-on.
I work in the K-12 education sector. In basically all jurisdictions this industry is not specifically regulated, but there’s an increasing trend of B2B customers enforcing these standards as contractual requirements. This is usually at the behest of their controlling authority, which is often a government, but it’s not out of the ordinary for non-government / private school systems to do the same. Contractual obligations can get quite onerous, just as you’d expect from B2B engagements in other sectors.
This blindsided our then-little edtech startup. Thus I’ve been reading ISO 27001, legislation, and all manners of utterly deranged security questionnaires since way back when I was much to green behind the ears to have any right doing so, often with little oversight. On the odd occasion where we have called in external help, supposed specialist consultants have had absolutely zero idea what they’re talking about.
I don’t expect that a typical junior engineer or even mid-level engineer, even working in a highly regulated industry, could possibly be expected to, say, understand ISO 27001. Perhaps understanding their organisation’s operationalising of compliance? But I doubt the standard itself. There a whole lot of big-picture thinking, discretion, understanding how organisations work, etc, to operationalise ISO 27001 well.
An organisation that does a good job of this would definitely need some sort of cross-functional team, as there are wider organisational implications. That’d certainly include someone/s with a level of technical understanding.
I’m a pretty good fake lawyer, a good reader / writer, read legislation for fun, etc. I tend to be pretty good at the bigger picture stuff. Yet I can’t in a hundred years imagine attempting to ingest ISO 27001 without doing so in service of an immediate goal (e.g. implementing it). It’s so incredibly abstract by itself, that I’d be truly impressed if an engineer ‘self-taught’ to increase their worth to a future employer. You’d need to truly have your head in the clouds to be in a mindset where you’d get anywhere.
It also must be said that the story can be quite different for other ISO standards (e.g. some mentioned in the article). They can obviously get quite in the weeds. 27001 is the one that’s all-encompassing, head in the clouds, sort of stuff, and IME tends to be the one that orgs care the most about during procurement.
I was a few years into the career, working for Big Blue on a piece of network monitoring infrastructure.
We had been bought in and part of fitting our product better to IBM's target markets was to address requirements for the US federal government market. FIPS 140 was part of that, and as a mid-level engineer I had to learn the technical ramifications and implement a bunch of stuff. The standard itself was complex, but not overly so, and it became clear after a while that it was more about disabling features and removing dodgy home-grown algorithm implementations than it was about any massive security upgrades.
Pretty sure I listed it on my cv... it was definitely part of building up my "developer who is pretty good with the crypto side of things" trajectory but I'm not sure it was in any way pivotal.
[dead]
> "FIPS mode” is a thing provided by OpenSSL that, well, makes it more secure
Well, it makes it more compliant. In some ways it can make it less secure. For example, you can't use the newer algorithms (which becomes more important the longer it's been since the latest FIPS standard was released). And if you need to be FIPS certified, you have to wait for security patches to go through a lengthy review process.
Comment was deleted :(
Why not operate it in the FIPS mode all the time?
How come Ed25519 is not approved?
It is in FIPS 186-5 which is a very recent standard. Likely the underlying implementation has not undergone recertification to include it, as NIST has quite the backlog for FIPS certifications.
See: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf and https://csrc.nist.gov/projects/cryptographic-module-validati...
I used FIPS 186-5 in an argument with my InfoSec team to get ed25519 added to the list of accepted SSH key types on SSH servers running in FIPS mode. What a fun day :P
Crafted by Rajat
Source Code