Getting Involved / CIS Role(s)

[Brian O'Reilly]

Hey all,

After attending Sam Doran's awesome session on security at AnsibleFest last week (thanks Sam!), I was really motivated to start looking for ways to get involved in the community in relation to Ansible/Security, and this seems like the place to be.

I have been working on a role based on the RHEL 7 CIS Benchmarks at my workplace and was able to deploy our role on some production servers recently, which was really exciting. The role I have currently is somewhat modified from the official CIS Benchmarks due to some changes we needed for our infrastructure and certainly needs some cleanup, but I'd like to be able to share some of the work I've done so that others can benefit as well.

I'm assuming that there is interest in having CIS roles in addition to STIG roles (?), but is there a centralized place for work on this sort of thing, and/or a best practice for getting involved? I saw the MindPointGroup RHEL7-CIS repo on GitHub, but the skeleton doesn't seem to match up with the sections on the current CIS Benchmark so I'm unclear if that's the best place. Would love to be able to fork a repo and start making PRs, or whatever would be most beneficial.

Also another question on this topic:

Is there an agreed upon methodology of handling customizability in terms of these security roles? I.e. if a company's policy differs from some item in the benchmarks, how would (or should) someone running these roles override these items? Would this be a case of forking the roles and making adjustments for individual use cases, or should we as role designers imbue the roles with flexibility and/or variables to handle these types of use cases?

For example, CIS says that user accounts should be disabled after 30 days of inactivity (5.4.1.4 in v2.1.0). Being a part of a small team, it's extremely likely that I won't login to a server for more than 30 days, so it would actually be very detrimental to have my account suddenly disabled. Is this something where it would be best practice to have some boolean in defaults/main.yml to determine whether or not to run that item, in the same way that there are optional flags indicating not to uninstall httpd in the case of servers that require it?

There are a bunch of hiccups along these lines that I've run into when actually running these sorts of roles on real servers, and I'm interested in what other people think about best practices to handle them.

Thanks!

Brian O'Reilly

[Jonathan Davila]

Brian, great post! And welcome to the Lockdown community.

On CIS:

Regarding the current Mind Point Group role:

This is definitely still a work in progress and you're right it doesnt quite line up perfectly; as far as the Ansible-Lockdown project goes, Mind Point Group's repos are the ones to fork (more on that below**). Once it matures, we'll be adding it to the test pipeline.

In general, the rule is for the audit/remediation actions to be written out sequentially. So for the RHEL7 CIS benchmark that would mean starting with 1.1.1.1 and ending with 6.2.19. The other design pattern is for each logical grouping to be in its own task file within "tasks/", which would be 1, 2, 3, 4, 5, and 6 for CIS.

Regarding customization:

There are a few of things to consider. 

1. If it's simply a data change (ie auto account disabling from 30 days to say, 90 days) then it's a matter of leveraging Ansible variable precedence mechanism to override that value, in the case of a role default (the weakest in precedence) you can override the value easily via a play var, a role call var, extra var, host var, group var, etc. 
   
2. If it's a logical change (ie you want to change how something works, remove something compleltely, add in custom rules, etc) then you're better off forking the role and making modifications there and then you can just do a periodic rebasing with the upstream in order to stay in sync (assuming your tweaks arent so widespread so as to cause merge conflicts every time).
3. The current RHEL6 STIG role does have some examples of leveraging booleans/defaults within the role if you'd like, feel free to use that as a reference.

** The reason Mind Point Group hosts the roles that are part of Lockdown proper is due to the fact they function as the 3rd party validator of our implementation. As everyone is well aware, neither Ansible nor Red Hat at-large is directly in the business of IT security, but MPG is. When we first started talking about doing this project it was one of the first things that came up, "How do we give some level assurance to users/orgs that end up leveraging these roles?" That answer is and was Mind Point Group, they are a formal partner of Red Hat (by way of the Ansible acquisition) with a solid track record in the IT security space and an affinity for open source. I can say for a fact that the RHEL6 STIG role has already made waves and is being used by many Federal and local government agencies as well as private sector institutions as well. Hopefully, this all makes sense.

If and when there is a need/desire to create a new role that doesn't yet have a repo, just open an issue on the Lockdown repo and we can create a new repo under the MPG org.

Again, welcome to the community!

Jonathan I. Davila Principal Architect, Automation Practice, Red Hat, Inc 202.415.1878 // redhat.com // jda...@redhat.com // Washington, D.C

--
You received this message because you are subscribed to the Google Groups "Ansible Lockdown" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdo...@googlegroups.com.
To post to this group, send email to ansible-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-lockdown/62e13740-4113-4d9e-9d6e-fa0d12a68e38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Shepherd]

