Comments

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.

NOTE: this discussion was created in 2018, and STIG topics are a moving target. So, keep in mind that this discussion has (as of 2022) information that is in some cases overcome by events (aka "OBE") (such as Red Hat adding FIPS support to Satellite). However, 'NOPASSWD' directives still exist on foreman for satellite, so that's still an issue and I have had a ticket in with Red Hat on that.

This is an old discussion, so again, much of what you see here may be OBE.

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)

(not FIPS related) We can not use the remote command function for SSH keys for remote execution per the documentation found at this link. Basically, to enable the dashboard and to send commands from the satellite as it is today, one must put a sudoers entry to allow the foreman (or whatever account is designated in the satellite) to have a passwordless capability to run every command known to man. This is unacceptable in the STIG and common criteria (Red Hat wrote most of the security releated Common Criteria), but this glaring security issue exists and is why we can't use the satellite to it's designed capabilities which is starkly annoying to say the least.
A Satellite server can not run in FIPS 140-2 mode, and more on FIPS here, The focus here is not merely FIPS.
Gluster also can not run in FIPS mode (I know, another FIPS item, see next paragraph) and this link describes Gluster not being able to run under FIPS
Another, Certain Puppet Build modules will not work with FIPS

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,