Nice discussion we have going here. Comments/responses inline
“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 31, 2015, at 02:46 AM, Peter Pickford <pe...@netremedies.ca> wrote:
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 "grep -rn CIS" method works very nicely for me, but YMMV
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?
A combination. The security folks are not as technical as the could be, so showing them code is a questionable use of time. Where possible without breaking something, I demonstrated how Puppet would either fix or notify something that went against a hardening guideline we chose to follow.
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:)
Great idea. While I may encounter hot water by publishing my classes outright,
I believe I am safe posting snippets demonstrating how to implement individual
rules or groups of rules. I will try to get a git-repo started by the weekend,
but it is Easter weekend and I have some family obligations I cannot (and do
not wish to) side-step.
Any requests for a section to start on ?
Thanks
Peter
You are most welcome
Dan
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.
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.
--
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/5b7d9d42-9ba1-4c76-b862-9a3b0d234feb%40me.com.
For more options, visit https://groups.google.com/d/optout.