Thanks Jonathan and welcome to Lockdown Brian!

 

The current RHEL7 CIS benchmark repo is definitely a work in progress and the current skeleton of sections in tasks, etc was generated from v1.1.0 of the benchmark. CIS has since released a major update to v2 and then v2.1.0. The move from v1 to v2 included some Section changes and we are currently planning on re-generating a skeleton and then seeing how much delta there is. We can then merge the changes so that we have a good base to start from.

 

As a note, I use this Python script to generate skeleton Ansible content from an XML benchmark file. https://github.com/shepdelacreme/benchparse Feel free use it for generating content for any other benchmark roles you may be working on!

 

Thanks!

Dan

 

From: <ansible-...@googlegroups.com> on behalf of Jonathan Davila <jda...@ansible.com>
Date: Monday, August 1, 2016 at 7:47 PM
To: Brian O'Reilly <brianp...@gmail.com>
Cc: Ansible Lockdown <ansible-...@googlegroups.com>
Subject: Re: Getting Involved / CIS Role(s)

 

Brian, great post! And welcome to the Lockdown community.

 

On CIS:

 

Regarding the current Mind Point Group role:

This is definitely still a work in progress and you're right it doesnt quite line up perfectly; as far as the Ansible-Lockdown project goes, Mind Point Group's repos are the ones to fork (more on that below**). Once it matures, we'll be adding it to the test pipeline.

 

In general, the rule is for the audit/remediation actions to be written out sequentially. So for the RHEL7 CIS benchmark that would mean starting with 1.1.1.1 and ending with 6.2.19. The other design pattern is for each logical grouping to be in its own task file within "tasks/", which would be 1, 2, 3, 4, 5, and 6 for CIS.

Regarding customization:

There are a few of things to consider. 

1.        If it's simply a data change (ie auto account disabling from 30 days to say, 90 days) then it's a matter of leveraging Ansible variable precedence mechanism to override that value, in the case of a role default (the weakest in precedence) you can override the value easily via a play var, a role call var, extra var, host var, group var, etc. 

2.        If it's a logical change (ie you want to change how something works, remove something compleltely, add in custom rules, etc) then you're better off forking the role and making modifications there and then you can just do a periodic rebasing with the upstream in order to stay in sync (assuming your tweaks arent so widespread so as to cause merge conflicts every time).

3.        The current RHEL6 STIG role does have some examples of leveraging booleans/defaults within the role if you'd like, feel free to use that as a reference.

** The reason Mind Point Group hosts the roles that are part of Lockdown proper is due to the fact they function as the 3rd party validator of our implementation. As everyone is well aware, neither Ansible nor Red Hat at-large is directly in the business of IT security, but MPG is. When we first started talking about doing this project it was one of the first things that came up, "How do we give some level assurance to users/orgs that end up leveraging these roles?" That answer is and was Mind Point Group, they are a formal partner of Red Hat (by way of the Ansible acquisition) with a solid track record in the IT security space and an affinity for open source. I can say for a fact that the RHEL6 STIG role has already made waves and is being used by many Federal and local government agencies as well as private sector institutions as well. Hopefully, this all makes sense.

 

If and when there is a need/desire to create a new role that doesn't yet have a repo, just open an issue on the Lockdown repo and we can create a new repo under the MPG org.

 

