FIPS compliance is honestly THE WORST.

This is a butchered version of my standard write-up for customers who have customers who ask about FIPS.

FIPS is really an unsuitable way to evaluate the security of large or complex systems. The major
cloud vendors who claim to be FIPS compliant do so by describing one key part of their system as
FIPS compliant (e.g. their VPN technology, for Azure, and SSL termination for AWS), and then
proudly displaying a compliance badge on their website.
It is more or less impossible to make a modern cloud system completely FIPS compliant, and it is a waste of
time to try. Organizations asking for FIPS compliance seem perfectly happy as long as one or two
key parts are compliant.

Usually, the simplest FIPS compliance goal is to target the transfer of <key data> over the Internet. That will satisfy most customers.

Actually it is a bit worse than that, because your customers will need to do some work on their side, and based on a realistic profile of customers who enquire about FIPs compliance, they are extremely unlikely to undertake that effort. So the key thing is to be "FIPS ready". More on this shortly.

DEFINITIONS

FIPS - This is actually a broad range of standards. In the context of security, most people mean
FIPS 140-2 - "Security Requirements for Cryptographic Modules".

* FIPS Certified: If you create cryptographic modules, you can have them certified as compliant by an accredited lab. This costs a lot of money. There is an official list of all FIPS certified cryptographic modules.

* FIPS "Level" - There are 4 levels. Software can really only ever be level 1. Levels 2+ start talking about features only possible in hardware, such as tamper evident seals.

* FIPS Compliant - If your product uses only FIPS certified cryptographic modules and FIPS approved algorithms for all cryptographic operations, it is FIPS compliant.

* FIPS Ready - This is a "made-up term", but it sounds good. It's a way to express "Our software can be compliant, but you need to do some things which we can't do for you".

FIPS ON THE CLIENT

Windows is only compliant if it is operating in "FIPS mode". Obviously, you can't turn that on for your customers, they need to do it themselves. See: Enabling FIPS compliant algorithms in Windows.
Note that enabling FIPS mode will often break a lot of things (e.g. TLS connections to some web
sites, inter-operation between different versions of Windows and so on). Also, it will actually tend to
weaken security. This is because the FIPs approved algorithm list is several years old which means
that the system is forced to use ciphers which are weaker than modern defaults. Furthermore,
FIPS-certified code can't, if you read carefully, be patched without re-certification.

FIPS MODE, IN GENERAL

Most vendors meet the requirements of FIPS by providing a specific, certified "mode" in which the
system is compliant.
Why? Well, when a software cryptographic module is FIPS certified, the certification just applies to
that exact version. If a single byte changes in that software module, it isn't certified any more.
Naturally, vendors want to keep improving their software. So they keep the old, certified code
around and only activate it in FIPS mode. Also, in FIPS mode, the software must perform time-consuming self-tests every boot (ok, that is not that bad).

It is really an untenable situation for software. Here's a great write-up of the software certification process from a member of the Oracle Solaris team: Is FIPS 140-2 Actively harmful to software?.

https://blogs.oracle.com/darren/is-fips-140-2-actively-harmf...

The engineer (an architect on the Solaris crypto team) writes:

So should I run Solaris 11 with FIPS 140-2 mode enabled ? - My personal opinion is that
unless you have a very hard requirement to do so I wouldn't ...

And then, regarding patching:

So what we do we do in Solaris ? We make the bug fixes and and new non FIPS 140-2 relevant algorithms (such as Camellia) anyway because most of our customers don't care about FIPS 140-2 and even many of those that do they only care to "tick the box" that the vendor has completed the validation.

FIPS IN THE CLOUD

Given the difficulties with FIPS mode for just operating systems vendors, you can see that operating
an entire cloud service using FIPS-certified cryptographic modules is going to be extremely difficult.

You will need to think about OpenSSL, any database encryption code, OpenSSH, NSS, PAM, password hashing and all sorts of other services which may or may not do encryption.

Various compliance schemes often allow you to have unencrypted transfers within certain trust boundaries. Ironically this can mean that the quickest path to compliance is logically to turn off any encryption which your regulators do not strictly force you to use. Because FIPS doesn't say what to encrypt, it just says how to do it - if you do!

FIPS AND AMAZON

Then you have to ask: Wait, is Amazon itself "FIPS compliant"? For example, when I send data to and from Amazon S3, will the SSL be protected with FIPS compliant algorithms and are they using FIPS certified cryptographic modules?

Amazon do claim to have a FIPs mode, but only in Govcloud. As far as I can tell, they claim to be FIPS 140-2 compliant by virtue of using FIPS-compliant TLS on their endpoints.

RECOMMENDED COMPLIANCE STATEMENT AND POSITION

The reality is that customers tend to think of "FIPS compliance" as a check in the box. A binary state - is it compliant or certified, or is it not?

This view makes sense for a chip or a software library. However, when we talk about a large system with many moving parts, it is not strictly clear what "FIPS compliant" even means anymore. Different vendors seem to solve this problem in different ways:

- Operating systems vendors achieve compliance by having a "special mode" which no-one in their
right mind ever turns on.

- Amazon claim they achieve compliance by providing "FIPS compliant" SSL on their endpoints.

- Azure claim they are FIPs compliant because "Azure uses Microsoft cryptographic modules in the
validated list published by NIST, enabling customers to configure and use Azure Virtual Network
services in a way that helps meet their information encryption requirements."

- Rackspace and Google Cloud, as far as I can tell, do not even try.

It is pretty clear that the cloud vendor claims are just pandering to the "rubber stamp" mentality of customers, and proudly displaying "FIPS compliance" by ensuring that say, some key aspect of their system is certified or compliant (not the entire system from end to end).

This mostly works because customers who are looking for rubber stamp compliance neither care enough nor know enough to question the veracity of claims.

SUGGESTED COMPLIANCE STATEMENT

The software we deliver to you (XYZ & ABC) is FIPS ready. To
achieve FIPS 140-2 Level 1 compliance, you need to operate your systems in FIPs mode via Windows Group Policy. When systems running ABC SOFT are in FIPs mode, all <sensitive data for your regulatory domain> transmitted to and from our systems will be protected using FIPS 140-2 approved encryption algorithms.

<context is operator providing a web service on AWS with mostly windows clients>

DELIBERATE WEASELINESS

Of course that statement is weaselly. The only thing you can promise is that you're gonna use FIPS compliant TLS, and even that only really works right if the customer configures their stuff in the right way and your cloud supports it.

The minute anyone opens their eyes to the broader scope of things, of course the system as a whole is not going to be "FIPS compliant" because there is a ton of crypto required behind the scenes to get software systems to work and NONE OF THAT IS FIPS COMPLIANT.