OSCAP module and DISA STIG compliance enforcement

[Samuel Vange]

Hello Everybody,

I'm not familiar with some of the tools used in SIMP, one of them being OpenSCAP. My question boils down to this:

How can I use the OpenSCAP puppet module rolled into SIMP to report on (and protentially enforce) compliance with the latest DISA RHEL 7 (draft) STIG?

I've figured out how to use the compliance map (simplib) to ensure that Puppet variables that are being used comply with DISA STIG standards, but this is not meant to be comprehensive. We have somebody manually STIGing our system, but it seems to me like he is not using the tools at his disposal. I can generate an oscap report, but the identifiers don't line up with identifiers in the DISA RHEL 7 STIG. I also see that there is an oscap scheduler; is this meant to be used to generate periodic reports? How about for automated remediation of problems?

I understand that a lot of this is specific to OpenSCAP, but I am also asking how the compliance reporting and remediation tools are meant to be used in a SIMP environment. Any response is appreciated.

[Trevor Vaughan]

Hi Samuel,

So, this is an interesting discussion and at the heart of what SIMP intends to solve.

First, SIMP very much *should* meet all of the STIG requirements (if with a few parameter tweaks) out of the box. If we're missing something, let us know. Also, the compliance map should be comprehensive in terms of parameters that affect the configuration of the system while the scans are there to validate that you meet the SCAP content that is available. We don't trust the fox to guard the henhouse!

However, the requirements are not the same as the scans. The scans have one view of the world and we have what we think is a more practical view of systems at scale as opposed to single system views.

The goal of the OpenSCAP module is, indeed, to run the scans on a periodic basis and get it output to /var/log/openscap on a weekly basis (by default).

The remediation should be handled via Puppet and/or SIMP where possible for consistent application across your systems.

To make this easier, we are working towards pushing SIMP-specific profiles into the upstream SSG content so that the scans will actually match what the system does. Time will tell if they get accepted.

To actually answer your question, you should be able to do the following via Hiera.

1) Add 'openscap::schedule' to the 'classes' Array

2) Set 'openscap::schedule::scap_profile : "xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream"

That should set you up with a weekly scan of your system which will be placed into /var/log/openscap.

Let us know if you have any trouble. Most organizations prefer to run a third party tool for their scans so we haven't had a lot of ground time with this module.

Available with SIMP Support, we have put together a processor for SCAP output that places it into Elasticsearch and some Grafana dashboards that allow for isolation and delving into the SCAP results across your hosts.

Thanks,

Trevor

--
You received this message because you are subscribed to the Google Groups "SIMP Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simp-users+unsubscribe@googlegroups.com.
To post to this group, send email to simp-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/simp-users/9234f136-b60d-4b69-a9da-1a18213a8f2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Trevor Vaughan
Vice President, Onyx Point, Inc

