STIG it to me, RHEL6! (computer security isn't hard!)

Latest response

Many of you out there work within the Government or "Public" sector.  Others of you are Security Enthusists like myself now have another reference point when we want to look at great ways to harden a Linux system.  The U.S. Government publishes serveral great guidelines for making security better on your systems.  The first of these is the STIG (Security Technical Implementation Guide).

The new RHEL6 STIG guidelines can be found here:

along with the RHEL5 materials.

Another great source of security/hardening is NIST (the National Institute of Standards and Technology).  Under their National Vulnabiltiy Database they provide checklists for assorted products to strengthen their security profiles:

Another great resource would be from our friends at SANS (a company dedicated to security research and certifications).  They have published another great resource in their Linux Security Checklist:

So Community, what tips can you share to make things more secure?  Do you follow any/all of these guidelines?  What other resources have you found helpful?  We'd love to hear from you!


So, they're finally out of draft stage?

This is my favourite hardening guide for RHEL 6:

It's created by CIS (Center for Internet Security).

Indeed!  Thanks for sharing Kamil!

How to check a system for STIG compliance? Does a testsuite exist for that or do I have to build one for myself?

This early in the STIG release-cycle, it's usually a "build them yourself" proposition.

Have a look at the Aqueduct project:

Great resource in the making there.  There was dwindling activity until a few weeks ago - then things just exploded into life again.  I've not fully caught up on the mailing lists since the recent activity, so I can't say exactly what's happening.

Also, Red Hat are pushing a bit more with their OpenSCAP stuff via Satellite.

Ultimately, it would be nice to be able to do a secured build of RHEL having chosen which guideline to follow at kickstart time.  The deployed system would have removed the security risk packages and locked down the rest of the install in line with your choice of STIG, NIST or CIS (don't mean to exclude any there, those are just the ones I remember off the top of my head for now.)



Here's a bit more background on the RHEL6 STIG, and where Red Hat is going with security automation:

The SCAP Security Guide community publishes comprehensive guidance, from which policies such as the STIG and NIST USGCB are derived. The idea is to have a common body of guidance, of which can be easily tailored in the formation of custom profiles.

Don't need 14 charactor passwords? Change the variable to 5.
Don't need audit logs retained for 90 days? Change the variable.
Don't care about SUID file permissions? Remove the check from your baseline.

In regards to hardening at build time, check out a sneak peak of what *should* be making its way into RHEL7:
(1) SCAP content based configuration in Fedora installation

(2) SCAP content based configuration in Fedora installation (update1)

Today, via the SCAP Security Guide, you can perform automated compliance scans for tailored baselines. These scans can be ran via CLI tooling (OpenSCAP) or via GUI tooling (Red Hat Satellite).

Progress is being made to create remediation scripts, so if you're a bash scripter, please consider contributing!

This isn't official Red Hat guidance or anything, just the process I use:

(1) So, you wanna STIG a RHEL5 box? Part I: Using the DISA RHEL5 STIG

(2) So, you wanna STIG a RHEL5 box? Part 2: Using the Aqueduct Project

Aqueduct has gone through a few iterations since that post, so you *should* receive fewer false positives.

Remediation scripts are just now being built for RHEL6 content, however the automated scaning piece (pass/fail) is available in the SCAP Security Guide @