Red Hat Enterprise Linux 7 STIG
With the release of RHEL 7.1 imminent, I was wondering if there was an ETA for the RHEL 7 STIG?
Is it possible to access pre-release or beta versions of the document/guide?
Responses
Guru
6827 points
Russell Goldberg, and everyone...
Imagine a # ./createiso.sh rhel-server-7.3-x86_64-dvd.iso script that creates a stand-alone DVD for your own use to create STIG hardened systems with the appropriate banner (for graphical workstations), or banner for ssh logins. I've found it covers most (not all because time marches on and more mitigations exist).
I found this nice bit written by Frank Caviggia, a Red-Hatter who wrote a rather sublime script that has a custom isolinux.cfg and stig hardening scripts with the usual GNU License and no warranty of any sort (use at your own risk).
Okay, it's a script with a collection of files that you match with a current RHEL X.X (6 or 7, depending which github project he made from what you pick from the google search above) iso file that builds either a workstation or server build STIG hardened bootable ISO with a custom menu (USE LOW GRAPHICS INSTALL!!). Did I mention, use LOW GRAPHICS installation from the boot menu, (for those who find the install hangs, remember this paragraph).
I edited it a bit for our own partitioning requirements (like /var/tmp being a partition, see previous discussions such as Tom Jones mentioning the fallacy of doing a bind mount of that to /tmp). Our edited version exists in a stand-alone development location that we can't share - but the sources above will give you a good starting point.
1) Go to google, search for "Frank Caviggia createiso.sh" (without quotes). (see links in #2 below)
2) He has several editions, apparently for RHEL6/7. (those are hyperlinks leading to those projects)
3) Edit within the sane appropriate use of the spirit of the GNU License keeping in mind Frank's caveats, warnings, no support, and in particular that Red Hat does not (repeat "not") support it.
NOTE: the usefuleness for our situation is for some unique cases. We have our own mitigations in place on our satellite servers. That being said, this could be a useful utility for those that are at the beginning of the road for STIG usage.
That being said, I highly recommend going over the kickstart file "ssg-rhel.cfg", and for the love of... Micky Mouse, PLEASE read the "README" file. The "menu.py" is what pops up when you first boot into the resultant iso file.
Please read the scripts and other files before implementing. Please test in non-production, and do not commit this to really important systems until you have understood & vetted it's impact and function. I personally consider this a starting point and there's other ways to do this for enterprise-level deployment that are saner than a stand-alone DVD. (we build the bulk of our systems using satellite servers, not this utility I'm speaking of in this post).
Apparently, there's a centos version I've not tried as well from the resultant google searches.
Anyone reading this, please oh please, edit for your own use, read the README file, and the entirety of the kickstart file, the createiso.sh and other bits. Remember the GNU license file as well, and that Red Hat does not support this.
Red Hat
Active Contributor
312 points
Frank left our team back in March, now working on cross domain systems at MITRE. You can catch him on LinkedIn.
The upstream for the kickstart projects are here: - https://github.com/RedHatGov/ssg-el7-kickstart - https://github.com/RedHatGov/ssg-el6-kickstart
The installation media creation scripts aren't a formal "product" of Red Hat. They don't fall under the standard subscription support agreements or anything, but we post and maintain them as a community service. Tickets and patches welcome on their project pages :)
With the STIG integration directly into the RHEL installer (which is completely supported by big Red Hat), are these projects still useful/needed?
Here's a 50 second YouTube of the RHEL 7.0 installer. Since that time, profiles are included natively (vs needing to fetch over HTTP). Profiles have been expanded to include RHEL7 Vendor STIG, PCI, FBI CJIS, and a few others.
Guru
6827 points
Thanks Shawn for the improved links, I attempted in my post to mention while it was written by a Red-Hatter, that it was certainly not covered by Red Hat Global Support services.
I've tried the STIG integration profile feature, yet even though i cited the stig profile, I'm not sure it actually accepted it. I think Frank's example carried additional stig requirements that the install ISO could carry without the benefit of updates like from a Satellite server. I suspect the stig profile in the iso is chained to the date of it's minor release date. I believe what Frank did had STIG mitigations that came after that date. The STIG profile feature that comes with the install disk (or can be cited in a kickstart) may not necessarily have the banner program that was included in the github project Frank created (for example), along with the other banner classifications available with the install.
As I mentioned in my own post above, all of this can of course be achieved through a kickstart with a satellite server etc, there are some unique uses where that disk is useful.
I'm going to test the stig profile feature in our development area to see how it does and then use the scap check to see how it fares.
Thanks Shawn
Guru
6827 points
I think this thread has gotten to the length that edits to previous posts now fail with a page full of odd text.
Frank Caviggia, I don't know if you ever read the Red Hat discussions, but you made a very nice product. I did add additional stig mitigations that seemed to have arrived after your last edit on these projects some months ago. (see my last entry for context)
Newbie
5 points
I'm glad you like the scripts, I developed the installer to do installs in the field with a customized profiles - I've further developed the scripts at MITRE to include additional automation using packer VM and AMI builds for RHEV, VMware, VirtualBox, Amazon, and other platforms - I have to go through the MITRE release process to release this (lawyers and such). The script uses the SCAP Security Guide and allows further customization to meet requirements that the SCAP Security Guide either currently doesn't meet (see ssg-supplemental.sh scripts) - I originally developed the scripts based off ideas that Tim Siegler and myself worked on at Sandia National Laboratories (although, I had to totally re-write things from the ground up while at Red Hat). I'm glad that you and other people enjoy the work and I plan to continue maintaining the RHEL and CentOS ports of the projects as they do the community a service. I welcome patches and contributions to the projects as things move forward.
Active Contributor
107 points
There might be a better thread to post this, but this seems pretty important to get eyes on the subject.
I keep hearing different RHEL groups around me talking about getting the audit.rules correct for RHEL 7 and that the DISA draft STIG, as mentioned in this thread, cannot be trusted to create such a critical file as the rules.
Where can community members find an approved known-working copy of a good RHEL 7 /etc/audit/rules.d/audit.rules file? There's no reason for DISA approved customers to be recreating the wheel, especially when just getting a system to a good baseline.
I know there is a github for RHEL6 STIG scripts, how about RHEL 7?
Thanks a lot.
Chris
Guru
6435 points
Really isn't such a beast. DISA individually prescribes each rule rather than as a consolidated "here's an approved rule-file".
The real problem with the currently-prescribed rules is that not all of them are valid - or, if they are valid, "order matters". The latter part is a key problem: some of the individually-prescribed rules will block others from being added. So, if you want your auditors' tools to say "yep, this rule is present" (validity of that rule be damned), you need to ensure that your insertions are executed in such order that no rules get blocked.
This means that your rules file(s) (pluralized because you can add rules - singly or in groups - by adding them to files in /etc/audit/rules.d/ that RHEL7 converts to an ordered, monolithic rule-file) need to be ordered "just so". Where we've encountered order-issues, we've taken advantage of the read-order of the files in /etc/audit/rules.d/ to ensure that files containing blocking-rules are read after files that contain blockable-rules.
Granted, the current STIGs are still "beta", so this dancing about may be rendered moot once the final STIG gets released.
Active Contributor
107 points
Thanks Tom. I hope there's a boiler plate version provided by someone someday. Teams are so busy no-a-days with normal admin jobs and now answer so many IA questions that a Linux team likely may not have an audit-configuration genius on hand, so to get this rule file right from a clean install should be considered paramount just to properly meet minimum audit standards. There's so much time being "wasted" on this subject alone - from my observations in two shops.
Can't wait to see if draft .3, or whatever it'll be called, to see if it will be a reliable 7 STIG. I had an IA guy almost install group "X Window System" the other day because of the damned STIG DRAFT .2. I can't believe DISA thought doing a , ID RHEL-07-040560, was a good way to check for X packages. Geeze.
Guru
6435 points
While I imagine there will end up being many people that come up with a boiler-plate file, it's equally unlikely that DISA will "bless" such a consolidated file. There's also a non-trivial likelihood that said files would only ever be published internally, any way, since security groups are often sufficiently-paranoid that they'll attempt squelch such community-serving efforts for fear of "letting attackers know what we're looking for".
There's also the increasing use of both launch-time and life-cycle automation of system configuration tasks. For example, my main project has the goal of being able to take any generic build and harden it based on organizational profiles (or re-harden it based on a trigger event ...like a failed IA scan). Thus, each STIG-prescribed control that we implement is individually-enumerated and de-selectable with a "skip this" type of flag. Deployment profiles are registered with IA so that their tools scan based not on a single, static, "enterprise-wide" hardening recipe but on deployment-appropriate profiles. While I don't necessarily anticipate that some profiles will say "skip this audit-rule control but not this one", I have to at least account for the possibility of such.
Things are only going to get more interesting as velocity increases. AWS posted a slide at re:Invent this week that captures some of the evolving security landscape. Golden Image and other static configurations are going to be harder and harder to justify in these landscapes. On the plus side, accommodating velocity is an interesting exercise. It's brought back to the fore the types of things that used to make SA type of work less drudgeful.
Community Member
25 points
First of all is this the same R. Hinton that would call me when his IPL broke?
Now to contribute. The current submission I have before our security apparatus as an approved baseline is using a combination of the NSA scripts and OSCAP for draft STIG compliance. I am attempting to get traction using the NIST 800-53 ANSIBLE role Has anyone taken the leap in a production environment?
Guru
6435 points
Problem isn't so much content - as loathsome as the DISA content is, it's interpretable into a mostly workable form - it's getting your DAA to sign off on other than official, "final" DISA content.
Red Hat
Active Contributor
312 points
We meant the rhtps account to be more of an internal staging repo. Before you go to far down the path, you may want to start using https://galaxy.ansible.com/RedHatGov/800-53/ and https://github.com/RedHatGov/ansible-role-800-53.
A US Intelligence customer let us open source that specific ansible playbook, which was generated in support of an ATO at their agency. I tipped off the RedHat guys who wrote it to comment here (as they have the full background + insight into who is using and where). Note Red Hat begins a corporate holiday shutdown this week, so responses may come next week.
Red Hat
Expert
845 points
http://iase.disa.mil/stigs/Pages/faqs.aspx#STIG
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.
Red Hat ships a RHEL7 draft STIG with the scap-security-guide.
Guru
6435 points
Which is half-assed "out" to try to buy time. That FAQ item isn't going to open the floodgates of adoption. All it really means is that the DAA has to make the decision, "that's good enough for me" or "no thanks, we'll wait for the formal STIG to be published." Really, it's the same decision they could make, before - it only very, very slightly tips the scale towards pre-DISA adoption.
Guru
10133 points
Note to anyone landing at this thread as a result of a search engine result etc...
Tom Jones has started a new thread at this link https://access.redhat.com/discussions/2899931 with the intention of carrying the conversation further at that link.
Pages
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.