Again, welcome to the community!

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-lockdown/CAPQp0Q8dd2NxhbvBn%3D%3D00QGSwkQuaJESd_MgauLuVtTbZU73sw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Confidential: This email is intended for recipient to which it is addressed. The information contained in this email may be confidential, proprietary, or may contain PII. Any retransmission, review, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you have been asked to provide PII to the sender of this email, then in order to properly secure this information, please send it within an encrypted attachment with the password/key provided under a separate cover, such as in person, by phone, or in a separate email.

[Bas Meijer]

Hi,

The RHEL7-CIS benchmark now has a few more actions than the original because some points needed more mitigating steps than generated, etc.

Bas 

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-lockdown/E66F63C3-3A5C-4747-AA58-2AE091F10D46%40mindpointgroup.com.

[Daniel Shepherd]

I checked this out and started working on an update last night. I confirmed that the issue is that the existing content was produced from the v1.1.0 benchmark. CIS altered the section layout and many of the configuration item numbers when they moved to v2. For example v2 goes from Section 1 to 6, whereas v1 went up to Section 9. 

I have generated new boilerplate and am in the process of migrating some of the existing checks that were written to the new layout. I should have the repo updated in the next few days.

Thanks,

Dan

---

From: Bas Meijer <brme...@gmail.com>
Sent: Tuesday, August 2, 2016 6:56 AM
To: Daniel Shepherd
Cc: Jonathan Davila; Brian O'Reilly; Ansible Lockdown

[Daniel Shepherd]

Brian,

If you'd like to contribute to the RHEL7-CIS role, I've updated the skeleton to v2.1.0. Feel free to fork and start making PRs if you feel so inclined. 

Also...there are some legacy files from the v1.1.0 version of the role that still exist in the "tasks" directory of the repo. These contain some content that can be directly migrated to the new section files but because of the CIS version change the item numbers didn't necessarily match up. I've kept these so that the content can be migrated as needed.

Thanks,

Dan Shepherd

MindPoint Group

[Sam Doran]

Brian,

Welcome to the Ansible Lockdown community! Thank you very much for attending my talk. I truly appreciate your kind words and I'm glad it inspired you to get involved.

I'm mainly responding to your questions on sharing and methodology, echoing a bit of what Jon mentioned earlier.

I'd like to be able to share some of the work I've done so that others can benefit as well.

Publishing and maintaining roles on Ansible Galaxy tagged with "security" and "cis" is an excellent way to share what you have. Contributing and working directly on the official roles in Ansible Lockdown/MPG is also great, but don't let that discourage you from sharing what you have for others to see. We have made a very specific set of choices with regards to the "official" roles so they are as flexible as possible. You may choose to approach security automation in a different manner, which can inspire someone else in their security automation needs.

The main thing we're trying to create is a reference architecture for how to do security automation with some great and useful content. We're not trying be the only way to do it or discourage others from making their own roles for the same standards or company-specific ones.

Is there an agreed upon methodology of handling customizability in terms of these security roles? I.e. if a company's policy differs from some item in the benchmarks, how would (or should) someone running these roles override these items?

What Jon said: if it's a specific value, such as number of days, make that a default variable that can be easily overridden. Also, used booleans to skip tasks or groups of tasks.

Designing roles in such a way that they can be used without being forked is really tough because everyone's needs are so different. I'd say start with the ideal notion of a role that can be fully tailored using variables and tags, but don't let that hinder development. There are certain situations where you have to make a decision and pick the action the role will take knowing that it's going to require forking for some folks. Security is an insanely hard problem to solve with a myriad of complexities. It's not feasible that one role will ever work in all environments.

There are a bunch of hiccups along these lines that I've run into when actually running these sorts of roles on real servers, and I'm interested in what other people think about best practices to handle them.

Please feel free to reach out here for ideas, or in issues on a particular role repository (or send a message here to invite people to an issue in a security automation related project). One of the things I wanted more of early on when I started writing the RHEL 6 STIG role was more people to bounce ideas off of. Please feel free to engage this community. We're here to help.

