All,
As a starting point for writing remediation fixes in the SSG - so, I did the following:
$ ls ~/scap-security-guide/RHEL6/input/checks/*.xml | awk '{ print $1 }' | sed s/.[^.]*$// > ~/checks $ ls ~/scap-security-guide/RHEL6/input/fixes/*.sh | awk '{ print $1 }' | sed s/.[^.]*$// > ~/fixes $ sdiff ~/fixes ~/checks | less
There's fair a bit of work to be done for the fix remediations...
Since I'm new to the project, I was wondering if there was any ideas or standards to how the SSG should distribute some of these fixes - for example - a wholesale replacement of the audit.rules and auditd.conf might be preferable than doing piecemeal sed's. I also think the first script that needs to be run is to tar the current existing configurations (as a backup) before applying any fix just in case we do something that jacks the users modifications to the system.
Anyway, just trying to get an idea of how to proceed set some goals for my contributions.
Regards,
Frank Caviggia
On 10/3/13 3:11 PM, fcaviggi@redhat.com wrote:
All,
As a starting point for writing remediation fixes in the SSG - so, I did the following:
$ ls ~/scap-security-guide/RHEL6/input/checks/*.xml | awk '{ print$1 }' | sed s/.[^.]*$// > ~/checks $ ls ~/scap-security-guide/RHEL6/input/fixes/*.sh | awk '{ print $1 }' | sed s/.[^.]*$// > ~/fixes $ sdiff ~/fixes ~/checks | less
There's fair a bit of work to be done for the fix remediations...
Since I'm new to the project, I was wondering if there was any ideas or standards to how the SSG should distribute some of these fixes - for example - a wholesale replacement of the audit.rules and auditd.conf might be preferable than doing piecemeal sed's.
It'd be omgz easier to `cp /usr/share/doc/audit-*/stig.rules /etc/audit.rules`, and that likely is the right choice during an initial provisioning process. But then SysAdmins tailor audit rules, the system evolves, and we need to evaluate the audit.rules file against specific auditing guidance items after the pristine audit.rules template is manipulated.
So, if a single rule must be remediated, we can't blow away the whole audit.rules file. Super fun sed scripts it is =/
I also think the first script that needs to be run is to tar the current existing configurations (as a backup) before applying any fix just in case we do something that jacks the users modifications to the system.
A prevailing thought has been to address backups once the remediations are finished, as we'll have a better handle for which files will need addressing.
Forcing the backup (through XCCDF/OVAL) is tricky. One thought has been to create an OVAL check -- which is listed first in the profile -- which will *always* fail. The remediation for said OVAL would be to perform the backups. Anyone have a better idea? =/
Anyway, just trying to get an idea of how to proceed set some goals for my contributions.
These are /really/ good questions. Thanks for starting the conversation!
Is Augeas an option?
This seems like the perfect opportunity to solidify the Augeas lenses regarding security settings while making life easier for everyone.
Trevor
On Thu, Oct 3, 2013 at 9:42 PM, Shawn Wells shawn@redhat.com wrote:
On 10/3/13 3:11 PM, fcaviggi@redhat.com wrote:
All,
As a starting point for writing remediation fixes in the SSG - so, I did the following:
$ ls ~*/scap-security-guide/RHEL6/input/checks/**.xml | awk '{ print$1 }' | sed s/.[^.]*$// > ~/checks $ ls ~*/scap-security-guide/RHEL6/input/fixes/**.sh | awk '{ print $1 }' | sed s/.[^.]*$// > ~/fixes $ sdiff ~/fixes ~/checks | less
There's fair a bit of work to be done for the fix remediations...
Since I'm new to the project, I was wondering if there was any ideas or standards to how the SSG should distribute some of these fixes - for example - a wholesale replacement of the audit.rules and auditd.conf might be preferable than doing piecemeal sed's.
It'd be omgz easier to `cp /usr/share/doc/audit-*/stig.rules /etc/audit.rules`, and that likely is the right choice during an initial provisioning process. But then SysAdmins tailor audit rules, the system evolves, and we need to evaluate the audit.rules file against specific auditing guidance items after the pristine audit.rules template is manipulated.
So, if a single rule must be remediated, we can't blow away the whole audit.rules file. Super fun sed scripts it is =/
I also think the first script that needs to be run is to tar the current existing configurations (as a backup) before applying any fix just in case we do something that jacks the users modifications to the system.
A prevailing thought has been to address backups once the remediations are finished, as we'll have a better handle for which files will need addressing.
Forcing the backup (through XCCDF/OVAL) is tricky. One thought has been to create an OVAL check -- which is listed first in the profile -- which will *always* fail. The remediation for said OVAL would be to perform the backups. Anyone have a better idea? =/
Anyway, just trying to get an idea of how to proceed set some goals for my contributions.
These are *really* good questions. Thanks for starting the conversation!
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 10/04/2013 07:40 AM, Trevor Vaughan wrote:
Is Augeas an option?
This seems like the perfect opportunity to solidify the Augeas lenses regarding security settings while making life easier for everyone.
Trevor
On Thu, Oct 3, 2013 at 9:42 PM, Shawn Wells <shawn@redhat.com mailto:shawn@redhat.com> wrote:
On 10/3/13 3:11 PM, fcaviggi@redhat.com <mailto:fcaviggi@redhat.com> wrote:All, As a starting point for writing remediation fixes in the SSG - so, I did the following: $ ls ~//scap-security-guide/RHEL6/input/checks//*.xml | awk '{ print $1 }' | sed s/\.[^\.]*$// > ~/checks $ ls ~//scap-security-guide/RHEL6/input/fixes//*.sh | awk '{ print $1 }' | sed s/\.[^\.]*$// > ~/fixes $ sdiff ~/fixes ~/checks | less There's fair a bit of work to be done for the fix remediations... Since I'm new to the project, I was wondering if there was any ideas or standards to how the SSG should distribute some of these fixes - for example - a wholesale replacement of the audit.rules and auditd.conf might be preferable than doing piecemeal sed's.It'd be omgz easier to `cp /usr/share/doc/audit-*/stig.rules /etc/audit.rules`, and that likely is the right choice during an initial provisioning process. But then SysAdmins tailor audit rules, the system evolves, and we need to evaluate the audit.rules file against specific auditing guidance items after the pristine audit.rules template is manipulated. So, if a single rule must be remediated, we can't blow away the whole audit.rules file. Super fun sed scripts it is =/<snip>
I think that augeas is a good idea. We need to be careful that rules that are inserted in to audit.rules happen before any '-e 2' line (if one exists). Otherwise they will fail to be inserted because the audit rules become locked.
-josh
On 10/4/13 8:06 AM, Josh Kayse wrote:
On 10/04/2013 07:40 AM, Trevor Vaughan wrote:
Is Augeas an option?
This seems like the perfect opportunity to solidify the Augeas lenses regarding security settings while making life easier for everyone.
Trevor
On Thu, Oct 3, 2013 at 9:42 PM, Shawn Wells <shawn@redhat.com mailto:shawn@redhat.com> wrote:
On 10/3/13 3:11 PM, fcaviggi@redhat.com <mailto:fcaviggi@redhat.com> wrote:All, As a starting point for writing remediation fixes in the SSG - so, I did the following: $ ls ~//scap-security-guide/RHEL6/input/checks//*.xml | awk '{ print $1 }' | sed s/\.[^\.]*$// > ~/checks $ ls ~//scap-security-guide/RHEL6/input/fixes//*.sh | awk '{ print $1 }' | sed s/\.[^\.]*$// > ~/fixes $ sdiff ~/fixes ~/checks | less There's fair a bit of work to be done for the fix remediations... Since I'm new to the project, I was wondering if there was any ideas or standards to how the SSG should distribute some of these fixes - for example - a wholesale replacement of the audit.rules and auditd.conf might be preferable than doing piecemeal sed's.It'd be omgz easier to `cp /usr/share/doc/audit-*/stig.rules /etc/audit.rules`, and that likely is the right choice during an initial provisioning process. But then SysAdmins tailor audit rules, the system evolves, and we need to evaluate the audit.rules file against specific auditing guidance items after the pristine audit.rules template is manipulated. So, if a single rule must be remediated, we can't blow away the whole audit.rules file. Super fun sed scripts it is =/<snip>
I think that augeas is a good idea. We need to be careful that rules that are inserted in to audit.rules happen before any '-e 2' line (if one exists). Otherwise they will fail to be inserted because the audit rules become locked.
-josh
Augeas and puppet would be great, their downside is they don't ship natively with RHEL :( Part of the goal is to enable the remediation with native tooling first. IMO, Augeas scripts would be *fantastic* for Aqueduct!
Ok, so how do we make it happen?
Trevor
On Fri, Oct 4, 2013 at 11:05 PM, Shawn Wells shawn@redhat.com wrote:
On 10/4/13 8:06 AM, Josh Kayse wrote:
On 10/04/2013 07:40 AM, Trevor Vaughan wrote:
Is Augeas an option?
This seems like the perfect opportunity to solidify the Augeas lenses regarding security settings while making life easier for everyone.
Trevor
On Thu, Oct 3, 2013 at 9:42 PM, Shawn Wells <shawn@redhat.com mailto:shawn@redhat.com> wrote:
On 10/3/13 3:11 PM, fcaviggi@redhat.com <mailto:fcaviggi@redhat.com> wrote:All, As a starting point for writing remediation fixes in the SSG - so, I did the following: $ ls ~//scap-security-guide/RHEL6/**input/checks//*.xml | awk'{ print $1 }' | sed s/.[^.]*$// > ~/checks $ ls ~//scap-security-guide/RHEL6/**input/fixes//*.sh | awk '{ print $1 }' | sed s/.[^.]*$// > ~/fixes $ sdiff ~/fixes ~/checks | less
There's fair a bit of work to be done for the fix remediations... Since I'm new to the project, I was wondering if there was any ideas or standards to how the SSG should distribute some of these fixes - for example - a wholesale replacement of the audit.rules and auditd.conf might be preferable than doing piecemeal sed's.It'd be omgz easier to `cp /usr/share/doc/audit-*/stig.**rules /etc/audit.rules`, and that likely is the right choice during an initial provisioning process. But then SysAdmins tailor audit rules, the system evolves, and we need to evaluate the audit.rules file against specific auditing guidance items after the pristine audit.rules template is manipulated. So, if a single rule must be remediated, we can't blow away the whole audit.rules file. Super fun sed scripts it is =/<snip>
I think that augeas is a good idea. We need to be careful that rules that are inserted in to audit.rules happen before any '-e 2' line (if one exists). Otherwise they will fail to be inserted because the audit rules become locked.
-josh
Augeas and puppet would be great, their downside is they don't ship natively with RHEL :( Part of the goal is to enable the remediation with native tooling first. IMO, Augeas scripts would be *fantastic* for Aqueduct!
______________________________**_________________ scap-security-guide mailing list scap-security-guide@lists.**fedorahosted.orgscap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.**org/mailman/listinfo/scap-**security-guidehttps://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/05/2013 07:26 PM, Trevor Vaughan wrote:
Ok, so how do we make it happen?
Trevor
Also addition of rules, I have like 10-20 product specific rules I'd like to add (and release publicly), it;s on my todo list for a few months now, haven't had time to do it since there is no quick/easy way to do it =(.Being able to take an existing rule and modify it would handle about half of what I want, so yeah, +1 =).
- -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
On Friday, October 04, 2013 11:05:24 PM Shawn Wells wrote:
Augeas and puppet would be great, their downside is they don't ship natively with RHEL Part of the goal is to enable the remediation with native tooling first.
Right. I'd also like to highlight the openscap integration with Anaconda which is coming in RHEL7. The intention is that from anaconda you'll be able to select the security policy and in the post install phase it will remediate the system so that its in configuration from the first install.
-Steve
On Thu, 2013-10-17 at 14:39 -0400, Steve Grubb wrote:
On Friday, October 04, 2013 11:05:24 PM Shawn Wells wrote:
Augeas and puppet would be great, their downside is they don't ship natively with RHEL Part of the goal is to enable the remediation with native tooling first.
Right. I'd also like to highlight the openscap integration with Anaconda which is coming in RHEL7. The intention is that from anaconda you'll be able to select the security policy and in the post install phase it will remediate the system so that its in configuration from the first install.
The openscap integration Anaconda addon [1] is now being packaged [2] for the Fedora distribution. Once there is a package, composes can be made by lorax (the tool creating installation DVDs, etc.) for testing purposes or as some sort of a Fedora spin.
But however the code may be ready, we don't have any content. And I'm afraid the same applies to RHEL7 where we could provide a way for testing, we could even make the addon available by default, but without any content it would be useless.
[1] https://fedorahosted.org/oscap-anaconda-addon [2] https://bugzilla.redhat.com/show_bug.cgi?id=1021485
On 10/22/13, 10:17 AM, Vratislav Podzimek wrote:
On Thu, 2013-10-17 at 14:39 -0400, Steve Grubb wrote:
On Friday, October 04, 2013 11:05:24 PM Shawn Wells wrote:
Augeas and puppet would be great, their downside is they don't ship natively with RHEL Part of the goal is to enable the remediation with native tooling first.
Right. I'd also like to highlight the openscap integration with Anaconda which is coming in RHEL7. The intention is that from anaconda you'll be able to select the security policy and in the post install phase it will remediate the system so that its in configuration from the first install.
The openscap integration Anaconda addon [1] is now being packaged [2] for the Fedora distribution. Once there is a package, composes can be made by lorax (the tool creating installation DVDs, etc.) for testing purposes or as some sort of a Fedora spin.
But however the code may be ready, we don't have any content. And I'm afraid the same applies to RHEL7 where we could provide a way for testing, we could even make the addon available by default, but without any content it would be useless.
[1]https://fedorahosted.org/oscap-anaconda-addon [2]https://bugzilla.redhat.com/show_bug.cgi?id=1021485
Fedora 20 alpha packages @ http://koji.fedoraproject.org/koji/buildinfo?buildID=472985
F19/20 and EPEL6 packages should hit soon (matter of days). Through Jan's mentoring, we were able to run a test EPEL-6 build earlier today: http://koji.fedoraproject.org/koji/buildinfo?buildID=473841
In regards to RHEL7... we're only waiting for _public_ alpha & beta at this point (so the community can start generating content). Needless to say, there WILL be content -- this feature is one of the most talked about within RH Public Sector. Many, many customers and community members are drooling at the mouth for your SCAP/Anaconda integration to hit RHEL!
Personally, I'm massively opposed to '-e 2'.
I really like the ability to audit new things as I add them without rebooting my systems.
Trevor
On Fri, Oct 4, 2013 at 8:06 AM, Josh Kayse Joshua.Kayse@gtri.gatech.eduwrote:
On 10/04/2013 07:40 AM, Trevor Vaughan wrote:
Is Augeas an option?
This seems like the perfect opportunity to solidify the Augeas lenses regarding security settings while making life easier for everyone.
Trevor
On Thu, Oct 3, 2013 at 9:42 PM, Shawn Wells <shawn@redhat.com mailto:shawn@redhat.com> wrote:
On 10/3/13 3:11 PM, fcaviggi@redhat.com <mailto:fcaviggi@redhat.com> wrote:All, As a starting point for writing remediation fixes in the SSG - so, I did the following: $ ls ~//scap-security-guide/RHEL6/**input/checks//*.xml | awk '{ print $1 }' | sed s/\.[^\.]*$// > ~/checks $ ls ~//scap-security-guide/RHEL6/**input/fixes//*.sh | awk '{ print $1 }' | sed s/\.[^\.]*$// > ~/fixes $ sdiff ~/fixes ~/checks | less There's fair a bit of work to be done for the fix remediations... Since I'm new to the project, I was wondering if there was any ideas or standards to how the SSG should distribute some of these fixes - for example - a wholesale replacement of the audit.rules and auditd.conf might be preferable than doing piecemeal sed's.It'd be omgz easier to `cp /usr/share/doc/audit-*/stig.**rules /etc/audit.rules`, and that likely is the right choice during an initial provisioning process. But then SysAdmins tailor audit rules, the system evolves, and we need to evaluate the audit.rules file against specific auditing guidance items after the pristine audit.rules template is manipulated. So, if a single rule must be remediated, we can't blow away the whole audit.rules file. Super fun sed scripts it is =/<snip>
I think that augeas is a good idea. We need to be careful that rules that are inserted in to audit.rules happen before any '-e 2' line (if one exists). Otherwise they will fail to be inserted because the audit rules become locked.
-josh
-- 404.407.6630
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Trevor,
The -e 2 setting ensures that the audit rules are immutable until the next reboot. It ensures the configuration can't be changed by doing someone doing something nefarious to the system.
Regards,
Frank
On 10/05/2013 09:27 PM, Trevor Vaughan wrote:
Personally, I'm massively opposed to '-e 2'.
I really like the ability to audit new things as I add them without rebooting my systems.
Trevor
On Fri, Oct 4, 2013 at 8:06 AM, Josh Kayse <Joshua.Kayse@gtri.gatech.edu mailto:Joshua.Kayse@gtri.gatech.edu> wrote:
On 10/04/2013 07:40 AM, Trevor Vaughan wrote: Is Augeas an option? This seems like the perfect opportunity to solidify the Augeas lenses regarding security settings while making life easier for everyone. Trevor On Thu, Oct 3, 2013 at 9:42 PM, Shawn Wells <shawn@redhat.com <mailto:shawn@redhat.com> <mailto:shawn@redhat.com <mailto:shawn@redhat.com>>> wrote: On 10/3/13 3:11 PM, fcaviggi@redhat.com <mailto:fcaviggi@redhat.com> <mailto:fcaviggi@redhat.com <mailto:fcaviggi@redhat.com>> wrote: All, As a starting point for writing remediation fixes in the SSG - so, I did the following: $ ls ~//scap-security-guide/RHEL6/input/checks//*.xml | awk '{ print $1 }' | sed s/\.[^\.]*$// > ~/checks $ ls ~//scap-security-guide/RHEL6/input/fixes//*.sh | awk '{ print $1 }' | sed s/\.[^\.]*$// > ~/fixes $ sdiff ~/fixes ~/checks | less There's fair a bit of work to be done for the fix remediations... Since I'm new to the project, I was wondering if there was any ideas or standards to how the SSG should distribute some of these fixes - for example - a wholesale replacement of the audit.rules and auditd.conf might be preferable than doing piecemeal sed's. It'd be omgz easier to `cp /usr/share/doc/audit-*/stig.rules /etc/audit.rules`, and that likely is the right choice during an initial provisioning process. But then SysAdmins tailor audit rules, the system evolves, and we need to evaluate the audit.rules file against specific auditing guidance items after the pristine audit.rules template is manipulated. So, if a single rule must be remediated, we can't blow away the whole audit.rules file. Super fun sed scripts it is =/ <snip> I think that augeas is a good idea. We need to be careful that rules that are inserted in to audit.rules happen before any '-e 2' line (if one exists). Otherwise they will fail to be inserted because the audit rules become locked. -josh -- 404.407.6630 <tel:404.407.6630> _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com mailto:tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Yeah, I know.
But I like to change my audit rules when I add new services/items that need to be audited.
Anywhere that's actually paying you money to keep their servers up isn't going to be thrilled with you rebooting them....ever.
If you're actually auditing your audit rules and offloading your logs, you'll see someone changing them and thus can react to the change.
-e 2 makes your system *less* secure in many SLA settings (since you can't actually audit as much as you should be given system changes) and should be in the realm of 'ideal'.
Trevor
On Sat, Oct 5, 2013 at 11:33 PM, fcaviggi@redhat.com wrote:
Trevor,
The -e 2 setting ensures that the audit rules are immutable until the next reboot. It ensures the configuration can't be changed by doing someone doing something nefarious to the system.
Regards,
Frank
On 10/05/2013 09:27 PM, Trevor Vaughan wrote:
Personally, I'm massively opposed to '-e 2'.
I really like the ability to audit new things as I add them without rebooting my systems.
Trevor
On Fri, Oct 4, 2013 at 8:06 AM, Josh Kayse Joshua.Kayse@gtri.gatech.eduwrote:
On 10/04/2013 07:40 AM, Trevor Vaughan wrote:
Is Augeas an option?
This seems like the perfect opportunity to solidify the Augeas lenses regarding security settings while making life easier for everyone.
Trevor
On Thu, Oct 3, 2013 at 9:42 PM, Shawn Wells <shawn@redhat.com mailto:shawn@redhat.com> wrote:
On 10/3/13 3:11 PM, fcaviggi@redhat.com <mailto:fcaviggi@redhat.com> wrote:All, As a starting point for writing remediation fixes in the SSG - so, I did the following: $ ls ~//scap-security-guide/RHEL6/input/checks//*.xml | awk '{ print $1 }' | sed s/\.[^\.]*$// > ~/checks $ ls ~//scap-security-guide/RHEL6/input/fixes//*.sh | awk '{ print $1 }' | sed s/\.[^\.]*$// > ~/fixes $ sdiff ~/fixes ~/checks | less There's fair a bit of work to be done for the fix remediations... Since I'm new to the project, I was wondering if there was any ideas or standards to how the SSG should distribute some of these fixes - for example - a wholesale replacement of the audit.rules and auditd.conf might be preferable than doing piecemeal sed's.It'd be omgz easier to `cp /usr/share/doc/audit-*/stig.rules /etc/audit.rules`, and that likely is the right choice during an initial provisioning process. But then SysAdmins tailor audit rules, the system evolves, and we need to evaluate the audit.rules file against specific auditing guidance items after the pristine audit.rules template is manipulated. So, if a single rule must be remediated, we can't blow away the whole audit.rules file. Super fun sed scripts it is =/<snip>
I think that augeas is a good idea. We need to be careful that rules that are inserted in to audit.rules happen before any '-e 2' line (if one exists). Otherwise they will fail to be inserted because the audit rules become locked.
-josh
-- 404.407.6630
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing listscap-security-guide@lists.fedorahosted.orghttps://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Frank Caviggia Consultant, Public Sectorfcaviggi@redhat.com (M) (571) 295-4560
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Putting my cloud hat on:
You shouldn't build reliable servers.
You should build reliable services.
Mind. blown. let that sink it. ;)
- -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Heh, pass your cloud hat to my customers and I'll buy you lunch.
Until then.....
On Sun, Oct 6, 2013 at 12:29 AM, Kurt Seifried kseifried@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Putting my cloud hat on:
You shouldn't build reliable servers.
You should build reliable services.
Mind. blown. let that sink it. ;)
Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAEBAgAGBQJSUOcUAAoJEBYNRVNeJnmTdWwP/1RvWsDS/LWJhOy2ZS5yNDyp O7IFBQVHkvFNBuXEh9UBiVLaEFPIdG2ezbnzamF/hLtvzFFWmw51UQNAW1NEtrG/ 0GzO7eKoAM/W+ig5uZXQu+FVgQVuZJsh/lCDjMknSeAWEjc4WJU4dcJDaNkQi4iE QGapldcCdq8y3HlY3pGdYjXJ+DezNufw5NPqSZGJlmjs6QSGDpu5o6Ve6j4SWYl3 A4YsGsEjwGjeUb9mUKQn2yoxwbFx3sOat6ploA1yly/0teOwDwh+ayJQ0fIT5usW REbnIoMoXIvmlC4YlIRQb99pZU1M0YYYtXR05azDURfmeUZPjriaSiI7CDSWJpBN yXQiXoTiRkO04uBjgaDQtfUqiZewP3WKrrj3tmsO6wa9mjXxW11mP38KR7PqqVI8 eKnzXP1QoJKNrTIlza5cbFgFw10wOZLDWDA5DckFY8Lgd5WxHaHbotXr2SenHwJk w7kNQH6CQlgB0cP6irU+RUNRjD9eWcKfjay8kspYeJbMY2hDuzfFrgeoreGFyHGI SG7TxaG68sy3C8knRSkaWz/UigFsXSHQPi5ZWi/rbK1EUXGUOylRXUm1yXmlxJxs 2GVungRGku54yEgS+4xiQ3x5I5XJxt7APl4+8bqrgqBZvPuoQGJuY1PClNLkCC4v DwSvawFa/Xw6y/kd8N4i =uZx5 -----END PGP SIGNATURE-----
* I didn't want to highjack the other 'Checks vs. Fixes' thread so I'm spinning off on to another one.
I have spent a lot of time thinking about just this type of thing. Currently the conversation is on auditing rules, but I think the topic applies in multiple areas with regards to automated remediation. From what I have seen there are two main ways that SSG is used:
1) Fully SSG compliant machine (or as close as possible) for policy reasons from above (DoD mandates STIG compliance, the customer says so, etc) 2) Mostly SSG compliant machine because we all want to be secure, but we are willing to forgo certain aspects out of necessity or convenience.
Regardless of which side of this you are on, everyone wants a tool that makes this process as easy as possible for them. Unfortunately, this is hard. If we can contain each remediation step into it's own little environment I think it's possible to make both sides mostly happy.
To make that tougher, you can't ever assume what state a machine is in when the SSG is run against it. It could be a brand new build with completely stock files or it could be a machine that has been in production for years and has various changes (compliant or not) that can't be changed wholesale. And then to make it even worse, we can't all use the same tools (like Puppet and Augeas or even perl) which could potentially make the job easier. There was some talk about later versions having extra capabilities when possible, but for now it's keeping everything as generic as possible.
I think it comes down to requirements. Obviously I don't make these decisions, but from the conversations I have seen and IMO they include something along the lines of:
1) Must use RHEL delivered tools only and sticking to the most common tools -- A conversation went on earlier this year where bash was chosen as almost every machine has it. I believe there was talk of later versions supporting other tools though.
2) Each remediation step should take care of all things needed to make that finding compliant, but should NOT change the way another finding is handled -- To use audit as an example: Which finding would do the wholesale replace of the audit.rules file? -- What happens if that finding is already satisfied and the file isn't replaced and all other audit.rules findings are still open? -- Or if you replace it wholesale with every audit finding then you are doing duplicate work and potentially blowing away valid, non-SSG enforced changes. Just because I have one line wrong doesn't mean I want every line to be right.
3) No remediation change should be dependent on another remediation change -- Similar to #2, but rather than step A breaking step B, step B should not rely on step A in order for step B to be compliant
I am sure there are others that I am not thinking of right now, but I hope I got the point across. If these can be pretty clearly defined I think a lot of the questions I see on this list could be answered by stepping through this list. It's not always the easy way, but I would argue it's the RIGHT way. And if someone wants to skip a remediation step (-e 2, for example) everything else should apply as needed and then the user can go on their merry way. It would be a lot of Regex terribleness, but I think it would be the most portable from system to system and site to site.
Does that sound reasonable?
* I wish I could think of a good 'Do it right the first time' quote...
- Chad
On 10/8/13 9:47 AM, Truhn, Chad M CTR NSWCDD, CXA30 wrote:
- I didn't want to highjack the other 'Checks vs. Fixes' thread so I'm
spinning off on to another one.
I have spent a lot of time thinking about just this type of thing. Currently the conversation is on auditing rules, but I think the topic applies in multiple areas with regards to automated remediation. From what I have seen there are two main ways that SSG is used:
- Fully SSG compliant machine (or as close as possible) for policy
reasons from above (DoD mandates STIG compliance, the customer says so, etc) 2) Mostly SSG compliant machine because we all want to be secure, but we are willing to forgo certain aspects out of necessity or convenience.
Regardless of which side of this you are on, everyone wants a tool that makes this process as easy as possible for them. Unfortunately, this is hard. If we can contain each remediation step into it's own little environment I think it's possible to make both sides mostly happy.
To make that tougher, you can't ever assume what state a machine is in when the SSG is run against it. It could be a brand new build with completely stock files or it could be a machine that has been in production for years and has various changes (compliant or not) that can't be changed wholesale. And then to make it even worse, we can't all use the same tools (like Puppet and Augeas or even perl) which could potentially make the job easier. There was some talk about later versions having extra capabilities when possible, but for now it's keeping everything as generic as possible.
I think it comes down to requirements. Obviously I don't make these decisions, but from the conversations I have seen and IMO they include something along the lines of:
- Must use RHEL delivered tools only and sticking to the most common
tools -- A conversation went on earlier this year where bash was chosen as almost every machine has it. I believe there was talk of later versions supporting other tools though.
- Each remediation step should take care of all things needed to make
that finding compliant, but should NOT change the way another finding is handled -- To use audit as an example: Which finding would do the wholesale replace of the audit.rules file? -- What happens if that finding is already satisfied and the file isn't replaced and all other audit.rules findings are still open? -- Or if you replace it wholesale with every audit finding then you are doing duplicate work and potentially blowing away valid, non-SSG enforced changes. Just because I have one line wrong doesn't mean I want every line to be right.
- No remediation change should be dependent on another remediation
change -- Similar to #2, but rather than step A breaking step B, step B should not rely on step A in order for step B to be compliant
I am sure there are others that I am not thinking of right now, but I hope I got the point across. If these can be pretty clearly defined I think a lot of the questions I see on this list could be answered by stepping through this list. It's not always the easy way, but I would argue it's the RIGHT way. And if someone wants to skip a remediation step (-e 2, for example) everything else should apply as needed and then the user can go on their merry way. It would be a lot of Regex terribleness, but I think it would be the most portable from system to system and site to site.
Does that sound reasonable?
- I wish I could think of a good 'Do it right the first time' quote...
wanted to quickly acknowledge the thread -- many of the govvies have been off and are just getting unburied. Jeff or myself will respond shortly to this, but you've hit the nail on many of these topics!
Hey Shawn,
I was thinking this trough last night - I was wondering if we can use checksums (sha256+) to determine if someone is using the "stock" configuration and replace it with a fully STIGed version - I'm thinking this would be best applicable to new installations of RHEL. I understand the need for atomic fixes for pre-existing systems, where the SA has modified the defaults, but I can guarantee you that most people just want a STIG'ed box out of the gate on install. I'm just trying to think in terms of long term and short term goals - the quicker we can satisfy the majority of the users (the ones that want something STIG'ed out of the box) the better acceptance the product will have, the long term should be to modify things for the people that mucked with their configurations, which I'm arguing is a minority.
I go back to Star Trek II: Wrath of Khan with Spock, "It is logical. The needs of the many outweighhttp://www.imdb.com/name/nm0000638/?ref_=tt_trv_qu...the needs of the fewhttp://www.imdb.com/name/nm0000559/?ref_=tt_trv_qu...or the one." We need to get the ship out of danger, and then worry about the needs of the few.
What do you think of my solution?
-Frank
On 10/03/2013 09:42 PM, Shawn Wells wrote:
On 10/3/13 3:11 PM, fcaviggi@redhat.com wrote:
All,
As a starting point for writing remediation fixes in the SSG - so, I did the following:
$ ls ~/scap-security-guide/RHEL6/input/checks/*.xml | awk '{print $1 }' | sed s/.[^.]*$// > ~/checks $ ls ~/scap-security-guide/RHEL6/input/fixes/*.sh | awk '{ print $1 }' | sed s/.[^.]*$// > ~/fixes $ sdiff ~/fixes ~/checks | less
There's fair a bit of work to be done for the fix remediations...
Since I'm new to the project, I was wondering if there was any ideas or standards to how the SSG should distribute some of these fixes - for example - a wholesale replacement of the audit.rules and auditd.conf might be preferable than doing piecemeal sed's.
It'd be omgz easier to `cp /usr/share/doc/audit-*/stig.rules /etc/audit.rules`, and that likely is the right choice during an initial provisioning process. But then SysAdmins tailor audit rules, the system evolves, and we need to evaluate the audit.rules file against specific auditing guidance items after the pristine audit.rules template is manipulated.
So, if a single rule must be remediated, we can't blow away the whole audit.rules file. Super fun sed scripts it is =/
I also think the first script that needs to be run is to tar the current existing configurations (as a backup) before applying any fix just in case we do something that jacks the users modifications to the system.
A prevailing thought has been to address backups once the remediations are finished, as we'll have a better handle for which files will need addressing.
Forcing the backup (through XCCDF/OVAL) is tricky. One thought has been to create an OVAL check -- which is listed first in the profile -- which will *always* fail. The remediation for said OVAL would be to perform the backups. Anyone have a better idea? =/
Anyway, just trying to get an idea of how to proceed set some goals for my contributions.
These are /really/ good questions. Thanks for starting the conversation!
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 10/4/13 8:50 AM, fcaviggi@redhat.com wrote:
I was thinking this trough last night - I was wondering if we can use checksums (sha256+) to determine if someone is using the "stock" configuration and replace it with a fully STIGed version - I'm thinking this would be best applicable to new installations of RHEL. I understand the need for atomic fixes for pre-existing systems, where the SA has modified the defaults, but I can guarantee you that most people just want a STIG'ed box out of the gate on install. I'm just trying to think in terms of long term and short term goals - the quicker we can satisfy the majority of the users (the ones that want something STIG'ed out of the box) the better acceptance the product will have, the long term should be to modify things for the people that mucked with their configurations, which I'm arguing is a minority.
I go back to Star Trek II: Wrath of Khan with Spock, "It is logical. The needs of the many outweighhttp://www.imdb.com/name/nm0000638/?ref_=tt_trv_qu...the needs of the fewhttp://www.imdb.com/name/nm0000559/?ref_=tt_trv_qu...or the one." We need to get the ship out of danger, and then worry about the needs of the few.
What do you think of my solution?
Something like this?
if rpm -V audit cp /usr/share/doc/audit-*/stig.rules /etc/audit.rules else if audit rule misconfigured sed fix else echo audit_rule >> /etc/audit.rules fi fi
I'm not particularly opposed. We'll want to ensure that the /usr/share/doc/audit-*/stig.rules file meets the STIG/SSG needs (and if not, submit RFEs). It'd be great if we could template these somehow.
On Fri, 04 Oct 2013 08:50:23 -0400 fcaviggi@redhat.com wrote:
I was thinking this trough last night - I was wondering if we can use checksums (sha256+) to determine if someone is using the "stock" configuration and replace it with a fully STIGed version - I'm thinking this would be best applicable to new installations of RHEL. I understand the need for atomic fixes for pre-existing systems, where the SA has modified the defaults, but I can guarantee you that most people just want a STIG'ed box out of the gate on install. I'm just trying to think in terms of long term and short term goals - the quicker we can satisfy the majority of the users (the ones that want something STIG'ed out of the box) the better acceptance the product will have, the long term should be to modify things for the people that mucked with their configurations, which I'm arguing is a minority.
Well, not really. I've set up ssg for several clients and not a single one wants to use it as is, they have all different requirements. Some need a different banner, some different password parameters, some different ssh, etc. All I'm saying is my experience is that most want to modify.
+1
EVERYONE wants to modify at least one rule. It needs to be easy to do so and run your own checks else people will just start writing other tools.
Trevor
On Sat, Oct 5, 2013 at 7:57 AM, Brian Millett bmillett@gmail.com wrote:
On Fri, 04 Oct 2013 08:50:23 -0400 fcaviggi@redhat.com wrote:
I was thinking this trough last night - I was wondering if we can use checksums (sha256+) to determine if someone is using the "stock" configuration and replace it with a fully STIGed version - I'm thinking
this
would be best applicable to new installations of RHEL. I understand the
need
for atomic fixes for pre-existing systems, where the SA has modified the defaults, but I can guarantee you that most people just want a STIG'ed
box
out of the gate on install. I'm just trying to think in terms of long
term
and short term goals - the quicker we can satisfy the majority of the
users
(the ones that want something STIG'ed out of the box) the better
acceptance
the product will have, the long term should be to modify things for the people that mucked with their configurations, which I'm arguing is a minority.
Well, not really. I've set up ssg for several clients and not a single one wants to use it as is, they have all different requirements. Some need a different banner, some different password parameters, some different ssh, etc. All I'm saying is my experience is that most want to modify.
-- Brian Millett "The guerrillas, whose ancestors migrated to Mars from Earth over the past hundred years, have demanded independence for the Mars Colony or, and I quote, 'The sand will run red with Earther blood.'" -- [ Derek Mobotabwe, ISN News, "A Voice in the Wilderness I"] _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide@lists.fedorahosted.org
-
Brian Millett -
Frank Caviggia -
Kayse, Josh -
Kurt Seifried -
Shawn Wells -
Steve Grubb -
Trevor Vaughan -
Truhn, Chad M CTR NSWCDD, CXA30 -
Vratislav Podzimek