search

ComplianceAsCode / content

Security automation content in SCAP, Bash, Ansible, and other formats
https://complianceascode.readthedocs.io/en/latest/
Other
2.22k stars 697 forks source link

STIG Profile Removed from CentOS 7 Data Stream #3743

Closed mrabe142 closed 5 years ago

mrabe142 commented 5 years ago

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:

  1. Install OpenSCAP + SSG
  2. Try to run a scan using STIG profile

Actual Results:

Scan errors out with profile not found. Confirmed with checking the info on the data stream file.

Expected Results:

Run the scan

shawndwells commented 5 years ago

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).

mrabe142 commented 5 years ago

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?

shawndwells commented 5 years ago

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.

mrabe142 commented 5 years ago

Never understood why such setups exist. RHEL is free for development,

It it a matter of scale. The development subscription restricts to one physical server/hypervisor per account.

I will look into the workbench, thanks.

ferricoxide commented 5 years ago

On 2/7/19 3:49 PM, shawndwells wrote: 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/

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:

  1. Pay 40% more per dev compute-hour – just so they can apply a pre-canned profile labeled 'STIG' and therefore be able to apply the same pre-canned profile name across their dev/test/prod release-process
  2. Say "screw that: 40% for dev systems is too high just to get a pre-canned profile labeled 'STIG'" and continue to opt for CentOS dev systems.

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.

redhatrises commented 5 years ago

On 2/7/19 3:49 PM, shawndwells wrote: 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/

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:

1. Pay 40% more per dev compute-hour – just so they can apply a pre-canned profile labeled 'STIG' and therefore be able to apply the same pre-canned profile name across their dev/test/prod release-process

2. Say "screw that: 40% for dev systems is too high just to get a pre-canned profile labeled 'STIG'" and continue to opt for CentOS dev systems.

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.

ferricoxide commented 5 years ago

All of that is fine, but it's still a cop-out to say "just use our free dev program".

compuguy commented 5 years ago

The "free dev program" doesn't really work when many government agencies are moving to the cloud for their computing needs....

redhatrises commented 5 years ago

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.

compuguy commented 5 years ago

In that case, there are other options that are FIPS compliant and have a STIG (Ubuntu 16.04, for example), @redhatrises

redhatrises commented 5 years ago

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.

zimmertr commented 4 years ago

Booooooooooooooooooo

cmpunches commented 2 years ago

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 ::

ggbecker commented 2 years ago

@cmpunches This discussion is more than 3 years old, many things have changed since then, including these political questionable decisions. As you can see here, right now we keep the same RHEL profiles in Centos 8 and 9. To make them available in Centos 7, shouldn't be that hard and the change will most likely get accepted. Feel free to create a pull request for that.