Matt, thank you very much for those kind words. It means a lot when we hear people are being helped by the content we've developed.
Gabriel,
RHEL8 is certainly on the roadmap for the project, it's just a matter of DISA putting out official guidance (even a draft would let us get rolling). We've even considered using the RHEL7 role as a starting point and tailoring/modifying it to work with RHEL8 in the interim.
We see explicitly:
The Security Rule does not require specific technology solutions. In this paper,some security measures and technical solutions are provided as examples to illustrate thestandards and implementation specifications. These are only examples.
And then it goes into various standards such as Access Control, Audit Controls, etc. Which, these do give good insight as to intent they do not provide the level of explicit guidance that something like the STIG or CIS Benchmarks provide. And HIPAA, unlike FedRAMP, doesn't say something like "Use CIS Benchmarks Level 1".
That being said, we could certainly create tech-specific (RHEL/Postgres/etc) Ansible content that satisfies the intent of the controls. However, my concern would be making sure that what is developed is useful and relevant to the majority of the Ansible Lockdown community.
To give an explicit example, take a look at
UNIQUE USER IDENTIFICATION (R) -§ 164.312(a)(2)(i), it mandates that users receive uniquely identifying attributes (name, id, etc) on a system. Implementing this could go a few different ways, some trivial brainstorming here:
- Rely on a standardize UID mapping across an estate
- AD/LDAP auth
- SAML2 (you can do this via PAM for example)
So again, I think we're totally up for it, but it's the inherit lack of precision in HIPAA guidance with regards to technical safeguards that can make it a little tricky.
Does that makes sense?
-Jonathan