---

Respectfully,

Sam Doran

[Bas Meijer]

@MindPointGroup,

Please keep track of the pull-requests in RHEL7-CIS. Work is accumulating for days now.

Bas

--
You received this message because you are subscribed to the Google Groups "Ansible Lockdown" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdo...@googlegroups.com.
To post to this group, send email to ansible-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-lockdown/D212394B-3090-464A-9097-530C700BF540%40redhat.com.

[Jonathan Davila]

Hi Bas,

Firstly, I'd like to request some patience, all maintainers of the Ansible Lockdown project have full-time jobs where Lockdown work isn't, to date, an explicit daily job duty. That being said, it is an officially endorsed project and we are able to work on it during work hours, but it is, so far, secondary to our primary roles. Speed isn't nearly as fast as it would be if Lockdown were our full-time job, please be respectful of that fact. When I look at the PRs I see one pull request from you that has been open for 2 days (according to GitHub), we'll get to it. It should only be cause for concern if you see a pull request open for more than 2 weeks without any sort of feedback.

Secondly, the mailing list isn't the place to request attention on a particular pull request. That sort of discussion should happen on the pull request itself. Of course, you can raise general concerns about the project, for example, to express dissatisfaction with, the speed at which your PRs are evaluated and merged, or even with the maintainers themselves (though I hope not); however, in that case, the proper place would be on a new mailing list submission and not on an existing thread.

On Fri, Aug 19, 2016 at 8:27 AM, Jonathan Davila <jda...@redhat.com> wrote:

Hi Bas,

Firstly, I'd like to request some patience, all maintainers of the Ansible Lockdown project have full-time jobs where Lockdown work isn't, to date, an explicit daily job duty. That being said, it is an officially endorsed project and we are able to work on it during work hours, but it is, so far, secondary to our primary roles. Speed isn't nearly as fast as it would be if Lockdown were our full-time job, please be respectful of that fact. When I look at the PRs I see one pull request from you that has been open for 2 days (according to GitHub), we'll get to it. It should only be cause for concern if you see a pull request open for more than 2 weeks without any sort of feedback.

Secondly, the mailing list isn't the place to request attention on a particular pull request. That sort of discussion should happen on the pull request itself. Of course, you can raise general concerns about the project, for example, to express dissatisfaction with, the speed at which your PRs are evaluated and merged, or even with the maintainers themselves (though I hope not); however, in that case, the proper place would be on a new mailing list submission and not on an existing thread.

To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdown+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-lockdown@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-lockdown/D212394B-3090-464A-9097-530C700BF540%40redhat.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Ansible Lockdown" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdown+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-lockdown@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-lockdown/1F143852-B9D6-4600-ACA2-E0E1DC9BCADF%40gmail.com.

[Imran Hussain]

Hi everybody,

Just wanted to throw my £0.02 in from the point of view of a sysadmin.

I've recently been tasked with investigating ways of bringing our servers into compliance with at least CIS level 1. We already try and use ansible where it makes sense so the idea of using ansible for this appeals to me, not only for the fact of Check Mode where you can potentially get an overview of what parts of your infrastructure don't conform to a state, thus making auditing easy but not having to bring in other third party applications that rely on agents to scan systems etc...

From an initial google search I've found:

https://github.com/major/cis-rhel-ansible Isn't up to date with rhel7 cis 2.1

https://github.com/MindPointGroup/RHEL7-CIS Seems to be based on shell commands and doesn't leverage ansible modules. https://github.com/MindPointGroup/RHEL7-CIS/blob/devel/tasks/section1.yml#L27 for example: it doesn't follow the PDFs way of disabling that module, nor does it use the ansible modules to add lines to a file (lineinfile), nor does it use the ansible kernel_blacklist module to achieve the same thing. It leaves me wondering what the rest of the role is like.

https://github.com/sanderv32/cis-rhel-ansible Isn;t up to date with CIS v2.1.0

