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
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@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 --
----- Original Message -----
From: "Trevor Vaughan" tvaughan@onyxpoint.com To: "SCAP Security Guide" scap-security-guide@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.
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@redhat.com wrote:
----- Original Message -----
From: "Trevor Vaughan" tvaughan@onyxpoint.com To: "SCAP Security Guide" scap-security-guide@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
----- 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.
HTH!
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@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.
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
scap-security-guide@lists.fedorahosted.org
-
Martin Preisler -
Trevor Vaughan