STIG interest, CAT I and server roles such as Gluster/Satellite (not limited to that) request input

Latest response

Re-written for some clarity

Ok, we've had a number of STIG discussions in the Red Hat portal.

Thomas Jones started This one in Feb 2017 https://access.redhat.com/discussions/2899931 and there's this one PixelDrift rightly started back from November 2016 https://access.redhat.com/discussions/1295753.

Why did I create yet another one...

I and (I'm sure others) are interested in resolving some of the more difficult STIG items. And the focus here would be the
higher category 1 aka "CAT I" issues (see attached file for CAT 1 items that denote the most severe rating)

This list is not exhaustive, but represents some STIG items that are CAT I issues that currently (as I type this) can not
be resolved...

Now regarding CAT I issues, most of them are resolved. The focus here for this discussion are any STIG items (especially CAT I items) that if implemented will break the function of a server role, such as these 5 examples: (Not trying to focus on FIPS, just happened to have 4 items that were FIPS related)

Yes, of the FOUR items above, I gave four items that are specific to FIPS, however, that being so, my goal with this thread is to get those who know of STIG items (especially CAT I items), that won't work with any given server role.

I have some RFE and other cases that are becoming RFEs that revolve around STIG security items. My customer tells me that we
are to fix/resolve CAT I items because they won't be able to be dismissed.

Red Hat in some replies to our cases have stated that it would be good to know of other customers who would need an RFE to build a buisiness case. I'm hoping that any customer reading this that has written a "POAM" (A POA&M is a management tool for tracking the mitigation of cyber security program and system level findings/weaknesses.) Source=energy.gov against an important CAT I item will submit a case with Red Hat (See Shawn Wells' post below), to help prioritize the resolution of important STIG items
.

Yes, please do not laugh too hard at that last paragraph. I recognize it might be a tall call to expect many to do so, but those interested in security, if customers submit cases that focus on the priority security items within a STIG, it will help.

My initial reply to the Red Hat case I have open is that the STIG and the fact it is a CAT I issue makes the business model because those are the items of highest interest to the DoD or other government components.

Incidentally, it's a misnomer to believe that STIG only applies to the government. Now certainly, they must abide by it by mandate, but there are plenty of other entities (banks, and others I'm told by reliable Red Hat sources) that do use the STIG.

Personally, I believe that any CAT I issue really ought to be a priority for Red Hat since it is of interest to many of their customer base, even if their customer base doesn't report in with a "me too" ticket. Namely because of the severity.

Please consider either in this thread or in a case with Red Hat, any STIG (CAT I item in particular) that can't be implemented because it will break the server role, and open a case with Red Hat, feel free to reply to this thread, and I'll make a cas
e with Red Hat for (qualifier) any valid CAT I STIG item that can't be implemented due to breaking a server role.

So... All of this is in hopes that some others might open cases with Red Hat for those CAT I (or other category STIG items) and let them know their interest. Holding my breath??

Please see the thoughtful reply by Shawn Wells below

Regards,

RJ

Re-written for some clarity

Attachments

Responses

I added a text file with stig items that (I believe) are only the CAT I items.

Open to feedback, if anything is overstated, or whatever, I'll gladly edit/discuss.

Lots to unpack here.

RHEL supports hardware platforms from Laptop to Mainframe and deployments from consumers to military. Default settings reflect an tradeoffs between usability and security across those spectrums.

Ultimately RHEL configuration will need to be customized to meet your security policies. Immediate options include:

  • The RHEL installer can deploy RHEL directly into a compliant state with many configuration profiles. Available profiles are exposed through kickstart and Anaconda-based installations. US Government and STIG profiles are available and fully supported.

  • Consider using the native SCAP Security Guide content to remediate your machine. Remediations are also available on Ansible Galaxy, if ansible is preferred. Either method is supported, meaning the process of hardening and the results. If anything fails to pass the scans, if Ansible remediation breaks, etc -- all that is covered.

  • Manually remediate the findings with the instructions provided in the DoD STIG. For each check DISA generally provides remediation/fix guidance.

Each product is at varying levels of FIPS 140 compliance. Some, like RHEL, are regularly evaluated. Others, like OpenShift, required extensive work. In the case of OpenShift the Golang programming language needed to be patched to use appropriate cryptographic libraries, then the new version of Golang needs to ship in RHEL, then OpenShift needs to be rebased against the updated Golang and RHEL versions, then Red Hat needs to ship the updated OpenShift version, and finally put all that through FIPS (which is a 6-12 month process).

Customer cases and RFEs are used to prioritize what components and products undergo FIPS. Larger products such as RHEL and OpenShift are givens; for smaller components such as Samba an understanding of demand is needed. While it's true every Samba deployment into DoD will need to be STIG compliant, the demand for Samba is incredibly small compared against those asking for Red Hat Storage. Combined they are both less than Satellite. RFEs aren't used to justify the requests (its known they are needed), the RFEs help prioritize them.

Thanks for the reply Shawn,

I concur with you, my hope is that those interested in whatever portion of critical STIG items that currently can not be implemented (such as satellite, samba, gluster, to name a few) submit cases with a theme such as you suggest.

My intent was not necessarily to focus exclusively on FIPS, however to recommend customers who have some STIG item (especially CAT I items) that can't be implemented because it breaks some function [fill in the blank] submit a case with Red Hat to get it properly addressed.

Thanks much, I'll review the post I made and what you said to revise it. Hoping those who need RFEs etc will submit them.

Regards/thanks

RJ

If you can compile a list if items that cannot be implemented, I'd be interested in taking a look. FIPS is certainly a known issues for some components -- but what other challenges are you facing?

