Hi Martin,

I was going to add it to the SSG stack, but it seemed....awkward since I'm going to also have to add a bunch of my oval checks scattered around.

We too are a compliance solution, but we're an operations focused compliance solution as opposed to a checkbox compliance solution. The two are not mutually exclusive but they don't always have the same base goals.

Additionally, compliance is compliance with the *documentation*, not the scanner. Where the scanner differs from the policy, the policy wins because it is, in fact, the policy.

The main issue is that we're going to have to have *different* OVAL checks since there is no method for actually differentiating between a SIMP system and a stock RHEL system. All we do is configure RHEL, we don't actually make something different.

Given all this, it does seem like the correct answer is to just dive in and start rolling 'simp_' things all over the place. We'll start light and see how it goes from there.



On Mon, Nov 14, 2016 at 4:46 AM, Martin Preisler <mpreisle@redhat.com> wrote:
----- Original Message -----
> From: "Trevor Vaughan" <tvaughan@onyxpoint.com>
> To: "SCAP Security Guide" <scap-security-guide@lists.fedorahosted.org>
> Sent: Friday, November 11, 2016 2:04:03 PM
> Subject: Re: Integration Etiquitte
> The simplest example of this is the OVAL checks for Auditd.
> As mentioned in the guides, you probably want to optimize your audit rules
> and so I did.
> The first optimization is that I drop -F auid!=4294967295 as one of the
> first things in my chain. This means that I don't need to actually worry
> about that causing load via any other rules.
> The same with auid>=500 (which may be 1000 in EL7, but it might not, we
> configure that system-wide).
> Finally, we dig out some of the more dangerous calls and segregate them
> away from the others (fork, vfork, etc...) so that your system doesn't die
> under load.
> Interestingly, what these rules do *not* check for is the presence of a
> rule at the top of the chain that just says "allow everything" and, of
> course, it doesn't check the running rules which may be heavily truncated
> unless you use the '-c' option to run auditd so that it continues to apply
> on an error.

To me it sounds like this could be added to the RHEL SSG product.

Although keep in mind that we are a compliance solution and optimizing
for performance or things like that are out of scope. We do want to pass
the rule if the user has optimized their chain though. So in this case
the changes to the OVAL can definitely be added to RHEL as long as it doesn't
start failing currently compliant systems.


Martin Preisler
Identity Management and Platform Security | Red Hat, Inc.
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org

Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

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