A DoD version of RHEL - A money maker for RH? Maybe!
After my team has spent many, many, many, MANY hours making system checklists for STIGs, I'm thinking Red Hat would be able to charge a wee bit more for a certified RHEL Distro that is "DoD Ready". Meaning that 85 to 90 percent of the 249security STIG checks would be completed "out of the box". I've not seen many STIGs ever actually break the RHEL distro. Very few need to be an exception to properly function as a workstation or a server.
I KNOW someone would pay for that. The time that's "so-called" wasted to verify these checks is amazing. Sure, they'd still need to be verified, but knowing that a cleanly installed RHEL system is already 90% STIG'd would go a LONG ways and save a ton of time and give commands the warm and fuzzy for their security posture. Really, I bet corporations, who are now learning how screwed up their security measures are, would also pay for a better implementation of RHEL. Sure, RHEL is pretty good now out of the box, but it could be even tighter, lets face it.
I bet they'd pay $50 to $100 more per license for a well-crafted STIG-approved OS - with a few good GUI tools to assist them. They're paying a lot of IA and admin folks more than that to maintain the quality of security-readiness that's demanded on the staff now.
STIG Reference in RHN
https://access.redhat.com/discussions/688833
Responses
The idea has merits, although it is difficult to satisfy everybody's needs.
After 30 years in IT business, I still very seldom see systems with, for example, separate file systems for
/var/log and /var, or boot loader password.
Likewise, "SSH Idle Timeout Interval" can cause problems: some processes may stop SSH from correctly detecting that the user is idle.
I have tested vanilla RHEL 7.1 with OSCAP tool and with very quick "customisation" of builds, achieved 81% STIG-compliance.
I have, however, found number of errors in RHEL7 OSCAP default tests. For example:
- "Verify that Shared Library Files Have Restrictive Permissions" fails to detect symbolic links for
the following directories:
/lib
/lib64
/usr/lib
/usr/lib64
The test fails even though the permissions are actually fine.
- "Ensure that System Accounts Do Not Run a Shell Upon Login" fails even though there are
no accounts with Shell access with UIDs below 1000 (except root).
In other words, more work is needed on Red Hat's side :)
Cheers,
Dusan Baljevic
I'm one of the ones who writes the STIGs for Red Hat, working out of Red Hat's U.S. Public Sector group. I'm also one of the upstream maintainers of the SCAP Security Guide.
RHEL must work from laptop to mainframe, from consumer to enterprise. For that reason the default settings come... neutral... regarding security relevant configuration settings. It's incredibly appealing to start offering variants, e.g. "RHEL for Government" or "RHEL for PCI" that come compliant to various regulatory controls, however the engineering/release/QA process would be cumbersome.
So instead, we've been working on developing processes that make (re)configuring RHEL6 and RHEL7 into regulatory-compliant baselines easy. Here's what we've done for RHEL6 and plan for RHEL7. Community feedback would be great :)
For RHEL6, we began with shipping a tool (OpenSCAP) and content (SCAP Security Guide) to attest RHEL6 systems against known baselines. For example, to attest a system against the DoD STIG:
$ yum install openscap-utils scap-security-guide
$ sudo oscap xccdf eval --profile stig-rhel6-server-upstream \
--results /root/results.xml \
--report /root/report.html \
/usr/share/xml/scap/ssg/content/ssg-rhel6-xccdf.xml
Users could now, at a glance, review their compliance status. However, remediation was still a challenge. The OpenSCAP engineers (Šimon Lukašík, Martin Preisler) added "online" and "offline" remediation capabilities. Online meant OpenSCAP would scan the host and automatically run embedded remediation scripts; offline meant putting the embedded remediation scripts into the XML result output (--result in the example above) and letting the user extract that into a shell script.
So, if a customer wants to automagically configure their RHEL6 system to DoD STIG, they'd run something like this:
(notice the new --remediate)
$ sudo oscap xccdf eval --profile stig-rhel6-server-upstream \
--results /root/results.xml \
--report /root/report.html \
--remediate \
/usr/share/xml/scap/ssg/content/ssg-rhel6-xccdf.xml
If users want to generate a bash script containing remediation for the rules that failed, users first run a compliance scan, and then:
$ oscap xccdf generate fix /tmp/results.xml
(defaults to STDOUT, you may want to redirect output to a file)
OpenSCAP's inclusion of online remediation helps kickstart machines directly into profiles, such as DoD STIG, by including "oscap --remediate" in %post section of your kickstart. There's a sample DoD STIG kickstart available upstream:
https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/kickstart/ssg-rhel6-stig-ks.cfg
(note the upstream version pulls from GitHub, not the scap-security-guide RPM in RHEL, so this may need to be edited for some shops)
We hope to improve this further in RHEL7. Vratislav Podzimek, an engineer with Red Hat, modified Anaconda to now include an "easy button" for security compliance. We're tracking to release that in RHEL 7.2, and you can find the public BugZilla here:
https://bugzilla.redhat.com/show_bug.cgi?id=1190685
During the GUI installation users will see a "Security" button. This brings you to a screen where you can select pre-established security baselines, such as DoD STIG and PCI. Kickstart users can continue to use OpenSCAP in their %post sections.
Ever year customers re-evaluate their subscriptions to Red Hat. Hopefully the inclusion of security baselines, and easy processes to use them, helps make your renewal decision easier :)
If you're interested in following our work on security automation, baseline development, and all things OpenSCAP, there are two core mailing lists to join:
OpenSCAP, where tooling is discussed:
- Mailing List @ https://www.redhat.com/mailman/listinfo/open-scap-list
- Development Community @ https://github.com/OpenSCAP/openscap
SCAP Security Guide, where content is discussed:
- Mailing List @ https://fedorahosted.org/mailman/listinfo/scap-security-guide
- Development Community @ https://github.com/OpenSCAP/scap-security-guide
And perhaps gov-sec, which is a Government user community sharing questions/stories/conversation on running Red Hat technologies within the U.S. Government. While unclassified, the mailing list is moderated and requires a .gov, .mil, or known system integrator EMail address to join:
http://www.redhat.com/mailman/listinfo/gov-sec
We're fairly close with SCC's development team. When we've checked with them in the past, there is no mandate that DoD users run SCC. Programs are allowed to make their own decisions, and since OpenSCAP is NIST certified for RHEL, many people chose OpenSCAP. Others chose SCC.
In regards to content, we open sourced the RHEL STIG process a few years ago. We use the SCAP Security Guide project as upstream. DISA calls this out in their STIG Overview:
http://people.redhat.com/swells/rhel6stig/U_RedHat_6_V1R5_Overview.pdf
(ref pg1 [PDF pg5], Section 1.1)
Red Hat now follows the Vendor STIG process to develop RHEL's STIGs. The content we ship natively in the operating system should mirror that which DISA FSO releases, minus the normal version leapfrogging that occurs between rebase cycles.
I am surprised no one has mentioned Puppet in this context, it is perfect for this style of configuration management/remediation with the added bonus that it maintains compliance of configuration through ongoing remediation.
I have written Puppet modules for lock down at multiple sites and they make the process straightforward when deploying to a large number of hosts. Puppet is also an excellent tool for catching when configuration drift occurs due to package upgrade, software installation or administrators getting 777 happy.
With Satellite 6 pushing Puppet integration, it makes perfect sense for these compliance tasks. There are several modules available in Puppet for STIG lockdown, which can be modified for specific site requirements.
It's far more cost-effective to use a generic OS as your starting point and either an automated CM system to lock-down a system per program requirements (and keep them locked down through the lifecycle of a given "server") or even a "gold image" taylor-built to meet a program's specific requirements . With either a CM system or a "gold image" solution, you effectively have a sunk cost that gets amortized over all managed/derived systems. The more systems you place under management, the lower your per system cost effectively becomes. You lose that advantage wiith a higher-cost per server-license certified build purchased from a vendor.
Given the current fiscal environment that the DoD operates under, I'd wager you were incorrect about customers being willing to pay an additional $50 - $100 per "server". This is especially so with the "server" proliferation resultant from the various Civilian, DoD and IC cloud initiatives.
Cost reduction efforts/mandates are a huge part of why there's so much CentOS encroaching on the potential Red Hat footprint within the Federal space at this time. When programs are subbing in CentOS as a cost-cutting measure, it's a hard sell to get them to buy an even more expensive version of a not free OS.
NSA's GovCloud is heavily based on free software: OpenStack for the virtualization layer; and as much OSS as they could chuck in for CM, OS and apps (so their failfast model didn't get bogged down with software procurement cycles and so they could afford to offer a free tier ...and to keep their offering-prices low enough to entice other agencies to adopt their solution).
I'm trying to find STIG configuration scripts for RHEL 5 and RHEL 6.
Is the aqueduct project still the primary source for that material?
https://fedorahosted.org/aqueduct/
I tried to join the group but have received no response. It looks dead.
There's projects all over GitHub. There's projects for stand-alone scripts (Red Hat publishes a set of Bash scripts for EL6). There's projects for CM-driven profiles (serveral for Puppet; a few for Chef; a couple for Salt; etc.). Even the SCAP tools that ship with EL6 come with remediation options you can activate in addition to their compliance-reporting functions.
Basically, you just need to decide how you want to STIG your systems (done once as part of your build; done on an ad hoc or triggered-event basis across the lifecycle of your system; done continuously as part of lifecycle CM; etc.).
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
