New year, new thread? (RHEL 7 STIG)
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?
Responses
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?
Answer:
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.
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.
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
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.
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.
Shawn,
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! :-)
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!
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 disa.mil.
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.
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.
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?
Thanks!
Likely was referencing DISA's FAQ page at http://iase.disa.mil/stigs/Pages/faqs.aspx#STIG.
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 =/
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.
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?
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.
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.
Pages
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
