On Mar 30, 2015, at 9:34 PM, Dan White <d_e_wh...@icloud.com> wrote: > 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.
I’ve actually done hardening on three separate projects with tools like Chef (one) and Puppet (two, including my current one). I’ve also been a professional Unix system administrator since 1989 (got my start in the basement of the Pentagon), and I’ve been involved in a multitude of security projects over the decades (some classified ones, and plenty of unclassified ones). I’ve worked in a variety of sectors, but mostly Internet/tech-related. I’m not as experienced with Puppet as I am with Chef, but I would agree with Dan's assessment. Fundamentally, security is not something you can bolt-on as an after-thought. It has to be baked into all of your processes and procedures as well as all your tools. Any other approach is likely to lead to “ensure => madness”. On the current project I’m working on, we are using the Roles/Profiles/Component module methodology, and we’re trying to minimize the number of component modules that we have to build, so we choose to make maximum use of publicly available modules from places like puppetforge. We also have provided to us lengthy security standards based on the ones from CIS, among other sources. Unfortunately, we have already run into problems with various Component modules pushing out configuration files (and other things) that didn’t meet our security requirements and we didn’t want to get into a constant battle of which module would win. So, we have decided that we will fork any public Component modules that we use and make necessary modifications to them. However, we are going to do this in a way that the necessary changes are parameterized and minimized, and then hopefully we will get approval to contribute this code back to the community. Among other things, we really don’t want to have to continue to maintain our forks. At that point, we can keep most of our work in the Profile modules that call the Component modules, and we get both the functionality that we require as well as the security that we require. I see no viable alternative to this approach. -- Brad Knowles <b...@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu> -- 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/941B58AC-2737-4D0C-8D77-EAEF5BD05F50%40shub-internet.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Message signed with OpenPGP using GPGMail
