STIG interest, CAT I and server roles such as Gluster/Satellite (not limited to that) request input
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)
- (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,
RJ
Re-written for some clarity
Attachments
Responses
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.
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).
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 =/
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
