3:42 p.m.
Hi All,
After much delaying, we're hoping to start integrating our SIMP-specific
methods for meeting the various policy requirements directly into the SSG.
Unfortunately, this is providing to be a bit hairy and I'd like to know
what you would prefer.
## Option 1: Fork the Entire RHEL base into SIMP/{6,7} etc...
- We're not another OS, we're a specific (flexible) configuration set for
RHEL and/or CentOS
- I'd really like to avoid this
## Option 2: Muck about directly in the RHEL space
- This is my preference and I can 100% start with a set of profiles that
mirror the existing profiles. I guess this would be prefaced with 'simp'.
So, simp-C2S.xml, simp-pci-dss.xml, etc...
- We will also need to add alternate OVAL checks that are specific to SIMP.
For instance, per policy, our auditd file is optimized, this means that
none of the included checks will pass and we need alternate checks.
And no, in general, there is no way to determine if you're on a SIMP system
unless it's the Puppet Server. It's just RHEL.
Advice appreciated.
Thanks,
Trevor
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
3:59 p.m.
Sorry for the double post but I just realized that I forgot to ask about
the acceptance of SCE in the core SSG.
There are some things I just can't check without SCE such as:
* OpenLDAP configuration items
* Running IPTables Rules
* Running Auditd Rules
* Certs and settings in GnuTLS keystores
Thanks,
Trevor
On Mon, Oct 31, 2016 at 4:42 PM, Trevor Vaughan <tvaughan(a)onyxpoint.com>
wrote:
Hi All,
After much delaying, we're hoping to start integrating our SIMP-specific
methods for meeting the various policy requirements directly into the SSG.
Unfortunately, this is providing to be a bit hairy and I'd like to know
what you would prefer.
## Option 1: Fork the Entire RHEL base into SIMP/{6,7} etc...
- We're not another OS, we're a specific (flexible) configuration set for
RHEL and/or CentOS
- I'd really like to avoid this
## Option 2: Muck about directly in the RHEL space
- This is my preference and I can 100% start with a set of profiles that
mirror the existing profiles. I guess this would be prefaced with 'simp'.
So, simp-C2S.xml, simp-pci-dss.xml, etc...
- We will also need to add alternate OVAL checks that are specific to
SIMP. For instance, per policy, our auditd file is optimized, this means
that none of the included checks will pass and we need alternate checks.
And no, in general, there is no way to determine if you're on a SIMP
system unless it's the Puppet Server. It's just RHEL.
Advice appreciated.
Thanks,
Trevor
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
5:57 a.m.
----- Original Message -----
From: "Trevor Vaughan" <tvaughan(a)onyxpoint.com>
To: "SCAP Security Guide" <scap-security-guide(a)lists.fedorahosted.org>
Sent: Monday, October 31, 2016 4:42:51 PM
Subject: Integration Etiquitte
Hi All,
After much delaying, we're hoping to start integrating our SIMP-specific
methods for meeting the various policy requirements directly into the SSG.
Unfortunately, this is providing to be a bit hairy and I'd like to know
what you would prefer.
## Option 1: Fork the Entire RHEL base into SIMP/{6,7} etc...
- We're not another OS, we're a specific (flexible) configuration set for
RHEL and/or CentOS
- I'd really like to avoid this
## Option 2: Muck about directly in the RHEL space
- This is my preference and I can 100% start with a set of profiles that
mirror the existing profiles. I guess this would be prefaced with 'simp'.
So, simp-C2S.xml, simp-pci-dss.xml, etc...
- We will also need to add alternate OVAL checks that are specific to SIMP.
For instance, per policy, our auditd file is optimized, this means that
none of the included checks will pass and we need alternate checks.
And no, in general, there is no way to determine if you're on a SIMP system
unless it's the Puppet Server. It's just RHEL.
Could you please send an example of the differences between simp-pci-dss and
pci-dss profiles.
--
Martin Preisler
Identity Management and Platform Security | Red Hat, Inc.
1:04 p.m.
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.
Thanks,
Trevor
On Mon, Nov 7, 2016 at 6:57 AM, Martin Preisler <mpreisle(a)redhat.com> wrote:
----- Original Message -----
> From: "Trevor Vaughan" <tvaughan(a)onyxpoint.com>
> To: "SCAP Security Guide"
<scap-security-guide(a)lists.fedorahosted.org>
> Sent: Monday, October 31, 2016 4:42:51 PM
> Subject: Integration Etiquitte
>
> Hi All,
>
> After much delaying, we're hoping to start integrating our SIMP-specific
> methods for meeting the various policy requirements directly into the
SSG.
>
> Unfortunately, this is providing to be a bit hairy and I'd like to know
> what you would prefer.
>
> ## Option 1: Fork the Entire RHEL base into SIMP/{6,7} etc...
>
> - We're not another OS, we're a specific (flexible) configuration set for
> RHEL and/or CentOS
>
> - I'd really like to avoid this
>
> ## Option 2: Muck about directly in the RHEL space
>
> - This is my preference and I can 100% start with a set of profiles that
> mirror the existing profiles. I guess this would be prefaced with 'simp'.
> So, simp-C2S.xml, simp-pci-dss.xml, etc...
>
> - We will also need to add alternate OVAL checks that are specific to
SIMP.
> For instance, per policy, our auditd file is optimized, this means that
> none of the included checks will pass and we need alternate checks.
>
> And no, in general, there is no way to determine if you're on a SIMP
system
> unless it's the Puppet Server. It's just RHEL.
Could you please send an example of the differences between simp-pci-dss
and
pci-dss profiles.
--
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 --
3:46 a.m.
----- Original Message -----
From: "Trevor Vaughan" <tvaughan(a)onyxpoint.com>
To: "SCAP Security Guide" <scap-security-guide(a)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.
HTH!
--
Martin Preisler
Identity Management and Platform Security | Red Hat, Inc.
1:55 p.m.
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.
Thanks,
Trevor
On Mon, Nov 14, 2016 at 4:46 AM, Martin Preisler <mpreisle(a)redhat.com>
wrote:
----- Original Message -----
> From: "Trevor Vaughan" <tvaughan(a)onyxpoint.com>
> To: "SCAP Security Guide"
<scap-security-guide(a)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.
HTH!
--
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 --
2726
days inactive
2740
days old
scap-security-guide@lists.fedorahosted.org
5 comments
2 participants
participants (2)
-
Martin Preisler -
Trevor Vaughan