Location of STIG Security Profile files on installation media?
Hello,
Does anyone know where I can find the STIG security profile files on the RHEL install media? I see that I can install/configure STIG controls during RHEL install but I can't figure out where those security profiles live on the media. I assume the security profiles are in the form of a kickstart friendly format or a bash script? I’d like to use the STIG security profile as a starting point for a more comprehensive security implimentation.
Thanks,
Rob
Responses
Guru
10133 points
Hi Robert,
To answer your question hopefully directly, examine this link https://rhelblog.redhat.com/2015/10/27/configuring-and-applying-scap-policies-during-installation/.
That being said, I STIG systems on an ongoing basis. You most likely do not want to take every STIG. That is, you probably do not want all of them, but just the majority of them. Which ones don't you want? For starters, the one that says to install a boot loader password because in the DISA provided stig-check-program rpm, that scanner in specific it looks for the wrong stig control in the grub file, and the most current method of password protecting grub, for instance differs from what is checked. So don't follow the recommended procedure that specific STIG says to implement (use that link in the previous sentence for that specific one)
That opens the door to "false positives". And sadly, there are a number of them. Additionally, maybe you can take FIPS controls on the majority of servers. But if you run a satellite server, you cannot, because satellite & fips are incompatible at the moment https://access.redhat.com/solutions/2799971. The same with Gluster for example. If you have an IDM server, by all means enable fips prior to installing IDM else you can't have IDM and FIPS together https://access.redhat.com/solutions/3520171.
So those are a few examples of many. There are other false positives. For operational reasons, you probably will find certain specific servers that you can not implement a specific (or a number of) STIG controls.
It's a lot to read, but examine previous STIG discussions here in the Red Hat discussion area https://access.redhat.com/discussions?title=stig&product=All&tags=All. Some of the discussions are crazy long, and rather scattered, but still relevant.
edited/added here This link leads to some work by Frank Caviggia https://github.com/fcaviggia, a rather smart guy who came up with a stig solution. Now some of the things we've found were heavier handed than what we wished to do, but I certainly admire his work, and there's enough there to learn from and assist. If you do take his work and attempt to use it, then please for the love of bacon, please read the scripts and know what they do, especially what happens to /etc/ssh/sshd_config, in terms of allowed users or groups. Also know he runs chatter +i /etc/selinux/config and some other things. So I'm not saying that is bad, but if you load it because you're in a hurry and then curse the day you downloaded it because it did more than you realized, you'll probably be setting the stage for a Bad Experience™. His work is good, but know what you are getting into and be ready to undo some of the things that perhaps for your organization do not "fit" for your situation.
Kind Regards,
RJ
Community Member
20 points
Hello RJ,
Thanks for all the great info. It's going to take me a while to get through all those links : ) You've helped answer my broader need for an automated hardening method during OS install. From another post, I found the specific answer to my question, which I'll post here for others.
https://myopensourcelife.com/2016/04/16/installation-based-compliance-with-scap-and-rhel/
The short answer is that the security profile information is stored in the following files on the installation media:
/Packages/openscap-.rpm #Command line engine for OpenSCAP /Packages/oscap-anaconda-addon-.rpm #OpenSCAP integration for anaconda /Packages/scap-security-guide-*.rpm #OpenSCAP security definitions
Documentation reguarding anaconda integration can be found on OpenSCAP's website: https://www.open-scap.org/tools/oscap-anaconda-addon/
The slightly longer answer is that Red Hat uses OpenSCAP as their security hardening and control auditing tool. I'm unfamiliar with OpenSCAP and assumed that the security controls were configured using scripts either included in or called from a kickstart file.
OpenSCAP feels a bit like DISA's SCAP Compliance Checker (SCC) but OpenSCAP actually implements controls vs. just auditing them. Based on what I've read so far, it sounds like OpenSCAP might work a bit like the old Windows XP Gold Disk and brick your system if you're not careful.
Thanks!
Rob
Guru
10133 points
Additional...
We made individual scripts for each stig control. We didn't necessarily take the scripts that came from either the SCAP material because they were pretty excessive in application. I eventually put them into my kickstarts and have systems built at minimum of 90.3% compliance (and they are still operational -- and the score is generally higher than that - we are using the most current disa stig check rpm provided, and before discounting false positives, so our scores are actually higher)
I found having all the scripts in the kickstart made life unbearable. So I used %include statements.
So the %include method was nice, because it cut literally thousands of lines out of my kickstarts, and our kickstarts are like 500 lines or less (instead of over 4k lines).
But with %include statements that lead to web addresses, you must be careful. If one, just *one* url is not available for download, your entire kickstarts fails for a vague 404 error (ask me how I know). So I test all includes to make sure they are reachable if I get a 404 error. Initially one thinks their kickstart is not available, but really, the issue is the URL path in the %include, so measure twice, cut once.
Now %includes can be used for a variety of things, even partitioning, the network line, a number of things. I think I first found %includes in Frank's scripts (see previous links in my posts)
The include goes such as this... (in this specific situation, stig scripts go in the post section)
# description of the stig goes here
%include http://cname/pub/files/servers/7/stigscripts/cce-NUMBERGOESHERE.bash
# description of the next stig goes here
%include http://cname/pub/files/common/7/stigscripts/cce-NUMBERGOESHERE.bash
Each (of my) scripts during the kickstart writes to a log that is available after build if it succeeds. So I can check the /root/runcce.log file to see if there were any issues.
We are next going to implement DNS CNAME for the satellite server constant across various networks and consistent file paths. And for a given network, specific files have unique settings geared/tailored to that given network. So I can then have one kickstart for all networks. Then the given settings, configs are specific for each individual network as required, even if the file paths are the same.
Regards
RJ
Community Member
20 points
Hello RJ,
Thanks for the additional information. I like the idea of using individual scripts. It compartmentalizes each control allowing easier maintenance when changes occur in the control language or the OS/application configuration/implementation.
Do you know of any place where I could pull down individual control scripts? I've been Googling like mad over the last week trying to sus out what the best practices are for implementing and managing security compliance. In the past, I'd just harden one system and then clone it. While that process still works, it doesn't scale and isn't agile when changes are needed across a network. I was hoping to use kickstart to build a partially compliant system and then finish it off with Ansible.
Thanks in advance,
Rob
Community Member
88 points
I think it would be interesting to see what Red Hat themselves are doing in terms of DISA STIG hardening. There's so much out there in terms of content it can be overwhelming. Part of my problem is documentation when it comes to checking for compliance with Ansible. There's a good amount of scepticism whenever automation is brought up; I gotta show the original check and best practice the rest of the industry is doing. Outside of DISA. Spell out why things might be different or default configurations with the current Red Hat 7 install.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.