Puppet is a compiler and the end state of the compiled artifacts is known prior to application on the target system.

Given this, the parameters of each artifact can be inspected prior to delivery and we can ensure that parameters meet the requirements before sending any information to the target system for application.

Ansible is procedural instead of declarative in execution which means that the final state cannot be known with the overall application of playbooks. However, this makes Ansible more suited to cross-system orchestration and dynamic one-off system configuration.

We've worked with several customers using Puppet as the 'over time' approach for compliance consistency and other tools (Ansible, Bolt, Salt, Chef, SSH in a loop, whatever) for the one-off approach.

We also like being able to disable the Ansible agent so that all inbound connections to systems are closed for maximum security.

Thanks,

Trevor

On Fri, Mar 6, 2020 at 2:16 PM Albrecht, Thomas C <thomas.c.albrecht@lmco.com> wrote:
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 <tvaughan@onyxpoint.com> 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 <fedoraproject@cyberpear.com<mailto: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<mailto: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:
> >  >
> >  > 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 -- scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
> >  To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org<mailto: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.fedorahosted.org
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699 x788
>
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org<mailto: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.fedorahosted.org


--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --
_______________________________________________
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.fedorahosted.org
_______________________________________________
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.fedorahosted.org


--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --