Re: FIPS vs STIG

[James Cassell]

On Wed, Mar 11, 2020, at 11:36 AM, Matěj Týč wrote:
> One of RHEL7 bugzillas [1] shows an interesting discrepancy between our
> content and STIG:
>
> * We feature [2] a rule "Use Only FIPS 140-2 Validated Ciphers"
> * STIG has its own [3] "A FIPS 140-2 approved cryptographic algorithm
> must be used for SSH communications."
> There is a discrepancy between the two - while we claim that the
> following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux
> 7, only three of them are recognized as such by the STIG:
>
> * aes128-ctr(STIG)
> * aes192-ctr(STIG)
> * aes256-ctr(STIG)
> * aes128-cb
> * aes192-cbc
> * aes256-cbc
> * 3des-cbc
> * rijnda...@lysator.liu.se
> I have confirmed correctness of our description with our FIPS SME Tomas
> Mraz (in CC), so this issue looks as a bug in STIG - either the
> requirement is too strict, so it is incorrect, or it is supposed to be
> strict, and it should therefore be reworded, and we need to create a
> new rule in our content.
>

Indeed, the STIG allows fewer ciphers than FIPS allows; the STIG currently says "If any ciphers other than "aes128-ctr", "aes192-ctr", or "aes256-ctr" are listed, the "Ciphers" keyword is missing, or the returned line is commented out, this is a finding." [4]

Similarly, for the MACs allowed, "If any ciphers other than "hmac-sha2-256" or "hmac-sha2-512" are listed or the returned line is commented out, this is a finding." [5]

More are permitted by FIPS than by SSH, but the STIG is FIPS compliant as-is, using a subset of the FIPS ciphers. From the Security Policy document for the certification [6],

Only the following ciphers are allowed:
- aes128-ctr
- aes192-ctr
- aes256-ctr
- aes128-cbc
- aes192-cbc
- aes256-cbc
- 3des-cbc
- rijnda...@lysator.liu.se
Only the following message authentication codes are allowed:
- hmac-sha1
- hmac-sha2-256
- hmac-sha2-512
- hmac-s...@openssh.com
- hmac-sha...@openssh.com
- hmac-sha...@openssh.com


> What is the procedure in cases like this?
>

I'd just configure the STIG subset of FIPS, and maybe ask DISA to add a clarification note to the STIG. Many folks are concerned about the FIPS-permitted 3DES algorithm [7], "3DES is deprecated for all new applications and usage is disallowed after 2023"


V/r,
James Cassell


[4] https://vaulted.io/library/disa-stigs-srgs/red_hat_enterprise_linux_7_security_technical_implementation_guide/V-72221?version=V2R6

[5] https://vaulted.io/library/disa-stigs-srgs/red_hat_enterprise_linux_7_security_technical_implementation_guide/V-72253?version=V2R6

[6] https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp3067.pdf

[7] https://www.cryptomathic.com/news-events/blog/3des-is-officially-being-retired


> References:
>
>
> > [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1781244
> > [2]: https://static.open-scap.org/ssg-guides/ssg-rhel7-guide-stig.html#xccdf_org.ssgproject.content_rule_sshd_use_approved_ciphers
> > [3]:
> https://www.stigviewer.com/stig/red_hat_enterprise_linux_7/2017-12-14/finding/V-72221
>

[Bas Meijer]

This is a nice audit tool for ssh: https://github.com/arthepsy/ssh-audit.git

It will answer why they differ: compliance < secure.

Bas Meijer
@bbaassssiiee

> Op 11 mrt. 2020 om 17:10 heeft James Cassell <fedora...@cyberpear.com> het volgende geschreven:
>
> 

> --
> You received this message because you are subscribed to the Google Groups "Ansible Lockdown" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdo...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-lockdown/d97c178c-103a-41b3-ba9a-720e3e1498f7%40www.fastmail.com.