I'll come back with what I know about, and will research further, and ask my Technical Account Manager as well, and others I know.

Shawn, yet another issue is the feature in Red Hat Satellite where in order for Foreman to run tasks, it must have a sudoers rule with the NOPASSWD directive and all possible commands. We can not implement that since it is known that if someone does, that account if compromised could have total control over all systems attached to a satellite. We have an RFE for that item. I'll add more. While this doesn't break Satellite completely, it causes those interested in security not to be able to have all the features of Satellite they'd want because they don't want to have an account that has a sudoers directive with NOPASSWD for all possible commands on every client system attached, including the satellite.

I've heard that FIPS breaks Ansible, have you (Shawn) or anyone else heard this or experienced it? I'm planning on discussing this with the other admin where I work who has returned.

Customers are caught in a tricky situation. Requirements like FISMA Moderate, NIST Moderate Impact, and DoD RMF, mandate the use of automated configuration management tools. However the market leaders (Ansible, Chef, Puppet) error when FIPS is enabled. Customers are currently in a spot where they can either use automated configuration management or get a POA&M for FIPS on the Ansible Tower nodes.

There are currently a number of things actively being addressed for Ansible. For example, MD5 hashes are used to compare files on the endpoint against Ansible templates. When the underlying host has FIPS enabled the use of MD5 is blocked and an error is generated.

To get an ATO generally the customers request a formal statement on corporate letterhead from Red Hat regarding FIPS roadmap. Generally these are signed off by myself (representing Red Hat Public Sector) and product management (representing their product) and detail an estimated timeline to full FIPS compliance. Also outlines areas/risks that can be mitigated.

Frequent example of mitigation for protecting network traffic between Ansible Tower and endpoints is enabling Opportunistic IPSec (which encapsulates all traffic in FIPS 140 validated tunnels). Each mitigation has its tradeoffs, but allows DAA's to make a more informed decision. Generally DAA/ISSM staff favor having automation (which creates agility) vs FIPS enablement on the Tower node(s).

Shawn, thanks for the additional information there. My customer is asking we pursue whatever means are possible to attempt to garner more attention to the CAT I items for functionality for the Red Hat products we use. And in particular, those items that are difficult to mitigate such as (but not limited to) the items I listed above in the original post starting this thread (updated today). I realize it's not an overnight process, but if the community/customers can add focus, it ought to help.

Consider creating a support ticket, one per CAT I finding, to get them addressed. When multiple findings are reported in the same ticket it's very hard to triage. Multiple groups step over each other, sometimes it's unclear what group "owns" the ticket. The best support experience will be opening one ticket per finding (or having someone on your account team do this for you, such as a TAM or Solution Architect).

Same thing for FIPS. Generally there are existing engineering activities to enable FIPS (e.g. for Satellite as you called out). While FIPS is a known requirement that spans government and commercial, opening a support ticket helps with prioritization of work.

Internally to Red Hat's BugZilla system every RFE has a "product management score," or you might see it called "PM score." Every customer case that gets attached to an RFE increases this demand signal which greatly helps prioritization and justifies engineering focus.

In regards editing the original post: The discussion forums don't show posting history. No idea what changed or how to respond to it =/

Red Hat informed me today that the following CLOSED bug says FIPS support has been fixed in the latest Samba:

"Bug 1436342 - Bump samba version, required for FIPS mode and privilege separation" https://bugzilla.redhat.com/show_bug.cgi?id=1436342

Thanks for the update, R!

Gladly Dave,

Shawn, yes we did indeed open a case, the same day as I started this discussion. I'm working with my Technical Account Manager (TAM) on that case, and he's dividing it for the reasons you wisely iterated.

My hope in opening this discussion was to get some community input for any CAT I issues with discussion on anything relevant to bring up to Red Hat.

Has there been a solution to the password issue outlined in the OP regarding satellite and a NOPASSWD entry in the sudoers file? While I have been successful in gaining approval for systems without FIPS capability, I will not be able to use Satellite if it requires anything in the sudoers file with a NOPASSWD set.

This is my first post, so please be gentle. I came up with a PAM-based solution to address this issue, so here goes:

Since the stig forbids "NO PASSWD" in neither the /etc/sudoers file or any file referenced by it--and my team and I don't want to have to type a password every 5 minutes while using sudo, I modified /etc/pam.d/sudo and created the first uncommented line that reads:

auth sufficient pam_succeed_if.so user ingroup local-or-ad-groupname

This satisfies auditing/logging as configured IAW DISA STiG requirements and allows us to run commands via sudo without ever having to put in a password.

I know some will probably scream this is a potential glaring security hole I'm opening up, but each sudo command is audited...so maybe the above line, bus specify a group created just for the Foreman account...just my two cents!

Hey Josh, or anyone, as of this post date, has anyone been able to mount CIFS to a Windows 2016 file server from RHEL 7.6 or newer, with FIPS enabled, but without running all the kerberos commands? I'm attempting with RHEL 7.7 now. Thanks. Josh, you rock.

Hey Chris, Unfortunately no, not yet...but you know we're always digging here to try and [queue Jeff Goldblum voice]: "find a way". Of note, it also breaks rdp to MS Windows because if I remember correctly an md5 subset of (I believe the hmac suite) is used and FIPS denied the session handshake because of that (it's been a while since I researched that particular one) but I'm relooking that rabbit hole to go down because I wonder if they could be related.

Hmm... I've set up FIPSed EL7 nodes to be reachable via XRDP and to be able to RDP (via vinagre) to STIGed Windows Server systems. Making it so RDP (to the FIPSed GNOME desktop-host) worked was the bugaboo. Didn't really run into issues going from the FIPSed GNOME desktop-host to STIGe Windows servers.