On Thu, Mar 5, 2020, at 9:57 PM, Shawn Wells wrote:
On 3/5/20 1:00 PM, James Cassell wrote:
> On Thu, Mar 5, 2020, at 12:57 PM, Jeff Bachtel wrote:
>> Good day. I am trying to apply current RHEL7 STIG guidance to AWS EC2
instances and have run into issues. Could someone check my conclusions
below and let me know if I missed something?
- OpenSCAP doesn't yet support RHEL7 STIG V2R6 in its in-tree code
(including remediation code)
- The NIST NCP for RHEL7 from
>>
https://github.com/ComplianceAsCode/content/tree/master/rhel7 doesn't
yet include STIG V2R4 remediations
- The actual DISA RHEL7 STIG XCCDF file does not include fixes, such
that OpenSCAP could use it to generate remediation scripts
-
https://github.com/MindPointGroup/RHEL7-STIG is probably the best
RHEL7 STIG remediation script that's publicly available
> All correct from my perspective.
To the best of our knowledge there haven't been any substantive changes
to the DISA content. At least we haven't been informed of any (eg rule
selections/removals, changing variables like password length, etc).
That said, could be interesting to run the Red Hat provided
remediations and then re-scan with the DISA-provided content. Goal
It's concerning that this hasn't already been done.
would be to see if anything fails... in theory showing any gaps
between
the content.
Would you be interested/able to help do that? Here's the ansible content:
https://galaxy.ansible.com/RedHatOfficial/rhel7_stig
Unfortunately, that "RedHatOfficial" ansible role has some problems:
1. It does not follow ansible best practices such as prefixing each role variable with a
variable namespace unique to the role, such as a `rhel7_stig_` prefix.
2. It is not idempotent
3. There is no explanation for any of the variables.
4. It's nearly impossible to audit any changes:
https://github.com/RedHatOfficial/ansible-role-rhel7-stig/commit/3cdf26b6...
>>> "7,176 additions, 8,160 deletions not shown because
the diff is too large. Please use a local Git client to view these changes. "
5. The thing is a monstrosity at 16K lines for its tasks, so even if you audit it once,
good luck auditing half of it again next time an update is pushed. (The ansible-lockdown
(
https://github.com/ansible/ansible-lockdown ) role currently under the MindPointGroup
org is also not tiny at 3.8K lines for its tasks.)
6. Does not practice DRY (don't repeat yourself), contributing to (4). RedHatOfficial
show 578 tasks when run with `--list-tasks` whereas MindPointGroup shows 314 tasks. (RH
lists "only" 84% more unique tasks, but has 420% more lines to audit.)
7. It's not really an open source project, but generated code from an open source
project.
8. All PRs to the role are being ignored:
https://github.com/RedHatOfficial/ansible-role-rhel7-stig/pulls
9. It clearly hasn't been audited by anyone who is familiar both with implementing
STIG requirements as a System Administrator and with writing and consuming Ansible roles.
10. It clearly is not used nor even tested by Red Hat itself. Such things as setting the
login banner text to the literal REGEX that should match the banner, which is completely
illegible, and would fail the DISA content check. It doesn't look like Red Hat even
uses their shipped scap-security-guide package to test the "RedHatOfficial"
ansible role, as this would certainly have been caught.
(Yes, they literally set the banner as a regex displayed to the user):
`(^You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+`...
I'd previously opened issues against the repo for these and other items, but they have
been "disappeared", so I can't even refer you to them, and it appears that
issues have now been turned off entirely for the repo.
Other things I'd be concerned about but haven't checked due to the items above:
11. Does it remediate a system without bricking it or severely disabling it?
(scap-security-guide bash remediations did not have this property last time I tried 2+
years ago.)
12. Does it support ansible check_mode?
13. Does check_mode accurately report changes that would be made if it were run for real?
14. Does every task that reports "OK" (i.e., "not changed") when run
for real, actually leave the system untouched?
Consider the above my review of the
https://github.com/RedHatOfficial/ansible-role-rhel7-stig ansible role. I Didn't
expect to write so much, but there you have it.
V/r,
James Cassell