Trevor, Can you provide details on the compliance introspection? If it’s What I think it is, we have the same concerns and I’m looking for ways to tackle it.
Sent from my iPhone On Mar 6, 2020, at 11:11 AM, Trevor Vaughan <[email protected]> wrote: No problem. We'll take Ansible ports of the code into the project as well but there are some things that Ansible can't do around (that I know of) around compliance introspection of the codebase that keeps us with puppet so far. Thanks, Trevor On Fri, Mar 6, 2020 at 10:05 AM James Cassell <[email protected]<mailto:[email protected]>> wrote: On Fri, Mar 6, 2020, at 8:48 AM, Trevor Vaughan wrote: > Hi James, > > From what I've seen of the project (someone please correct me if I'm > wrong), the Ansible code from the SSG was meant to help you address > individual items without really being a cohesive infrastructure. > Cohesive infrastructures take a LOT of time to build and test. > > What you're asking for is what we do in the FOSS SIMP project > https://simp-project.com and we actually run the SSG tests against our > enforcement components on a regular basis as well as InSpect tests and > compare the two. By doing this, we've found issues in our code, the SSG > rules, and the InSpec rules over time. > > We'd love more interested people to take a look and help us close the > feedback loop between the two projects. > Looks like a nice project. I'm just not interested in puppet these days. I'll recommend your project to folks who are puppet shops if I come across them. (Everyone I work with is using ansible these days.) V/r, James Cassell > Thanks, > > Trevor > > > On Fri, Mar 6, 2020 at 12:14 AM James Cassell > <[email protected]<mailto:[email protected]>> wrote: > > 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]<mailto:[email protected]> > > To unsubscribe send an email to > > [email protected]<mailto:[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] > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 x788 > _______________________________________________ scap-security-guide mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[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] -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information -- _______________________________________________ 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] _______________________________________________ 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]