And that's the first page of google done. (Yes I know there's more results, but this is from my very first initial google search).

After doing some thinking these are the conclusions I've come up with:

Do we want to/have to follow CIS recommendations for implementing changes? What will our auditors accept? (i.e. black listing kernel modules instead of registering them with the /bin/true binary)

We need to be able to run this ansible against a server and see what sections it fails against. Again, follow CIS implementation or can we get away with using existing ansible modules.

At the moment I'm very realistically looking at writing my own ansible to do CIS 2.1.0 for at least level 1 server on rhel7.

What are your thoughts? Especially on the subject of "shell: lsmod | grep -vq cramfs" vs "modprobe: name=cramfs state=absent" and such?

Thanks,

Imran

[Bas Meijer]

Imran,

Thanks for your review. In short, please fork https://github.com/MindPointGroup/RHEL7-CIS.git and send in your PR's.

The CIS role endorsed by Ansible is supervised by people of the security firm MindPoint Group, nowadays on a volunteer basis; and you can contribute too! This repo is still a work in progress, but it is based on the newer version of CIS v2.1.0. The role actually lists a lot of shell commands to audit and patch. Some of these could certainly be replaced by ansible modules, but that was not the first priority. Also the CIS benchmark is not yet fully implemented, but the skeleton is there and most 'audit points' are implemented. Many 'patch actions' simply have '/bin/true' because they might introduce unwanted changes to a production system. You can run a playbook with the role like:

ansible-playbook --tags audit --skip-tags patch cisbenchmark.yml

It would be an improvement to add a skip-tag 'unimplemented' to actions having /bin/true, then the run-log would better represent the state of the systems audited.

bbaassssiiee

--
You received this message because you are subscribed to the Google Groups "Ansible Lockdown" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdo...@googlegroups.com.
To post to this group, send email to ansible-...@googlegroups.com.
Visit this group at https://groups.google.com/group/ansible-lockdown.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-lockdown/2ae6086c-579b-4306-a362-30b40e55b554%40googlegroups.com.

[sdo...@redhat.com]

Imran,

Thanks for expressing interest in the CIS roles. They have been second priority behind the STIG roles and haven't received much attention. I would love for that to change since the STIG roles are in a more mature state at this point (though there is still work to be done).

I agree there are some puzzling things when looking through the CIS role. That's mainly due to the fact that it's more a skeleton than a fleshed out role at this point. There are a large number of placeholder tasks, hence all the /bin/true command tasks. The other reason for the plethora of shell commands are the audit tasks. We have decided to remove all audit tasks for several reasons. They will be removed in the future in favor of using Ansible's --check and/or --diff as an auditing mechanism.

All that is a very long way of saying please fork and submit PRs against https://github.com/MindPointGroup/RHEL7-CIS.git as Bas suggested. That's the best way to concentrate efforts and get a working role to the most people.

I'll keep an eye out for PRs. Feel free to reach out if you have any other questions.

---

Sam Doran

[Mauro Medda]

Hi all,

thanks to Bas to introduce me to the Ansible-lockdown community.

I started to write an ansible role for the latest CIS Benchmark CentOS linux.

Below the link to the ansible-role

https://github.com/mauromedda/ansible_role_cis_centos

Please, feel free to submit me suggestion and changes.

Regards,

Mauro

[Bas Meijer]

Hi,

https://github.com/MindPointGroup/RHEL7-CIS is the official Ansible role for CIS compliance. Imran has very valid points about the use of modules vs shell-like actions. But please be aware that the development of this role is no-one's full-time job, I think none of use are paid for it actually. Nevertheless if we to maintain this role then we should take note of these remarks. The CIS recommendations are based on shell commands, and their remediation script is a shell script too. The Ansible way to automate this should be cleaner and better to maintain; and this _is_ by better use of modules.

Bas

On 3 Feb 2017, at 12:18, 'Imran Hussain' via Ansible Lockdown <ansible-...@googlegroups.com> wrote: