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 fedoraproject@cyberpear.com 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 fedoraproject@cyberpear.com 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:
Unfortunately, that "RedHatOfficial" ansible role has some problems:
- 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.
It is not idempotent
There is no explanation for any of the variables.
It's nearly impossible to audit any changes:
https://github.com/RedHatOfficial/ansible-role-rhel7-stig/commit/3cdf26b66cc...
> "7,176 additions, 8,160 deletions not shown because the diff is
too large. Please use a local Git client to view these changes. "
- 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.)
- 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.)
- It's not really an open source project, but generated code from an
open source project.
- All PRs to the role are being ignored:
https://github.com/RedHatOfficial/ansible-role-rhel7-stig/pulls
- 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.
- 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:
- 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.)
Does it support ansible check_mode?
Does check_mode accurately report changes that would be made if
it were run for real?
- 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 --
scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to
scap-security-guide-leave@lists.fedorahosted.org
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/scap-security-guide@lists.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org 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/scap-security-guide@lists.fedor...