On Sat, 1 Jun 2013 17:20:12 -0400 Shawn Wells shawn.d.wells@gmail.com wrote:
Well, for me ACK.
The hardest part of maintaining a bunch of remediation scrips is to make sure that the "fix" is consistant with the "check". I've spent much time remediating my remediation.
I like it.
Yes, but please hold off on remediation content until the OVAL validates per the schematron, and there is a means of handling parameters/variables in fix content. If you don't eat your meat, you can't have any pudding. But we should be able to have both.
Subscribers will note that while they got their STIG, there is no automated checking content for it. But it is very close.
Please see the output from "make validate" for schematron validation problems.
Also, how many have run the automated scans per: https://fedorahosted.org/scap-security-guide/wiki/usageguide
Do the OVAL checks which are executed here work? Would you like to see these in an automated STIG, as-is? Or would some QA first be nice?
On Sat, Jun 1, 2013 at 6:14 PM, Brian Millett bmillett@gmail.com wrote:
On Sat, 1 Jun 2013 17:20:12 -0400 Shawn Wells shawn.d.wells@gmail.com wrote:
Well, for me ACK.
The hardest part of maintaining a bunch of remediation scrips is to make sure that the "fix" is consistant with the "check". I've spent much time remediating my remediation.
I like it.
-- Brian Millett "Orin Zento has powerful friends. By embarrassing him, you embarrassed them. Today, you have made new enemies. If I were you, Commander, I would watch things very carefully. You are not the most popular person in government circles right now." 'So what else is new?' -- [ Senator Hidoshi and Sinclair, "By Any Means Necessary"] _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 6/1/13 6:52 PM, Jeffrey Blank wrote:
Yes, but please hold off on remediation content until the OVAL validates per the schematron, and there is a means of handling parameters/variables in fix content. If you don't eat your meat, you can't have any pudding. But we should be able to have both.
The value of working sequentially doesn't make sense for such such a parallel development effort, with members of different skill levels contributing.
For example: I've no idea how to fix the remaining OVAL issues, so you're telling me and all other would-be contributors to completely stop helping for awhile? What value does that add?
It is not so simple.
This is a strategy problem. If there is only one contributor who is capable of fixing OVAL problems, then there should be serious viability concerns about the project. The addition of remediation content, which would logically depend on this checking content, would only compound the problem. I am seeking evidence of community motivation and capability to address the OVAL problems before we move on to any remediation efforts.
There was significant irony in observations about how checking content (from Aqueduct, for example) is better than the checking content actually used by system auditors (who may be leveraging OVAL content issued by DISA), yet there seems to be so much interest in producing remediation content. DISA is waiting on our OVAL content to be fully baked so that they can issue it. How much testing of the OVAL content as described at https://fedorahosted.org/scap-security-guide/wiki/usageguide has been carried out? Does it work? Is it suitable to base remediation content on?
Another interesting note is that in fact tooling support from OpenSCAP for remediation scripts was further ahead than I thought: https://www.redhat.com/archives/open-scap-list/2013-June/msg00001.html (I again tip my hat to Simon and Peter and the other OpenSCAP devs.)
This means that, from a tooling perspective, the ability to automatically generate parameterized remediation scripts is already there (and my next post should put us yet closer to being able to work remediation). But still: if the checks aren't any good, then nobody should trust the remediation scripts generated.
On Sat, Jun 1, 2013 at 6:58 PM, Shawn Wells shawn@redhat.com wrote:
On 6/1/13 6:52 PM, Jeffrey Blank wrote:
Yes, but please hold off on remediation content until the OVAL validates per the schematron, and there is a means of handling parameters/variables in fix content. If you don't eat your meat, you can't have any pudding. But we should be able to have both.
The value of working sequentially doesn't make sense for such such a parallel development effort, with members of different skill levels contributing.
For example: I've no idea how to fix the remaining OVAL issues, so you're telling me and all other would-be contributors to completely stop helping for awhile? What value does that add?
______________________________**_________________ 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
Another way to look at the remediation strategy is to have an independent source for building fix content. The source would provide basic information needed to change a system to a secure state. This information would reside alongside the check information in the XCCDF policy. Having a common source will help in achieving consistency in remedial actions performed by differing scripting languages or fix systems .
This method could also be used as a way to check parity in the checking and fixing content for correctness.
This is probably a good time to review Common Remediation Enumeration and see if fits into the project objective. CRE was created to identify and provide a reference point for actions necessary to correct a security issue. Based on the CRE-ID one could build remediation scripts and systems in a referenced way. The CRE-ID could also be used for traceability in troubleshooting and change control management.
-ln
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Jeffrey Blank Sent: Sunday, June 02, 2013 1:42 PM To: scap-security-guide@lists.fedorahosted.org Subject: Re: [PATCH 0/4] Remediation Templates
It is not so simple.
This is a strategy problem. If there is only one contributor who is capable of fixing OVAL problems, then there should be serious viability concerns about the project. The addition of remediation content, which would logically depend on this checking content, would only compound the problem. I am seeking evidence of community motivation and capability to address the OVAL problems before we move on to any remediation efforts.
There was significant irony in observations about how checking content (from Aqueduct, for example) is better than the checking content actually used by system auditors (who may be leveraging OVAL content issued by DISA), yet there seems to be so much interest in producing remediation content. DISA is waiting on our OVAL content to be fully baked so that they can issue it. How much testing of the OVAL content as described at https://fedorahosted.org/scap-security-guide/wiki/usageguide has been carried out? Does it work? Is it suitable to base remediation content on?
Another interesting note is that in fact tooling support from OpenSCAP for remediation scripts was further ahead than I thought:
https://www.redhat.com/archives/open-scap-list/2013-June/msg00001.html
(I again tip my hat to Simon and Peter and the other OpenSCAP devs.)
This means that, from a tooling perspective, the ability to automatically generate parameterized remediation scripts is already there (and my next post should put us yet closer to being able to work remediation). But still: if the checks aren't any good, then nobody should trust the remediation scripts generated.
On Sat, Jun 1, 2013 at 6:58 PM, Shawn Wells shawn@redhat.com wrote:
On 6/1/13 6:52 PM, Jeffrey Blank wrote:
Yes, but please hold off on remediation content until the OVAL validates per the schematron, and there is a means of handling parameters/variables in fix content. If you don't eat your meat, you can't have any pudding. But we should be able to have both.
The value of working sequentially doesn't make sense for such such a parallel development effort, with members of different skill levels contributing.
For example: I've no idea how to fix the remaining OVAL issues, so you're telling me and all other would-be contributors to completely stop helping for awhile? What value does that add?
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 6/4/13 1:43 PM, Nunez, Luis K wrote:
Another way to look at the remediation strategy is to have an independent source for building fix content. The source would provide basic information needed to change a system to a secure state. This information would reside alongside the check information in the XCCDF policy. Having a common source will help in achieving consistency in remedial actions performed by differing scripting languages or fix systems .
This method could also be used as a way to check parity in the checking and fixing content for correctness.
This is probably a good time to review Common Remediation Enumeration and see if fits into the project objective. CRE was created to identify and provide a reference point for actions necessary to correct a security issue. Based on the CRE-ID one could build remediation scripts and systems in a referenced way. The CRE-ID could also be used for traceability in troubleshooting and change control management.
Reviewed the examples @ http://scap.nist.gov/specifications/cre/1.0/cre_examples.xml
And then the spec @ http://scap.nist.gov/specifications/cre/1.0/cre_1.0-draft.xsd
Seems like this would be a major schema change, requiring updates to every rule, but I don't particularly see the value. Maybe it's just me being dense =/
Seems like an interesting approach to have XCCDF express "requirements," OVAL to check system state, <fix> tags for automated compliance, then CRE for manual remediation. From what I gather, the CRE really is a different way to express SSG's usage of OCIL tags. Can you help explain what value would be gained by changing content to CRE?
CRE is for identifying remediation related actions. Using CRE-IDs makes for easy references when conveying or describing remediations.
Fixing systems could also leverage this information as the basis to building remediation content in a preferred language or tool.
Value I see is in providing a common base upon which fix systems such as Anaconda, Puppet and others could provide consistent remediation. While bash meets the needs of providing automated scripted remediation for a localhost, from an enterprise management standpoint we need the flexibility in identifying remediation actions in identifiable way.
Users fear the term remediation used with STIGs, it is going to be a hard sell to implement automated remediation in any manner. CRE is not the silver bullet but it begins the process of accountability on what actions performed on a system. Side topic: has there been any thought on remediation roll back changes?
I am looking for ways in which to advance the state of automated remediation, which the SSG project is at the cutting edge. Scripting is a start, but we need to look at flexible ways to operate in diverse environments.
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Shawn Wells Sent: Tuesday, June 04, 2013 2:22 PM To: scap-security-guide@lists.fedorahosted.org Subject: Re: [PATCH 0/4] Remediation Templates
On 6/4/13 1:43 PM, Nunez, Luis K wrote:
Another way to look at the remediation strategy is to have an independent source for building fix content. The source would provide basic information needed to change a system to a secure state. This information would reside alongside the check information in the XCCDF policy. Having a common source will help in achieving consistency in remedial actions performed by differing scripting languages or fix systems .
This method could also be used as a way to check parity in the checking and fixing content for correctness.
This is probably a good time to review Common Remediation Enumeration and see if fits into the project objective. CRE was created to identify and provide a reference point for actions necessary to correct a security issue. Based on the CRE-ID one could build remediation scripts and systems in a referenced way. The CRE-ID could also be used for traceability in troubleshooting and change control management.
Reviewed the examples @ http://scap.nist.gov/specifications/cre/1.0/cre_examples.xml
And then the spec @ http://scap.nist.gov/specifications/cre/1.0/cre_1.0-draft.xsd
Seems like this would be a major schema change, requiring updates to every rule, but I don't particularly see the value. Maybe it's just me being dense =/
Seems like an interesting approach to have XCCDF express "requirements," OVAL to check system state, <fix> tags for automated compliance, then CRE for manual remediation. From what I gather, the CRE really is a different way to express SSG's usage of OCIL tags. Can you help explain what value would be gained by changing content to CRE?
On Tuesday, June 04, 2013 09:11:41 PM Nunez, Luis K wrote:
CRE is for identifying remediation related actions. Using CRE-IDs makes for easy references when conveying or describing remediations.
Fixing systems could also leverage this information as the basis to building remediation content in a preferred language or tool.
But CRE is an emerging standard. Which means that there is no software support for it in anything that I know of. It could change 5 more times in the next year. I don't know if its a good idea to use an unfinished standard.
Value I see is in providing a common base upon which fix systems such as Anaconda, Puppet and others could provide consistent remediation. While bash meets the needs of providing automated scripted remediation for a localhost, from an enterprise management standpoint we need the flexibility in identifying remediation actions in identifiable way.
Users fear the term remediation used with STIGs, it is going to be a hard sell to implement automated remediation in any manner. CRE is not the silver bullet but it begins the process of accountability on what actions performed on a system. Side topic: has there been any thought on remediation roll back changes?
I am looking for ways in which to advance the state of automated remediation, which the SSG project is at the cutting edge. Scripting is a start, but we need to look at flexible ways to operate in diverse environments.
One issue is that the tools on RHEL5/6 would be certifying to SCAP 1.2. Once that is done, they likely will not be updated for fear of losing the certification. Doing CRE work (assuming its ratified) would better fit with RHEL7 work where the tools could changed because SCAP 1.3 is not defined.
-Steve
scap-security-guide@lists.fedorahosted.org
-
Brian Millett -
Jeffrey Blank -
Nunez, Luis K -
Shawn Wells -
Shawn Wells -
Steve Grubb