Hi Dan, Chris, Many thanks for taking the time to respond, some very useful ideas to ponder.
Apologies if this is a bit waffley and repeats itself. Dan's approach is more elegant in the sense that it implements just what is required, but makes me uncomfortable because it distributes hardening implementation throughout all of the code base. Using a hardening module is somewhat elegant in the sense that the hardening is 'mostly' in one place, but it makes me uncomfortable that many other modules are affected, not all the hardening can remain in the hardening module if other modules manage conflicting resources, and conflicts can be problematic to diagnose and resolve, it doesn't seem too follow the puppet way of doing things. My experience is that using a hardening module was a pragmatic way to take advantage of existing code that implements an industry standard hardening guideline, especially without an extensive pre-existing code base and it was easier to communicate that hardening was being enforced. Agreed -- the CIS Hardening guidelines should not be applied verbatim (as the individual sections don't always apply to the business's use of the system). Each item should be considered and applied to each system as appropriate. There may also be site standards to take into account that can add or subtract hardening requirements. If you go down the path of using a module specific to hardening.... The implementation of hardening guidelines via an independent module affects many other generic modules and may well cause conflicts. Resolving these conflicts involves changing either the hardening module or the generic module (assuming you can identify the conflict or lack of convergence). If you have to change the generic module anyway perhaps that should be where the hardening code should be implemented rather than attempting to have a separate module to implement the hardening. However some of the CIS guidelines don't have a corresponding generic module (at least in the code base I was working on) so the hardening module provides a starting point. I remember the f000 and c000 things now -- quite a PITA to find and trace the relationships when there are problems, I didn't enjoy that one bit. I liked the idea of having a cis::el6all include classes for each guideline paragraph, it provides a reference for which paragraphs of the hardening guide are being implemented. The use of sequential numbers for the classes that actually implement the hardening (called from cis:: classes named after the corresponding document section) makes tracing problematic, I think there are couple of cases where they are reused -- still meaningful names would probably help. I don't see why the facts and there corresponding script fragments cant have meaningful names. If I recall correctly I commented out some of the classes in the cis::el6all class and added a description of where this functionality was implemented in a generic module (ssh, ntp etc). If I end up having to do this again and go down this path I will comment the changed ssh module etc with the CIS section too (should of thought of that before). I like the idea of having most of the hardening implementation in one place rather than scattered over the whole code base. The way puppet works doesn't lend itself to taking a cross cutting concern like hardening and putting it in an independent module -- at least not without significant issues -- so its fair to argue it misappropriate use of puppet. It seems to me that hardening is a distinct aspect and in some circumstances I would like to see all the hardening things and none of the rest of the details, however I'm unaware of any support for a module implementing specific functionality (say ssh) having part of is implementation overideable by a class in a foreign module (say cis hardening). If you go down the path of implementing hardening directly in the code base without a module then apart from a text search there seems no way of gathering all of the hardening specifics together. My experience of using arildjensen-cis was that there was quite a bit of breakage that had to be resolved, but that breakage identified things that were managed but non-compliant. Some of the arildjensen-cis classes were not relevant and were disabled before attempting the first run. I found that arildjensen-cis was a good starting point and covered quite a number sections of the guide, diagnosing problems was not always straight forward and the end solution had most but not all the hardening in one place. I also subscribe to Dan's disclaimer above, this is just my experience and opinions however code was written systems configured and audits passed. The $enablehardening idea sounds interesting but don't expect there would be much uptake unless puppetlabs found some way to mandate it or something similar. I feel like hardening should override other modules resources by some magic, or there should be some way to compose a resource from unrelated modules, but its not the way puppet works and I suspect it would be extremely unworkable. I feel something is missing but I don't have a concrete suggestion of what form a solution should take. Dan, did you present the security team with the comments in puppet code containing the string CIS or extract the CIS relevant code for their inspection? Were there new modules that implemented some of the hardening sections and if so did you use module names that describe what they implement along with comments referencing the security guidelines? On one hand pre-existing code to perform hardening can get you going quicker but on the other hand perhaps Dan's approach is better in the long run and gathering the all hardening information from across the code base is sufficient. Do you have the code base or some fragments on git-hub, I guess not as security related code is usually quite sensitive but if you don't ask:) Thanks Peter On 30 March 2015 at 19:34, Dan White <d_e_wh...@icloud.com> wrote: > 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 > <https://groups.google.com/d/msgid/puppet-users/1FE02271-FC6B-4A2A-B936-329AC7D779ED%40icloud.com?utm_medium=email&utm_source=footer> > . > > For more options, visit 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/CAKx2DRaub4LzY8aUu2CvfLXWSTwgE4fTPovjVmpMEriECzk_qQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
