On Fri, Oct 11, 2019 at 12:25 PM Chuck Atkins <chuck.atkins(a)kitware.com>
wrote:
> FIPS certification is more than just turning on ciphers,
>
For sure, I'm not arguing that point at all.
> but doing so only does the technical part, but it’s not the whole chain.
>
So, that's what the rules in question are checking though. The technical
implementation of the ciphers. The
That's not true. The rules also make sure that you are on a FIPS validated
system by design to meet compliance requirements hence the quote of the
NIST 800-53 controls.
> So, having a CentOS system with proper technical configurations in place
> is better than not doing so (like having a will on a piece of paper in the
> top drawer of your dresser is better than not having a will), calling that
> configuration “FIPS enabled” is not the case. It’s “just” a server with
> certain ciphers enabled.
>
Right, but that's not what I'm advocating for. The rules are supposed
to be testing whether or not certain ciphers, hashes, or packages are
enabled. Those are technical checks that should be able to pass regardless
of "certification". There is already a stand alone rule for if the OS is
FIPS certified, and certainly none of the derivatives should pass. But
shouldn't some of the technical components still be able to pass? "Is ssh
configured to exclusively use FIPS approved ciphers?" is different than "Is
ssh configured to exclusively use FIPS approved ciphers on a FIPS certifies
OS?" The checks are two different tests and the OS check is already a
stand alone rule.
No. FIPS ciphers running on non-validated FIPS systems are considered
equivalent to cleartext. FIPS ciphers are validated by compiled binary and
not source code. A very common misconception is that these profiles/rules
is about "hardening to a standard" rather than "validating and ending up
in
a compliance state" to 800-171, STIG, Common Criteria, etc. Which is why
certification profiles are no longer being delivered downstream from RHEL
in addition to the rules passing for FIPS as there are no more waivers in
the Federal government for not using FIPS or FIPS validated crypto. Not to
mention the fact that RHEL certifications and certifying content do not
apply to CentOS. There are many issues with CentOS that are related to
compliance areas, e.g. secure supply chain, certifications, validating
crypto, etc. which is why PRs surrounding compliance profiles and FIPS will
be closed. And it isn't about us not wanting to do it, it is about making
sure that compliance profiles get users to compliance end states. For those
that don't have to "comply" with FIPS (anyone not in the Federal
Government), they don't care that they fail.
> So, if I were king for a day, I would propose the idea that having a
> server pass a “FIPS valid” check would requiring passing other checks
> (ciphers, kernel FIPS configuration, supported RHEL OS). A hardened CentOS
> system could be configured to pass the cipher check and kernel checks, but
> fail the supported OS and the meta FIPS validated check.
>
That can already effectively happen by just enabling all of the FIPS
related rules. The profile can require all of them and then in the case of
being run on a derivative OS, most of them can still pass as they are
testing technical implementation but the "Is OS Certified" and "Is OS
vendor supported" will always fail.
Rules can be tailored out and removed. Plus, once again, FIPS running on
non-validated systems is considered cleartext.
This is of particular interest outside of RHEL derivative OSs.
We're
currently trying to develop NIST 800-171 content for ubuntu and I don't see
why we shouldn't be able to enforce the cipher configurations.
There is a different conversation that takes place when we talk about other
distributions, because if we are talking about Canonical-supported Ubuntu,
they do have FIPS-validated crypto.
BTW. FIPS validated crypto is also a requirement of NIST 800-171 for CUI.
- Chuck
_______________________________________________
scap-security-guide mailing list --
scap-security-guide(a)lists.fedorahosted.org
To unsubscribe send an email to
scap-security-guide-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...