ComplianceAsCode / community

This repository is for management of all ComplianceAsCode community related initiatives.
Apache License 2.0
2 stars 0 forks source link

[DISA] RHEL-07-020100 remediation is incomplete #14

Closed jamescassell closed 4 years ago

jamescassell commented 6 years ago

Description of problem:

Per @shawndwells in #2722 :

The DISA content is incorrect. They've been notified about this several times.

blacklist will not prevent modules being loaded as dependencies. Using /bin/true or /bin/false will. That's documented at https://access.redhat.com/solutions/41278.

One path is creating a new rule that aligns to DISA. Some users do want exactly the DISA content -- right or wrong. Could add a warning note that DISA's content places DoD systems at risk and goes against configuration guidance for RHEL. Let users make their own risk decisions. Only enable that rule in the DISA profile.

Legitimizing the DISA rule is a concern though. By creating the new rule it demonstrates that it's OK for DISA to publish rules that DoD, NSA, NIST, the Vendor, and community at large, have told them places DoD systems at risk. People blindly follow DISA's content and these rules tend to live on for no other reason than "someone saw it in the DISA STIG." Would rather start to kill it off.

On the flip side, DISA's baseline is supposed to reflect "risk acceptance" for the included rules. DISA's understanding of blacklist vs /bin/{true false} is questionable, but it has been published. It's a trivial technical task to create new automation content that aligns to what DISA published.

@tbrunell: Do you know if DISA plans to update their content to DoD recommended settings? Is it worth creating a new rule now? One concern is version leap frogging... aka DISA drops the rule during the next update, but it lives on in SSG (or downstreams) for awhile.

SCAP Security Guide Version:

ssg version N/A DISA STIG RHEL7 V1R4

Operating System Version:

RHEL 7

Steps to Reproduce:

1. 2. 3. 4.

Actual Results:

STIG does not effectively disable usb storage

Expected Results:

Official STIG should effectively disable usb storage.

Addition Information/Debugging Steps:

I'm not familiar with the process of opening bugs with DISA, so I'm just putting this here so it's not forgotten about.

shawndwells commented 6 years ago

On 4/12/18 10:35 AM, James Cassell wrote:

I'm not familiar with the process of opening bugs with DISA, so I'm just putting this here so it's not forgotten about.

https://iase.disa.mil/help/Pages/index.aspx

Near the bottom you'll see text "If your problem is not listed above: Click here"

Should bring up an email form to reach them.

ajd394 commented 6 years ago

RHEL-07-020101 contains the "install xxxx /bin/true" instruction for dccp. Sounds like DISA just needs to be consistent.

linuxdan commented 6 years ago

@shawndwells @jamescassell Found the link on https://iase.disa.mil/help/Pages/index.aspx toward the bottom: STIG Questions

shawndwells commented 5 years ago

On 2/19/19 7:21 PM, James Cassell wrote:

I'm not familiar with the process of opening bugs with DISA, so I'm just putting this here so it's not forgotten about.

Can EMail them at disa.stig_spt@mail.mil

Or go to https://iase.disa.mil/help/Pages/index.aspx and click the "STIG Questions" near the bottom of the left-hand column.

Passionate differences of opinion about what should be in the content aside... they're good humans and have always been responsive.

-- Shawn Wells Chief Security Strategist North America Public Sector shawn@redhat.com | 443-534-0130

shawndwells commented 5 years ago

Hah. When moving the tickets, followers receive emails that make it look like these are new tickets.

jamescassell commented 5 years ago

DISA still has it wrong in V2R2 for usb-storage, but they get it correct for dccp.