On Mon, Mar 30, 2015 at 09:10:03AM -0700, Peter Pickford wrote: > Hi Dan, > Could you expand on why "making a module out of the CIS Hardening > Guidelines is the wrong approach".
Not sure what Dan will say and I haven't done it myself. However I have watched another team here produce a hardening module which reaches into all sorts of places and applies all sorts of resources. After watching their experience I would not willingly do that myself. > It seems like a good option when the likes of PCI > DSS suggest implementing industry standards. > Are you referring to the conflicts you end up with when using more > specific, and usually more appropriate to the task at hand, modules (ssh > module deals with ssh and cis also tries to manage ssh). Don't forget the dependency loops. There can be many fun dependency loops when managing related resources using different modules. This goes double when you have the obvious collector/chaining relationships like apt/yum before packages, packages before mounts, mounts before "special" execs, and so on. A shim'ed-in dependency can be difficult to untangle. It's also not terribly obvious where the problem is when your resource keeps apply because there's another resource in another module changing it (file_line vs file revert fight sort of thing). > Last time I tried this I recall having to modify and disable some of the > CISmodule. > I did end up with systems that proved easy to demonstrate complied with > the CIS guidelines. > Is there a good way to combine cross cutting concerns such as implement a > policy of standardizing on CIS Hardening Guidelines and wishing to > use/resuse more specific/standard/appropriate modules for each component? I suspect that the most generic puppet modules were not built with CIS/PCI/etc. paranoiac hardening in mind. (Grep the manifests for 'mode' to illustrate this, blink at all the o+r.) If you want hardening in the standard modules maybe the authors will accept patches with $enablehardening type of class parameters toggling things? > Thanks > Peter > On 30 March 2015 at 07:41, Dan White <[1]d_e_wh...@icloud.com> wrote: > > <Just my opinion> > I believe that making a module out of the CIS Hardening Guidelines is > the wrong approach. > I implemented RHEL 5 and RHEL 6 hardening throughout my catalog. > Specific example: Guidelines for ssh_config and sshd_config are in the > ssh moduile. > </Just my opinion> > > “Sometimes I think the surest sign that intelligent life exists elsewhere in > the universe is that none of it has tried to contact us.” (Bill Waterson: > Calvin & Hobbes) > > On Mar 30, 2015, at 10:07 AM, Joseph Holland <[2]j0ey2...@gmail.com> > wrote: > > Hi Ash26, > Did you manage to get this working in the end or have you figured out > another way to implement the CIS benchmarks in some automated fashion? > Thanks, > Joe. > > On Monday, February 9, 2015 at 9:57:57 AM UTC, Ash26 wrote: > > arildjensen-cis seems not to have worked for RHEL7 > > -- > You received this message because you are subscribed to the Google > Groups "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [3]puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > > [4]https://groups.google.com/d/msgid/puppet-users/5cbbbc24-70cb-4db9-b6bb-5c527f70f92c%40googlegroups.com. > For more options, visit [5]https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google > Groups "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [6]puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > > [7]https://groups.google.com/d/msgid/puppet-users/63abe2dd-d338-4448-afc3-29ea481f3e97%40me.com. > For more options, visit [8]https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [9]puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > > [10]https://groups.google.com/d/msgid/puppet-users/CAKx2DRYPx%2BVwX%3DPBah2mgS367jQFbFjsHPA9KO5KiZ34p1knyQ%40mail.gmail.com. > For more options, visit [11]https://groups.google.com/d/optout. > > References > > Visible links > 1. mailto:d_e_wh...@icloud.com > 2. mailto:j0ey2...@gmail.com > 3. mailto:puppet-users+unsubscr...@googlegroups.com > 4. > https://groups.google.com/d/msgid/puppet-users/5cbbbc24-70cb-4db9-b6bb-5c527f70f92c%40googlegroups.com?utm_medium=email&utm_source=footer > 5. https://groups.google.com/d/optout > 6. mailto:puppet-users+unsubscr...@googlegroups.com > 7. > https://groups.google.com/d/msgid/puppet-users/63abe2dd-d338-4448-afc3-29ea481f3e97%40me.com?utm_medium=email&utm_source=footer > 8. https://groups.google.com/d/optout > 9. mailto:puppet-users+unsubscr...@googlegroups.com > 10. > https://groups.google.com/d/msgid/puppet-users/CAKx2DRYPx%2BVwX%3DPBah2mgS367jQFbFjsHPA9KO5KiZ34p1knyQ%40mail.gmail.com?utm_medium=email&utm_source=footer > 11. https://groups.google.com/d/optout -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20150330201348.GA12753%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
