Compliance with CIS or other security recommendation

Latest response

It would be good to have the RHEL V7 standard Server installation conform to a CIS or other security recommendation out of the box - this would save us having to make the configuration conform.

MC
Log in to join the conversation

Responses

Phil Jensen's picture Guru 3262 points
4 August 2011 4:04 PM

I took a quick look over the published RHEL5 benchmark from a few years ago. A significant amount of the benchmark seemed like it had to do with reducing attack surface but disabling un-used services. To help drive the conversation, are there significant specific tasks you are having to perform to ensure conformity in your production environment? If appropriate, would you mind sharing them?

bh Active Contributor 124 points
11 August 2011 4:39 PM

One standard my company has to conform to is the Statement on Standards for Attestation Engagements (SSAE) No. 16 (formerly Statement on Auditing Standards [SAS] No. 70).  This standard requires us to report on the use of administrative privileges and to separate out the administrative functions.

 

Where this has hit us the most is in the administration of the Apache web server.  (We’ve also encountered it with JBoss and expect we’ll run up against it with other services, too.)  One basically has to be root to administer Apache after the httpd package is installed.  We need an easy way to `give` the administration of that service to another group without giving them full root access.

 

We opened Red Hat support case 413200, “[RFE] Apache Non-Root User Feature Request” for this.  The suggestion given by the technical support person was sub-optimal -- it was basically `as Apache admin team members are prevented from doing their jobs, create sudo privileges to fix it.`  Unfortunately, that recommendation of a very manual process was the best the support person could do for RHEL5 with the way httpd is packaged.  Maybe this can be improved in RHEL7.

MC Active Contributor 220 points
5 August 2011 8:33 AM

Like many large companies we have a security group who want us to make our systems as secure as possible; both by reducing the attack surface of the systems and by process; we started writing our own requiremets, but this soon became a pain, as it had to be rewritten every new version of RHEL; and we had to argue about what was appropriate and had we missed something. 

 

Moving to the CIS benchmark, resolved most of these issues, as the great and the good have defined appropraite security and we avoid writing documents (which is always good in my book).

 

We effectively have to go through every CIS recommendation and either change our build to comply, or justify why we can not comply, based on the business need - and these days there are very few things we do not comply with. A good example of non-compliance was use of NOUSB, we need USB for ILO.RSA virtual keyboards to work on some servers.

 

I know many other admins who have to do the same type of work for every new version of RHEL.

 

It would save us all time, if the out of the box RHEL complied to the CIS benchmark or some other recognised benchmark, so save us having to make the changes.

 

I know RH work with a number of different standards organisations to show that RHEL can be secured, it would help if the out of the box build conformed, as we did not need to make changes - just monitor the build has not been changed.

ep Pro 479 points
11 August 2011 5:44 PM

We go through the process of getting our kickstart's CIS-compliant. We create all the kickstarts we need based on that and use only those. Not really a pain doing so; we just have to do it the once when the CIS standard is released and then we deploy all new boxes that way.

 

That said, we've had situations where new admins start building boxes without the CIS compliant kickstarts. We have some auditing tool (forget it's name) which helps identify these, and then we have to go through remediating all of them. THAT is a pain. But actually getting a kickstart CIS compliant is no big deal, and if you can make sure EVERYONE uses it, for us it has always worked well.

 

Perhaps if Red Hat pulled a good deal of the items from the RHEL 5 CIS (no RHEL 6 CIS yet I don't think) and pushed as many of the items to RHEL 7 master as possible, that would help a lot. Ideally the CIS document would be short, when released, but I'm sure the CIS doc would be released regardless.

MC Active Contributor 220 points
12 August 2011 10:35 AM

I've worked in the CIS benchmark for 5 and now starting 6.

Agree that it is not a big job to create a KS setup for compliance

But it would be nice if the out of the box install complied.

 

What tool do you use to audit?

ep Pro 479 points
12 August 2011 3:54 PM

I'll have to check, it's done by our Security team not by the admins.

 

Also good to note that CIS is more or less a remediation effort. If RHEL7 was secure to the point that they didnt have anything to report, there'd be no standard. So pulling older CIS stuff into the master would be great but security is an evolving thing so security needs to be re-evaluated continuously. That said, most likely the CIS document will be released regardless, but a shorter doc would be nice.

Duncan Innes's picture Guru 2135 points
29 February 2012 2:51 PM

https://access.redhat.com/discussion/provide-standard-lockdown-scriptspackage

 

Definitely worth looking at is:

 

https://fedorahosted.org/aqueduct/

 

as pointed out by Vincent Passaro.  Only shame is that it's a community project rather than a Red Hat product.  If this project could be rolled into the default RHEL distribution as an install or post-install option, many problems would be solved for us.