(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --

[Trevor Vaughan]

As an aside, I wanted to make sure that you know about the other half of the Security equation that SIMP provides via the CONOP and Control Mapping. Suggestions for making them better is always appreciated.

https://simp.readthedocs.io/en/master/security_conop/index.html

https://simp.readthedocs.io/en/master/security_mapping/index.html

Thanks,

Trevor

[Samuel Vange]

Thank you Trevor. We are using RHEL 7 which currently has a draft STIG. I really like what you guys are doing, but I'm having trouble convincing some of my team. The main concern right now is the following:

I've setup a SIMP 5.2.0-0 on RHEL 7.2 test environment using the disa-stig-el7 compliance profile.

Here are the highlights of the compliance report run on a baseline test system I have setup:

[root@puppet ~]# grep 'RHEL\-07' /var/lib/puppet/compliance_report.yaml |sort |uniq

              - RHEL-07-010000

              - RHEL-07-010130

              - RHEL-07-010140

              - RHEL-07-010160

              - RHEL-07-010250

              - RHEL-07-010370

              - RHEL-07-020230

              - RHEL-07-021060

              - RHEL-07-040030

              - RHEL-07-040540

[root@puppet ~]# grep 'RHEL\-07' /var/lib/puppet/compliance_report.yaml |sort |uniq |wc -l

10

It's clear here that only 10 STIG items with variables that are configured with non-compliant values.

I downloaded and complied the latest OpenSCAP Security Guide from github to get the latest rhel7 STIG xccdf file. The results (attached) show the following:

114 tests passed

103 tests failed

10 other

28 low severity failures

62 medium severity failures

13 high severity failures

I don't believe that the 103 failures will be addressed by the 10 items reported in the compliance report. Now, I understand that we're not only on the bleeding edge (targeting a draft STIG), and that the draft STIG is also a moving target. I'd like to know if SIMP is updating the disa-stig-el7 compliance profile to match the changing draft STIG and if so, how to update the compliance profile and the SIMP modules that contain the variables that it reports on.

Thank you,

Samuel Vange

[Trevor Vaughan]

Thanks Samuel!

At a quick glance some of these are in the STIG itself as "if you need this, turn it on, otherwise, turn it off" and we need it by default.

Quite a few others are not operationally viable and I think there are a host of false positives.

That said, there are some valid ones, such as the 'yum.conf' settings. In our case we actually don't have GPG checking on on the filesystem local repository but I suppose that we could add it without too much trouble.

Things like restricting root access from Serial consoles by default we'll probably need to argue on the SSG list about. That's the type of thing that is nice to say but is simply not operationally feasible in a LOT of places and, for a server, I would doubt that this is effective at all.

We'll get through these and either get bugs filed or get something written up and added to our core documentation.

Thanks,

Trevor

--
You received this message because you are subscribed to the Google Groups "SIMP Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simp-users+unsubscribe@googlegroups.com.
To post to this group, send email to simp-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/simp-users/2fef5d53-e4d9-48ed-964d-86bd427e29c3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Samuel Vange]

Trevor,

Thank you for all of your replies. A conversation has been started today within our group that might be of interest to you and/or the community. I've copied it here:

 

It looks like DISA pulled the draft version of the RHEL 7 STIG off of the iase.disa.mil site.  After doing some reading into the status of the RHEL 7 STIG,

