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/3cdf26b66cc723d34ba5dd3ed3d39410f48ae89c >>>> "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 _______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
