PostgreSQL and FIPS Mode

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.

How would it become less secure? Because newer crypto algos aren't in the set allowed by FIPS?

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...

> 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.

>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"

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.

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.

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 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...