I found this link (https://access.redhat.com/discussions/1295753). In short DISA, NSA, and Redhat are working on developing an official RHEL 7 STIG and the current status of the project can be found here:

(https://github.com/OpenSCAP/scap-security-guide/wiki/RHEL7-STIG-Project-Page).  Unfortunately, that original post was create in December of 2014.  In the developer's mailing group found in the second link, I found this post created in January 2015 by Shawn Wells (RedHat Chief Security Strategist) : 

---------------------------

There are now two RHEL7 STIGS:

- One issued by NSA and Red Hat, that ships in RHEL7. It was developed under the DISA FSO Vendor STIG process, and is aligned with NIST 800-53 and NIAP regimes. This edition is supported by Red Hat, and ships natively via the scap-security-guide package. This is also the STIG configuration that is exposed in the RHEL installer. Additionally, this RHEL7 STIG is the baseline of many DoD agencies such as NSA and Army. This was released back in March 2015.

 

- Last week, DISA FSO quietly released what they are calling the their own RHEL7 draft STIG. This version is entirely unknown to Red Hat, and DISA FSO did not make NSA, Red Hat, NIAP or NIST aware they were publishing this edition. It appears they took Red Hat provided content, and added several hundred unknown compliance checks to it. We're working with DISA FSO to see where this came from.

---------------------------

 

TLDR: There was some bureaucratic inefficiencies that surfaced in January regarding the RHEL 7 STIG and as of currently there isn't an official DISA STIG for RHEL 7 and there won't be one in the foreseeable future.

[Trevor Vaughan]

Hi Samuel,

Yeah, that's one of the reasons that we've sort of been putting off the full effort.

A lot of the checks that DISA put in are good, but they didn't follow the process and those checks may be WAY overboard for a lot of systems without adding any real security value.

We're keeping tabs on the subject and I'm in touch  with both Shawn Well and Jeff Blank so hopefully we'll align relatively quickly with the actual final approved publication.

That said, it is true that a lot of the items in the list are a good idea so we'll put them on the backlog for implementation.

Thanks!

Trevor

To view this discussion on the web visit https://groups.google.com/d/msgid/simp-users/91aad842-9a8f-4f4d-b0ae-d4ce08cf534c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Shawn Wells]

On 12/19/16 4:33 PM, Samuel Vange wrote:
> TLDR: There was some bureaucratic inefficiencies that surfaced in
> January regarding the RHEL 7 STIG and as of currently there isn't an
> official DISA STIG for RHEL 7 and there won't be one in the
> foreseeable future.

Bureaucratic inefficiencies is understatement of the year. See NSA's
take on the whole thing:

https://lists.fedorahosted.org/archives/list/scap-secu...@lists.fedorahosted.org/message/I3LDQSYRLK3HLYYHEDM52AYWOKZUXYDX/


On the positive side, was on the phone with DISA last week, and then
again today, trying to progress to a final edition of their content.

[Shawn Wells]

On 12/19/16 12:30 PM, Trevor Vaughan wrote:
>
> At a quick glance some of these are in the STIG itself as "if you need
> this, turn it on, otherwise, turn it off" and we need it by default.
>
> Quite a few others are not operationally viable and I think there are
> a host of false positives.
>
> That said, there are some valid ones, such as the 'yum.conf' settings.
> In our case we actually don't have GPG checking on on the filesystem
> local repository but I suppose that we could add it without too much
> trouble.
>
> Things like restricting root access from Serial consoles by default
> we'll probably need to argue on the SSG list about. That's the type of
> thing that is nice to say but is simply not operationally feasible in
> a LOT of places and, for a server, I would doubt that this is
> effective at all.
>
> We'll get through these and either get bugs filed or get something
> written up and added to our core documentation.

In the Red Hat review of the DISA content, we found about 600
issues/bugs between the multiple drafts. Keep in mind DISA only has 225
rules in their latest draft. The variance is because a single rule might
have improper check text, and improper remediation guidance, etc -- so
multiple bugs per DISA configuration item.

Currently having weekly calls with DISA to step them through -- line by
line -- of their content and fix things. Extremely interested in
coordinating my direct comments to DISA with those the SIMP community
have found.

[Trevor Vaughan]

Hey Shawn,

We'll try to provide feedback but some of our differences are due to needing to support EL6 and EL7 with the same codebase as well as some legacy capabilities that are valid, but not checked (passwdqc vs cracklib for example).

We'll try to keep this thread alive as a running list if possible.

Thanks,

Trevor

--
You received this message because you are subscribed to the Google Groups "SIMP Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simp-users+unsubscribe@googlegroups.com.
To post to this group, send email to simp-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/simp-users/33511f0f-1dcb-201e-3f07-b512de8b1761%40redhat.com.

For more options, visit https://groups.google.com/d/optout.

[Shawn Wells]

On 12/19/16 6:00 PM, Trevor Vaughan wrote:
> Hey Shawn,
>
> We'll try to provide feedback but some of our differences are due to
> needing to support EL6 and EL7 with the same codebase as well as some
> legacy capabilities that are valid, but not checked (passwdqc vs
> cracklib for example).
>
> We'll try to keep this thread alive as a running list if possible.

Within the OpenSCAP content, the intention is author XCCDF against the
"RHEL7 way" but have OVAL support legacy methods.

e.g. /etc/sysctl.conf and /etc/sysctl.d/*.conf:
https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/oval/sysctl_static_kernel_randomize_va_space.xml

Tickets welcome on areas where this isn't done (e.g. password checks
like you mentioned)

[Shawn Wells]

(sent to early)

In our conversations with DISA on the same topic, they intend only to
publish the "RHEL7 way"
(e.g. firewalld and not recognize iptables)