New year, new thread? (RHEL 7 STIG)

Latest response

The other thread's gotten stupid long and hard to follow, so, starting anew...

DISA's web site had indicated that the first STIG release for 2017 was to have happened on January 27th. Unfortunately, appears that - not only did they miss the previous quarter's release-date, they missed this one, too. Coincidentally, looks like they also missed the quarterly-date for updating the other RHEL STIGs' updates. Does anyone at Red Hat (or elsewhere) know if DISA's planning to release this quarter or not? If so, any projected dates and any knowledge of whether it will be another "draft" release or if (hope beyond hope) it might actually be a "real" release?


Anyone landing here in search of some viable STIG info, make sure to still see the previous discussion Tom Jones cited in the post starting this thread. Also, make note of the points he made in the first page of that previous thread (and Sean Wells), which basically boils down to if you do the hard work with the resources that are available (see last thread), you (provisionally) ought to be able to get it at least approved at your location (see his comments, previous threads, good points).

I,we followed that advice at our location, and we were able to have RHEL 7 approved last year with the controls we set into place (fulfilling sane controls, see method described by Tom in the previous thread he linked to)

On 20-JAN-2017 we sent another round of feedback to DISA RE71 (aka DISA FSO). On 23-JAN-2017 they sent back another draft with the changes incorporated, which we hoped would be the final.

The process has been very challenging. Each draft means reviewing line-by-line what changed across some 200-225+ configuration checks.

In the mean time, to get stuff done, we've been failing back to the official DISA guidance on "What do I use if there is no STIG?." Their FAQ reads:

Question: May I deploy a product if no STIG exists?

Answer: Yes, based on mission need and with DAA approval.

Question: What do I use if there is no STIG?

Answer: DISA FSO developed Security Requirement Guides (SRGs) to address technology areas. In the absence of a STIG, an SRG can be used to determine compliance with DoD policies. If there is no applicable SRG or STIG, industry or vendor recommended practices may be used. Examples include Center for Internet Security Benchmarks, Payment Card Industry requirements or the vendor's own security documentation.

Question: Does DISA FSO certify products for use in the DoD?


No. DISA FSO certifies Information Systems for use in DISA. DISA FSO not does certify products for DoD use. SRGs/STIGs are designed to assist in implementing the secure deployment of products.

"Answer: DISA FSO developed Security Requirement Guides (SRGs) to address technology areas. In the absence of a STIG, an SRG can be used to determine compliance with DoD policies. If there is no applicable SRG or STIG, industry or vendor recommended practices may be used. Examples include Center for Internet Security Benchmarks, Payment Card Industry requirements or the vendor's own security documentation."

I read this as STIG -> SRG -> Vendor Guidance. I have had the pain of going through multiple SRG inspections and I would rather never do that again. I have never been through one for RHEL, but I know that a General Purpose OS SRG is posted.

Has anyone had DISA RME do an inspection where they didn't accept the Red Hat policy and instead used the SRG? We used the RHEL 6 content the last time we did an inspection because they would not accept the Red Hat policy.

The RHEL7 Vendor STIG is the RHEL7 implementation against the OS SRG. They're the same.

This is the upstream edition. The official version of the RTM ships via the scap-security-guide package and gets installed into /usr/share/doc.

Good deal. Thank you.

There are policy mapping files for both NIST 800-53 rev4 and the OS SRG. Feedback on how/if they're being used, if the control mappings are found sufficient for security accreditors, etc would be extremely welcome and valuable.

I... I can't even come up with a reply better than a GIF

That sums it up pretty well Tom

Is this the place for real answers? Or, where can I get help with implementation and troubleshooting? I'm using OpenSCAP RHEL7 STIG Server Running GUIs. While the RHEL7.3 Installer (DVD, dated 2016-12-02) contains v0.1.30, I'm pushed to apply the latest (now, v0.1.31). I've seen improvement - particularly with the ssh fixes, although I'm perplexed that PrintLastLog still is not. But also new rules are added that don't work - many for GNOME, in particular.

