STIG Profile Removed from CentOS 7 Data Stream #3743
Comments
|
On 2/7/19 1:51 PM, mrabe142 wrote:
Is there a reason this and the other profiles were removed in the
latest release or is this a bug?
Not a bug.
CentOS does not have a STIG. Shipping a CentOS profile called STIG lead
many people to (inaccurately) believe a CentOS STIG existed (and thus
was OK for DoD use).
|
|
That is unfortunate but I understand the reasoning. It was convenient for running CentOS is testbeds, RDT&E, and other testing infrastructure on non-DoD systems since it doesn't require a subscription then using the same automation to deploy to RHEL systems when doing something more official. Is there an easy way to create a custom profile that looks close to the removed one without recompiling the SSG? |
|
On 2/7/19 3:39 PM, mrabe142 wrote:
That is unfortunate but I understand the reasoning.
It was convenient for running CentOS is testbeds, RDT&E, and other
testing infrastructure on non-DoD systems since it doesn't require a
subscription then using the same automation to deploy to RHEL systems
when doing something more official.
Never understood why such setups exist. RHEL is free for development,
has been for years:
https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscription-now-available/
Is there an easy way to create a custom profile that looks close to
the removed one without recompiling the SSG?
Definitely. SCAP Workbench could be used to tailor a profile to look
similar.
|
It it a matter of scale. The development subscription restricts to one physical server/hypervisor per account. I will look into the workbench, thanks. |
Which is great ...if you're developing on in-house hardware (or as @mrabe142 points out, on an exceedingly small dev footprint). If you're developing in AWS/Azure, choosing the RHUI-enabled Red Hat AMIs adds 40% to your hourly-compute costs vice using a CentOS AMI. This puts AWS/Azure tenants with two manin options:
Down side of the second option is potentially facing an IA group that says "your dev and prod systems used two different scan-profiles, we can't accept that" forcing them to make a decision of "raise my development system's hourly compute-costs by 40%" or "use CentOS end-to-end so that my scan-profiles are the same ...and, by the way, add that 40% hourly compute-cost savings to my test and prod environments". I know what direction the CIOs of many of my customers would lean. |
This is 100% about compliance and not money. Zero of RedHat certifications flow down to CentOS. Commons Criteria, FIPS, etc. Per CentOS https://wiki.centos.org/FAQ/General:
Federal laws, Executive Orders, directives, policies, regulations, and standards require FIPS-validated cryptography for systems that run on government networks or process government data. There are other directives, policies, regulations, and standards that require vendor-backed support (e.g. NIST 800-53, DISA SRGs, NIAP, etc) If CentOS wants to put forth the effort to go through and create NIST CCEs as well as NIAP and FIPS validation, we would be more than happy to point in the right direction of the process as well as creating the security profiles. |
|
All of that is fine, but it's still a cop-out to say "just use our free dev program". |
|
The "free dev program" doesn't really work when many government agencies are moving to the cloud for their computing needs.... |
Which now means that using a non-FIPS and government approved OS violates federal law. |
|
In that case, there are other options that are FIPS compliant and have a STIG (Ubuntu 16.04, for example), @redhatrises |
|
Windows, MacOS, AIX, zOS, Oracle, Ubuntu, SuSe, etc. are all FIPs compliant as well as others. Although not all are NIAP evaluated, certified, and/or recommended. |
|
Booooooooooooooooooo |
|
This is just yet another instance of a beurocrat injecting roadblocks into the work of people actually getting things done and holds communities back from having secure solutions "unless they pay" -- either by buying into it or by changing the operating system they're using to something more friendly with our corporate overlords. You are not our friends and are serving as one of many threats to infrastructure -- not because of a lack of government approvals -- but because you pulled a critical tool to hardening systems from users so that they would not confuse it for something that people pay money for. Tell us more about how you are a valuable contributor to the open source community. Make the damned profile available again and let the community keep it up to date, you vogons. :: throws a tomato :: |
|
@cmpunches |
Description of problem:
CentOS 7 has two different options (Data Stream and XCCDF files):
In SSG v0.1.41 and other previous versions, both contained a profile for running the RHEL 7 STIG as well as a number of other profiles:
Title: DISA STIG for Red Hat Enterprise Linux 7
Id: xccdf_org.ssgproject.content_profile_stig-rhel7-disa
This no longer appears to be the case, they only contain profiles for "pci-dss" and "standard".
Is there a reason this and the other profiles were removed in the latest release or is this a bug?
SCAP Security Guide Version:
0.1.42
Operating System Version:
CentOS 7.6
Steps to Reproduce:
Actual Results:
Scan errors out with profile not found. Confirmed with checking the info on the data stream file.
Expected Results:
Run the scan
The text was updated successfully, but these errors were encountered: