Chris, you make some good points, so I will respond here rather than earlier in the thread.
The CIS Benchmarks are guidelines rather than rules. Quoting the overview: "This document, …, provides prescriptive guidance for establishing a secure configuration posture for Red Hat Enterprise Linux (RHEL) version 7.0 running on x86 and x64 platforms.” As I originally stated, I believe that a “CIS Hardening Module” is the wrong approach. The approach I used was to understand the CIS document and apply it, as appropriate, throughout the Puppet catalog. I believe this is not like implementing an individual service because it touches the entire operating system. In my workplace, we do not follow all the guidelines as some of them would prevent us from doing our work -- specific example: Section 3.11 Remove HTTP Server. How do you run a web server without HTTP ? If you read more carefully, it says to delete the HTTP packages unless there is a need to run the system as a web server. In my opinion, you cannot blindly convert this document into a Puppet module. The arildjensen-cis module (I think) turns many of the scored “rules” into cryptically named facter-type-facts (? “f0000” thru “f0022" ?). I created facts for my hardening implementation, but they are clearly named (like “duplicate_user_name”). The module’s classes are also cryptically named and (IMHO unnecessarily) multi-level with no references to the individual CIS guideline it applies to. In the code I wrote, each CIS paragraph is referenced. I did this for the security group’s ease of verification. I can do a recursive grep for “CIS” on my Puppet Master and produce a list to show that every paragraph is being addressed. Rather than using the CIS document exactly, we use it as a beginning and produce a local document that walks down each “rule” in the CIS, recording which ones we choose NOT to follow and the necessary mitigation. Most of the guideline “rules” can be implemented with a single Puppet resource, but not every rule is for every environment. I kinda like Chris’s suggestion for the $enablehardening parameter, but I do not know how much cooperation you will get on that idea. To sum up my point of view: (preface this whole block with “I believe…/I think…/IMHO…”) Puppet-izing the CIS Hardening Guidelines should be done throughout the entire catalog as necessary for one’s environment and system requirements. A security audit should be an easy thing if all the code bits are clearly referenced by paragraph. DISCLAIMER: This is my opinion as an experienced Puppet-using systems engineer/administrator. I do not claim to be 100% correct. I do make mistakes and my opinions sometimes go way out in left-center field. I welcome discussion and feedback on this topic. Maybe we can collectively figure it out. > On Mar 30, 2015, at 4:13 PM, Christopher Wood <christopher_w...@pobox.com> > wrote: > > 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 “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) -- 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/1FE02271-FC6B-4A2A-B936-329AC7D779ED%40icloud.com. For more options, visit https://groups.google.com/d/optout.