Sorry. Mostly opened this thread for status-tracking purposes.

In our environment, we don't do CD builds. We don't even really KickStart much, any more (we're probably better than 90% virtualized, at this point, and our builds come from generalized templates with launch-time provisioning tasks initiated via CM-hooks (SaltStack, Puppet, etc.)

Since DISA can't seem to be asked to put out a timely STIG, we recently opted to leverage the vendor-STIG content and tools. We run whichever version of those tools is available in our yum repositories.

Hi Sam Dana, see the previous thread that Tom and I both spoke of, read through it. I surmise your "hair is on fire" meaning you're in a dire need for answers sooner than later, but it will help to go through the previous thread. I'll let you know up front there's a cacophony of bits in that previous thread, but there is also quite a lot of useful information.

I and my teams have RHEL 7 approved (I spoke about this in the previous thread, and Tom spoke about this as well). My process was a tad bit different than what Tom mentions below (he's using the vendor method, see context in -this- thread), and we used SCAP and other sources, including the pre-release stig among other things we have available.

by the way, a side note, we strictly at our location avoid the use of a server-with-gui because it's just that much more to mitigate. you can make your own choice, but we never (with several customers) use a server-with-gui for true servers in a data center.

Good luck, please re-read this thread for tips for the last thread.
R Hinton

Heh... Wasn't until one of our developer-groups started doing "cloud (RHEL) desktops" (was easier, especially with a mobile workforce, than trying to get developer tools deployed to regular desktops) that I discovered bunch of bugs in the assumptions I'd made when I put together the STIG-oriented CM-automation for our EL6 builds. We'd gone nearly two years before those bugs revealed themselves.

Has anyone heard how bad the latest RHEL 7 STIG V1R1, release around 27 Feb? It seems like their dates are off, or maybe it's me.

Was notionally released 3/13/2017 (see the date on the STIG page for UNIX). Given that the date DISA typically lists is the date it was published to their pre-prod site rather than the date it was actually made available on the Internet-facing site, it may have just shown up.

[Edit] ...yeah, benchmark files haven't even posted to the NVD, yet. Even if I were to use the content to remediate a system to the DISA spec, my customers' accreditors wouldn't even be able to verify it, yet.

Either way, its notional availability is likely too short for people not directly involved in its creation/release to have done an evaluation.

Thanks Tom!

Nor will benchmark files show up. DISA has stated they do not intend to publish automation content (in SCAP or any other format). Currently the SSG content developed with NSA and shipped natively in RHEL (against the DoD RHEL7 Vendor STIG, a superset of what DISA published) is your best bet.

Working with higher-level DoD Information Authorities to publish a RHEL7 DoD Secure Host Baseline -- which will include automation.

You're kidding, right?

So... What's this do for tools like Nessus that typically want that benchmark content?

Just to make sure I am understanding you, DISA has stated there will be no "benchmark" content to load into SCC or some other SCAP utility?

As far as a RHEL 7 SHB, what is the goal of that? Would there be a separate baseline image for each version (server, workstation, desktop)? Not to mention the different versions based on the number of processors, etc.

Pre-hardened builds is exactly what we've been moving away from. They're just not an agile (small "a" intentional) enough a starting point for our cloud-oriented efforts.


I'll attempt to organized my toughts here. I've worked with J. Bell and others in Augusta, GA for many years. I know you just met with them in the past few months. I would have attended, but was working else where at the time. I heard good things about your talks while there and how you were on the phone with DISA asking them not to release too early. "We're watching". LOL

I've sat here a few moments considering whether or not I should open this "can of warms" again. The can of pre-hardened RHEL. In recent years I have talked with co-workers at multiple DoD sites. And most recently, last night, I was talking with a Red Hat employee, no names mentioned. But we all agree that in the state in which the DoD currently stands, in regards to STIGs, general hardening, and other security BS & policies being pushed down, we believe there MIGHT be a small percentage of revenue in which Red Hat could make by providing a pre-hardened RHEL release. Even if there was simple a check-box during installation in which the hardening process would be applied, and even if it was 85% of the STIGs. Heck, provide it free of charge and you'll still sell more RHEL. This would be good for ALL customers of RHEL, not just DoD and PCI folks.

  • Provided and tested by Red Hat Engineers for their own product(s). Who can do it best? The customer? NO, I don't think so.

No matter how Tom replies, there are so many shops out there that find it challenging, to say the least, to keep up with all these security standards. Tom may harden one way using Ansible, I may use Puppet (NOT), and others still may script it out per release. All experiencing different levels of success. Many RH customers do not even use cloud-based technologies. There are so many different ways the community is deploying RHEL systems it's truly an eye opener. Some are making appliances that aren't even on PCs or puffy clouds.

IDEA: If RH did provide that magic check box or a pre-hardened version (free or not), the system installed would also provide the overall results documentation and provide an estimate of the overall risk to the owner. We feel that many commanders and other leaders may be willing to adopt Linux more if they new their struggling staff could more easily and more accurately deploy with a moderate level of lock-downs in place.

Let's face it, if written and used correctly, most Cat 1s and 2s will not break anything. It's the Cat 3s that take more time to research and involves more "breath-holding".

Think of it. A nice little bullet noting "RHEL 8.x", * Pre-hardened or * Meets 90% of DoD STIG standards. We promise, from how we see it here in the trenches, it would be worth it to Red Hat.

It's just not me saying this. I'm just the one willing to type all this stuff out on a community forum. I've been in two good sized RHEL groups in many years and I'm one of the very, very few participating on these forums - for whatever reason. Some vendors, like Sun Microsystems, didn't listen to the customer at times. Where are they now? Not that Red Hat would easily let a crummy company purchase them, but, just saying.

Just mine and others' viewpoint (soap box).

Piece out. Now Tom, be nice! Have a cookie! :-)

You've pretty much described the entire point of the oscap utility's --remediate option. Basically, pick a pre-canned profile, add the --remediate flag and go. If the pre-canned profiles are insufficient, use the scap workbench to do the requisite customizations (then reference that profile in your oscap call).

You can apply at KickStart or you can apply continuously via your CM tool of choice (either by re-doing its contents in your CM-engine's DSL or just wrapping the call to oscap in your CM engine's DSL).

The inherent problem of pre-hardened builds is they lack "velocity". You're likely looking at a new release along the same frequencies that 7.x moves to 7.x'. That's kind of a killer if you've got an elastic workload. It's potentially a killer even for static workloads if you're leveraging automated builds to effect an automated recovery. In short, pre-certified builds are fine the day they release, but become less and less fine with each publication of a patch (since you've gotta wait for all the intervening patches to apply before your system's build declares ready).

On the subject of patches: the moment there's a security-relevant patch published, your "it was deployed pre-hardened and will forever sit in a closet unchanged" pre-hardened method becomes no longer valid/of value. Meaningful hardening isn't a "do it once" activity, it's continuous (or, at the very least, has regular periodicity).

It will be interesting, if not disheartening, to see where this DISA situation goes. I'm moving farther out of the DoD next week. But will still touch it at times. We'll see how the other side lives. LOL


To give DISA credit, there really is positive momentum.

Given the time delay between RHEL7 GA and release of DISA's RHEL7 STIG, the DoD was at a point where something was needed. DISA published what they could, which included public feedback, even though full consensus between DoD, DISA, and Red Hat wasn't achieved.

Moving forward the hope is to (re)align the DISA content against the OpenSCAP/SCAP Security Guide. In the RHEL6 days, the content followed the general upstream-->downstream process and differences occurred mostly because of release schedules. For example, upstream might release in May but DISAs quarterly release wouldn't occur until July.

The aspiration for "DISA STIG v2" is to reestablish that upstream-->downstream process. If that happens, the SCAP content shipping in future RHEL7 releases will be (mostly) aligned to provide for the 'prehardened' experience.

To make that happen, DISA dedicated new resources to collaborating with Red Hat and DoD. Might be slow, but is very positive progress!

That does sound very positive indeed. Thanks for the clear update Shawn.

Just getting on it, this week. Haven't actually checked content-validity - stuck wading through the copious remappings of IDs from the drafts to this release. No, I don't know why they can't just use consistent mappings from draft-to-draft or from the final draft to the first release. The EL7 STIG process has made me pretty much give up on trying to make sense of anything DISA does.

At any rate, once the remapping is done, then we can begin the process of seeing what's stayed the same, what's completely changed and what's received only minor tweaks.

Much grumbling has ensued.

FWIW - the mapping inconsistencies are caused by DISA's VMS tooling. Every time a new baseline is changed we can expect the control identifiers to change =/

Wow... You're just a fount of good news today. :p

So, is that group's current working-model, "let's identify all the ways we can do things The Wrong Way(TM) and do those?"

I noted one of the files named "U_Red_Hat_Enterprise_Linux_7_STIG_V1R1_Manual-xccdf.xml" which I'm going to attempt to load into SCAP. Has anyone else found this to work with SCAP or am I missing something? will try later.

Sorry - I typically just use their Java-based STIG-viewer. What you need - and that they haven't published, yet - is the "Benchmark" bundle. That contains the full file-set you typically want for the os's SCAP utility. Similarly, it's the content needed by things like cscc and Nessus.

thanks much Tom

DISA decided to not to publish automation content. A good alternative would be the NSA-lead DoD/Red Hat SCAP content (via the OpenSCAP/SCAP Security Guide project).

There have been positive talks with DISA to resume their collaboration with DoD and Red Hat via engagement in the SCAP Security Guide project. The goal is to resume the model from RHEL6, whereas OpenSCAP served as the "upstream" and DISA would snapshot for periodic "downstream" releases from

To demonstrate field support for DISA to collaborate in such a manner, it'd be great for interested parties to send a note to their DISA POC. This would go miles in documenting if and how much demand there is for DISA to publish automation :)

Are you aware if the OpenSCAP content is acceptable under RMF? This is the biggest concern here at my organization. If DISA is unable to provide the content on a timely basis, we need to at least find another way to comply with RMF standards. Overall, we're getting mixed messages of "acceptable" forms of documentation and benchmarks.

What's deemed "acceptable" is organization-specific. That said, all of the OpenSCAP content is fully annotated with references to the relevant RMF controls.

Open source communities come together to develop the SCAP Security Guide content. When the content ships natively in RHEL (via the scap-security-guide package), it becomes commercial vendor guidance.

Suppose then the question can be rephrased as "Is vendor provided security configuration content acceptable?"

But because content is co-developed with the government, can also ask "Is NIST and NSA provided security configuration content acceptable?"

The US Gov-RedHat collaboration means the content is one in the same.

Thanks, I will bring up these points to our ISO/ISMs the next time we talk to them. It's been very confusing during the transition from DIACAP to RMF.

Wow, no benchmarks? Well, thank you all for this thread saga. It helps some of us know what's going on with this situation.

Oh, as a side note. I'm not sure what time zone you guys are in, but the posts that were must submitted by Tom and Shawn (21 march) say they posted 3 or 4 hours later than Eastern Time Zone. I'll see what THIS posting indicates once I submit it. I'm on the East Coast too.

Edit: Yup, posted as "4:26pm", but it's 12:26pm Eastern. Are these forums served from Europe? I'll poke around my profile for a time zone setting.

Hey Tom, et. al.

Did I see somewhere in this thread, or the previous older thread, that someone mentioned the fact that the DoD, or some entity, was starting to except the OpenScap results in lieu of the DISA STIGs for RHEL 7? It sounded something like that. I cannot quite remember. I think it was mentioned in the past few months. I'll keep searching.

Do that ring a bell with anyone?


Likely was referencing DISA's FAQ page at

The language there states vendor supplied security guidance is acceptable if DISA hasn't published anything. Now that they have, I'm not sure anyone can follow that FAQ anymore =/

Yeah: we'd finally gotten the OK to do vendor-content. Then DISA decided to release a non-draft STIG. So, naturally, we're getting questions on "this means we can use the official STIG, now, right". Explaining, "while that's a decision you could make, you need to know that the tools you use that expect benchmark content aren't going to work: we can continue forging ahead with the vendor content and tools, or we can fall back and lose another several months" and then reminding them that RHEL 6.9 just released and is (notionally) the final RHEL 6 dot-release.

Good times.

In the upstream space, the new DISA identifiers have been mapped to existing OpenSCAP/SSG rules (ref: pull request).

If you're able to use the upstream RHEL7 Vendor STIG content, you can show your security guys how the rules map back to DISA content.

:: standard hand waving on the following not being an official Red Hat roadmap commitment ::

The next SSG rebase will be for RHEL 7.4. Since the new mappings are already upstream, they should ship in the RHEL 7.4 rebase.

I think I found it. Seth Kress posted it on 7 February (above). That must be what I'm thinking of.

The language in the policies should allow for POS versions.



Throwing this out there for feedback:

I was with NSA Information Assurance and Red Hat Security Engineering last week. We chatted about hosting a public "security update" call. The idea was for NSA (as the Information Assurance owner for classified systems) to speak publicly about current and future policy and have Red Hat step through current + roadmap elements to meet those policies. Make some demos where appropriate.

Example topics:
(1) Common Criteria Certification now requests vendors publish SCAP-based configuration verification as part of the certification. What is the link between Common Criteria, DoD Configuration Annex's, STIGs, and the OpenSCAP content provided natively in RHEL?

(2) New and updated Identity Management + PKI requirements are popping up across civilian and DoD segments. What is Red Hat's roadmap to integrate Red Hat Certificate System into Red Hat IdM? Will it be government certified -- when, with what capabilities, and to what standards?

(3) How do NSA/NIAP, DISA, and Red Hat envision STIG'd systems to actually operate? Lets step through the policy side, as relating to going through the NIST Risk Management Framework, and also step through some demos on how to provision and lifecycle a RHEL-based system.

There are many, many interesting topics. A series of calls might be more appropriate. But would something like this be interesting to people? What would you want to hear about? What technical workflows might be interesting to you?

I can definitely tell you I would probably have a group of people that would love to attend such an event or event-series.

YES! "What Tom said".

I'm about to lose access to these forums as I transition to my new company. Once I get a RH contract I'll see if Red Hat help desk can combine my previous business account postings with my new one.

Great info by everyone. Thanks again for sharing what's going on behind the scenes.

Tell your new company to sign up as a partner. That should get you the access you need. If you've got posting history you want to keep, you'll need to contact Red Hat to have your forums profile moved to your new account under your new company's partnership.

Piling on late. YES! This would be most welcome!

Hi, I am fairly new to this world of trying to STIG RHEL. So from the reading it seems like there is not going to be a benchmark released for automated scoring. I am wondering then what people are doing instead? My understanding is a bit lost here on what people are suggesting to do. Currently I have been just following the STIG as released, and trying to follow it write scripts for what I can. Although, some of the STIGs findings and fixes do not even resolve the initial findings. Once, I get done with this what is the best way to then attempt a score? I did see CIS's bench mark with a list of what they scored, and didnt.

Since we'd just gotten authorization to leverage oscap, when the "real" DISA ones dropped, we provided our leadership a writeup on the status and impacts and they agreed to continue with going the oscap route.

Our only "problem" now is, that while we can use oscap on our EL6 and EL7 instances (opting to reduce the number of tools required, back-ported our automation to use oscap for EL6 as well), we're still stuck with scc on Windows. If you haven't had the misfortune of using scc, it's ungodly slow (literally: things that take oscap a few tens of seconds to do, scc takes upward of five minutes).

Going the oscap route also means we can be proactive and use the upstream content rather than waiting for DISA or even RHEL to push out hardening guidances.

Have you used oscap with the currently release STIG? I am attempting to do this but not have a lot of success.