We'll shortly be committing a script to do checking for consistency between our OVAL and XCCDF. This should detect situations such as:
1) a reference from an XCCDF rule to an OVAL definition that doesn't exist.
2) an XCCDF rule exists (and is used in a profile) but doesn't include any reference to a check.
3) mismatch between filename and OVAL definition name (as this is an important convention for our approach to modular definitions)
4) others?
On 3/12/12 5:59 PM, Jeffrey Blank wrote:
We'll shortly be committing a script to do checking for consistency between our OVAL and XCCDF. This should detect situations such as:
a reference from an XCCDF rule to an OVAL definition that doesn't exist.
an XCCDF rule exists (and is used in a profile) but doesn't include any reference to a check.
mismatch between filename and OVAL definition name (as this is an important convention for our approach to modular definitions)
I think the following would be helpful too:
4) An XCCDF rule exists and isn't used in a profile
5) Any checks that are not present in an XCCDF rule (I can't imagine there would actually be any of these given how we've been making XCCFD then the checks, but it'd be good to watch for)
Perhaps it's beyond the scope of this script but identifying rules without NIST controls would also be of value.
Number 5 could be tricky with respect to nested checks, some checks are not referenced in the xccdf directly.
V/r,
Kevin Spargur
On 03/12/2012 10:26 PM, Shawn Wells wrote:
On 3/12/12 5:59 PM, Jeffrey Blank wrote:
We'll shortly be committing a script to do checking for consistency between our OVAL and XCCDF. This should detect situations such as:
a reference from an XCCDF rule to an OVAL definition that doesn't exist.
an XCCDF rule exists (and is used in a profile) but doesn't include any reference to a check.
mismatch between filename and OVAL definition name (as this is an important convention for our approach to modular definitions)
I think the following would be helpful too:
An XCCDF rule exists and isn't used in a profile
Any checks that are not present in an XCCDF rule (I can't imagine there would actually be any of these given how we've been making XCCFD then the checks, but it'd be good to watch for) _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
A nicely loaded question.
As you've noticed, we don't have any <fix> tags. Such commands, when available, are just in the <description> or possibly <rationale>, and marked up with xhtml.
I also might expect there to be plenty of <Rule>s which simply won't have <fix> tags (such as edits to configuration files like pam.d/system-auth or sshd_config, or disk partitioning instructions). On the plus side, it would obviously be a cheap/easy way to annotate remediation instructions. On the minus side, I see it as leading to sed/awk in some of our output documents, and think this will make them less approachable/comprehensible. (I'm certainly fine with it being there, and hidden.)
Is there a project/effort/output which would benefit from <fix> tags?
On 03/13/2012 10:21 AM, Steve Grubb wrote:
On Monday, March 12, 2012 05:59:06 PM Jeffrey Blank wrote:
others?
Content without<fix> tags?
-Steve
On Tuesday, March 13, 2012 07:37:07 PM Jeffrey Blank wrote:
A nicely loaded question.
As you've noticed, we don't have any <fix> tags. Such commands, when available, are just in the <description> or possibly <rationale>, and marked up with xhtml.
I also might expect there to be plenty of <Rule>s which simply won't have <fix> tags (such as edits to configuration files like pam.d/system-auth or sshd_config, or disk partitioning instructions). On the plus side, it would obviously be a cheap/easy way to annotate remediation instructions. On the minus side, I see it as leading to sed/awk in some of our output documents, and think this will make them less approachable/comprehensible. (I'm certainly fine with it being there, and hidden.)
Is there a project/effort/output which would benefit from <fix> tags?
Yes. openscap can generate shell scripts from <fix> tags. The gentoo demo shows this. The aqueduct project is creating remediation scripts in shell. So, it sounds like we ought to work towards one document with guidance, check, and fix so that we can make remediation easy.
There are some fixes that are hard. I'd like to say we should incorprate the easy ones and identify the hard ones. Whene we have several of these, then we can start looking for how to solve the hard problems.
-Steve
On 3/13/12 9:44 PM, Steve Grubb wrote:
On Tuesday, March 13, 2012 07:37:07 PM Jeffrey Blank wrote:
A nicely loaded question.
As you've noticed, we don't have any<fix> tags. Such commands, when available, are just in the<description> or possibly <rationale>, and marked up with xhtml.
I also might expect there to be plenty of<Rule>s which simply won't have<fix> tags (such as edits to configuration files like pam.d/system-auth or sshd_config, or disk partitioning instructions). On the plus side, it would obviously be a cheap/easy way to annotate remediation instructions. On the minus side, I see it as leading to sed/awk in some of our output documents, and think this will make them less approachable/comprehensible. (I'm certainly fine with it being there, and hidden.)
Is there a project/effort/output which would benefit from<fix> tags?
Yes. openscap can generate shell scripts from<fix> tags. The gentoo demo shows this. The aqueduct project is creating remediation scripts in shell. So, it sounds like we ought to work towards one document with guidance, check, and fix so that we can make remediation easy.
FWIW, a big +1 to this.
There are some fixes that are hard. I'd like to say we should incorprate the easy ones and identify the hard ones. Whene we have several of these, then we can start looking for how to solve the hard problems.
I'm not to concerned about the hard fixes, largely as they've already been addressed through CLIP and/or Aqueduct. For example, DoDIIS open sourced their baseline (accredited to PL3) and we can pull a good bit from that.
On 3/13/12 9:52 PM, "Shawn Wells" shawn@redhat.com wrote:
On 3/13/12 9:44 PM, Steve Grubb wrote:
On Tuesday, March 13, 2012 07:37:07 PM Jeffrey Blank wrote:
A nicely loaded question.
As you've noticed, we don't have any<fix> tags. Such commands, when available, are just in the<description> or
possibly
<rationale>, and marked up with xhtml.
I also might expect there to be plenty of<Rule>s which simply won't have<fix> tags (such as edits to configuration files like pam.d/system-auth or sshd_config, or disk partitioning
instructions).
On the plus side, it would obviously be a cheap/easy way to annotate remediation instructions. On the minus side, I see it as leading to sed/awk in some of our output documents, and think this will make
them
less approachable/comprehensible. (I'm certainly fine with it being there, and hidden.)
Is there a project/effort/output which would benefit from<fix>
tags?
Yes. openscap can generate shell scripts from<fix> tags. The gentoo demo shows this. The aqueduct project is creating remediation scripts in shell. So, it sounds like we ought to work towards one document with guidance, check, and fix so that we can make remediation easy.
FWIW, a big +1 to this.
I understand that we can generate whatever we want from the <fix> tags but I want to ensure the generated content is consumable by the larger community. Are the <fix> tags flexible enough to support the forward movement of system configuration tools?
I know the rest of this is long but bear with me here because, much like SCAP, there are a lot of relationships that must be addressed by a successful solution.
While I would like to see a single source for all SCAP content, the mechanisms to address remediation under SCAP aren't mature. It has taken the Puppet/Augeas teams a lot of effort to get to the current state which can be leveraged to address remediation while SCAP-standard remediation matures. It may not be the ideal solution but it is a huge step in the right direction. I think the goal here, and I think this is what Steve is saying, should be to start implementing a binding between the XCCDF, OVAL, and remediation content. Of course this is supported by the defined standards but someone has to write the content to actually perform the binding.
As Jeff states, there are going to be gaps. There won't always be remediation content available for numerous reasons. We are trying to address part of that problem. Tresys is currently mapping several requirement sets to controls and implementation (DCID 6/3 PL4 High/High, CNSSI 1253, NIST 800.53). We are starting with the SNAC guide to provide the implementation guidance. Where necessary we are writing Puppet content to address controls and remediation. We are also writing OVAL content to complement and test the remediation content.
I would appreciate comments and feedback on the above but I'm really interested in knowing the community's opinion on how to handle binding XCCDF/OVAL to remediation in the short-term. The hope is that the remediation language will mature and the remediation content we are all working on now can be re-used in the future.
CLIP was developed to reduce the burden associated with creating a C&A'able solution based on Red Hat Enterprise Linux. This has been accomplished through configuration, customization of packages, and providing supporting evidence mapping the implementation into requirements and controls. We are now taking the next steps by: 1. ensuring all targeted requirement sets are in XCCDF, 2. ensuring the implementation guidance is available in a similar format (SNAC->XCCDF), 3. filling the implementation documentation gaps found in #2 above (basically adding to SNAC guidance), 4. determining where OVAL content can test the implementation, 5. ensuring OVAL content is developed that addresses the gap identified in #4 above, 6. developing puppet content to address as many reqs and controls as we can.
As if there aren't enough goals described above - I think the pen-ultimate goal for reqs management from Tresys' upcoming XCCDF/OVAL contributions to scap-security-guide is to see SCAP content that can be consumed by developers, accreditors, and admins. We hope this binding will be flexible enough to facilitate tying the XCCDF to other types of content in the future, like OCIL.
Thanks, --Spencer
There are some fixes that are hard. I'd like to say we should incorprate the easy ones and identify the hard ones. Whene we have several of these, then we can start looking for how to solve the hard problems.
I'm not to concerned about the hard fixes, largely as they've already been addressed through CLIP and/or Aqueduct. For example, DoDIIS open sourced their baseline (accredited to PL3) and we can pull a good bit from that. _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
On Wednesday, March 14, 2012 12:41:51 AM Spencer R. Shimko wrote:
On 3/13/12 9:52 PM, "Shawn Wells" shawn@redhat.com wrote:
On 3/13/12 9:44 PM, Steve Grubb wrote:
On Tuesday, March 13, 2012 07:37:07 PM Jeffrey Blank wrote:
A nicely loaded question.
As you've noticed, we don't have any<fix> tags. Such commands, when available, are just in the<description> or
possibly
<rationale>, and marked up with xhtml.
I also might expect there to be plenty of<Rule>s which simply won't have<fix> tags (such as edits to configuration files like pam.d/system-auth or sshd_config, or disk partitioning
instructions).
On the plus side, it would obviously be a cheap/easy way to annotate remediation instructions. On the minus side, I see it as leading to sed/awk in some of our output documents, and think this will make
them
less approachable/comprehensible. (I'm certainly fine with it being there, and hidden.)
Is there a project/effort/output which would benefit from<fix>
tags?
Yes. openscap can generate shell scripts from<fix> tags. The gentoo
demo shows
this. The aqueduct project is creating remediation scripts in shell.
So, it
sounds like we ought to work towards one document with guidance, check,
and fix
so that we can make remediation easy.
FWIW, a big +1 to this.
I understand that we can generate whatever we want from the <fix> tags but I want to ensure the generated content is consumable by the larger community. Are the <fix> tags flexible enough to support the forward movement of system configuration tools?
I know the rest of this is long but bear with me here because, much like SCAP, there are a lot of relationships that must be addressed by a successful solution.
There are hard fixes and there are easy fixes. Let's look at one publicly available validated solution:
http://people.redhat.com/sgrubb/files/usgcb/rhel5/workstation-ks.cfg
NIST published an exact copy of that file. Look at what is being done to configure the system. The vast majority break down to this:
chkconfig chmod echo gconftool-2 mkdir rpm --import sed touch useradd
They are all one liners. Now if a package was required and it needing to be in a specific configuration and it drags in dependencies and they also have changes to their configs or perhaps have multilpe daemons which may or may not need to be enabled or disabled...we have a hard problem. In which case, maybe the solution is:
echo "Requirement xyz cannot be met by this script, please solve it manually. Do you understand? [y/n]" read ANS
And then when/if the remediation standards mature, we can address the hard problems. Just making the simple solutions available is a big first step in the right direction.
-Steve
While I would like to see a single source for all SCAP content, the mechanisms to address remediation under SCAP aren't mature. It has taken the Puppet/Augeas teams a lot of effort to get to the current state which can be leveraged to address remediation while SCAP-standard remediation matures. It may not be the ideal solution but it is a huge step in the right direction. I think the goal here, and I think this is what Steve is saying, should be to start implementing a binding between the XCCDF, OVAL, and remediation content. Of course this is supported by the defined standards but someone has to write the content to actually perform the binding.
As Jeff states, there are going to be gaps. There won't always be remediation content available for numerous reasons. We are trying to address part of that problem. Tresys is currently mapping several requirement sets to controls and implementation (DCID 6/3 PL4 High/High, CNSSI 1253, NIST 800.53). We are starting with the SNAC guide to provide the implementation guidance. Where necessary we are writing Puppet content to address controls and remediation. We are also writing OVAL content to complement and test the remediation content.
I would appreciate comments and feedback on the above but I'm really interested in knowing the community's opinion on how to handle binding XCCDF/OVAL to remediation in the short-term. The hope is that the remediation language will mature and the remediation content we are all working on now can be re-used in the future.
CLIP was developed to reduce the burden associated with creating a C&A'able solution based on Red Hat Enterprise Linux. This has been accomplished through configuration, customization of packages, and providing supporting evidence mapping the implementation into requirements and controls. We are now taking the next steps by:
- ensuring all targeted requirement sets are in XCCDF,
- ensuring the implementation guidance is available in a similar format
(SNAC->XCCDF), 3. filling the implementation documentation gaps found in #2 above (basically adding to SNAC guidance), 4. determining where OVAL content can test the implementation, 5. ensuring OVAL content is developed that addresses the gap identified in #4 above, 6. developing puppet content to address as many reqs and controls as we can.
As if there aren't enough goals described above - I think the pen-ultimate goal for reqs management from Tresys' upcoming XCCDF/OVAL contributions to scap-security-guide is to see SCAP content that can be consumed by developers, accreditors, and admins. We hope this binding will be flexible enough to facilitate tying the XCCDF to other types of content in the future, like OCIL.
Thanks, --Spencer
There are some fixes that are hard. I'd like to say we should
incorprate the easy
ones and identify the hard ones. Whene we have several of these, then
we can
start looking for how to solve the hard problems.
I'm not to concerned about the hard fixes, largely as they've already been addressed through CLIP and/or Aqueduct. For example, DoDIIS open sourced their baseline (accredited to PL3) and we can pull a good bit from that. _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
----- Original Message -----
On Wednesday, March 14, 2012 12:41:51 AM Spencer R. Shimko wrote:
On 3/13/12 9:52 PM, "Shawn Wells" shawn@redhat.com wrote:
On 3/13/12 9:44 PM, Steve Grubb wrote:
On Tuesday, March 13, 2012 07:37:07 PM Jeffrey Blank wrote:
A nicely loaded question.
As you've noticed, we don't have any<fix> tags. Such commands, when available, are just in the<description> or
possibly
<rationale>, and marked up with xhtml.
I also might expect there to be plenty of<Rule>s which simply won't have<fix> tags (such as edits to configuration files like pam.d/system-auth or sshd_config, or disk partitioning
instructions).
On the plus side, it would obviously be a cheap/easy way to annotate remediation instructions. On the minus side, I see it as leading to sed/awk in some of our output documents, and think this will make
them
less approachable/comprehensible. (I'm certainly fine with it being there, and hidden.)
Is there a project/effort/output which would benefit from<fix>
tags?
Yes. openscap can generate shell scripts from<fix> tags. The gentoo
demo shows
this. The aqueduct project is creating remediation scripts in shell.
So, it
sounds like we ought to work towards one document with guidance, check,
and fix
so that we can make remediation easy.
FWIW, a big +1 to this.
I understand that we can generate whatever we want from the <fix> tags but I want to ensure the generated content is consumable by the larger community. Are the <fix> tags flexible enough to support the forward movement of system configuration tools?
I know the rest of this is long but bear with me here because, much like SCAP, there are a lot of relationships that must be addressed by a successful solution.
There are hard fixes and there are easy fixes. Let's look at one publicly available validated solution:
http://people.redhat.com/sgrubb/files/usgcb/rhel5/workstation-ks.cfg
NIST published an exact copy of that file. Look at what is being done to configure the system. The vast majority break down to this:
chkconfig chmod echo gconftool-2 mkdir rpm --import sed touch useradd
They are all one liners. Now if a package was required and it needing to be in a specific configuration and it drags in dependencies and they also have changes to their configs or perhaps have multilpe daemons which may or may not need to be enabled or disabled...we have a hard problem. In which case, maybe the solution is:
echo "Requirement xyz cannot be met by this script, please solve it manually. Do you understand? [y/n]" read ANS
That's a great idea. It would also be good to have a yum-like "-y" option for automation. One wouldn't want to run the remediation on 1000 systems interactively by hand.
I wonder if it would be good to have a to-do checklist / report at the end in say .csv? Do as much as possible in an automated way, and then have a to-do list that people can print out, check the box when done with an element, do the next one, etc.
Dave
And then when/if the remediation standards mature, we can address the hard problems. Just making the simple solutions available is a big first step in the right direction.
-Steve
While I would like to see a single source for all SCAP content, the mechanisms to address remediation under SCAP aren't mature. It has taken the Puppet/Augeas teams a lot of effort to get to the current state which can be leveraged to address remediation while SCAP-standard remediation matures. It may not be the ideal solution but it is a huge step in the right direction. I think the goal here, and I think this is what Steve is saying, should be to start implementing a binding between the XCCDF, OVAL, and remediation content. Of course this is supported by the defined standards but someone has to write the content to actually perform the binding.
As Jeff states, there are going to be gaps. There won't always be remediation content available for numerous reasons. We are trying to address part of that problem. Tresys is currently mapping several requirement sets to controls and implementation (DCID 6/3 PL4 High/High, CNSSI 1253, NIST 800.53). We are starting with the SNAC guide to provide the implementation guidance. Where necessary we are writing Puppet content to address controls and remediation. We are also writing OVAL content to complement and test the remediation content.
I would appreciate comments and feedback on the above but I'm really interested in knowing the community's opinion on how to handle binding XCCDF/OVAL to remediation in the short-term. The hope is that the remediation language will mature and the remediation content we are all working on now can be re-used in the future.
CLIP was developed to reduce the burden associated with creating a C&A'able solution based on Red Hat Enterprise Linux. This has been accomplished through configuration, customization of packages, and providing supporting evidence mapping the implementation into requirements and controls. We are now taking the next steps by:
- ensuring all targeted requirement sets are in XCCDF,
- ensuring the implementation guidance is available in a similar
format (SNAC->XCCDF), 3. filling the implementation documentation gaps found in #2 above (basically adding to SNAC guidance), 4. determining where OVAL content can test the implementation, 5. ensuring OVAL content is developed that addresses the gap identified in #4 above, 6. developing puppet content to address as many reqs and controls as we can.
As if there aren't enough goals described above - I think the pen-ultimate goal for reqs management from Tresys' upcoming XCCDF/OVAL contributions to scap-security-guide is to see SCAP content that can be consumed by developers, accreditors, and admins. We hope this binding will be flexible enough to facilitate tying the XCCDF to other types of content in the future, like OCIL.
Thanks, --Spencer
There are some fixes that are hard. I'd like to say we should
incorprate the easy
ones and identify the hard ones. Whene we have several of these, then
we can
start looking for how to solve the hard problems.
I'm not to concerned about the hard fixes, largely as they've already been addressed through CLIP and/or Aqueduct. For example, DoDIIS open sourced their baseline (accredited to PL3) and we can pull a good bit from that. _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
On 3/14/12 12:49 PM, "David Egts" degts@redhat.com wrote:
----- Original Message -----
On Wednesday, March 14, 2012 12:41:51 AM Spencer R. Shimko wrote:
On 3/13/12 9:52 PM, "Shawn Wells" shawn@redhat.com wrote:
On 3/13/12 9:44 PM, Steve Grubb wrote:
On Tuesday, March 13, 2012 07:37:07 PM Jeffrey Blank wrote:
> A nicely loaded question. > > As you've noticed, we don't have any<fix> tags. > Such commands, when available, are just in the<description> > or
possibly
> <rationale>, and marked up with xhtml. > > I also might expect there to be plenty of<Rule>s which > simply won't > have<fix> tags (such as edits to configuration files like > pam.d/system-auth or sshd_config, or disk partitioning
instructions).
> On the plus side, it would obviously be a cheap/easy way to > annotate > remediation instructions. On the minus side, I see it as > leading to > sed/awk in some of our output documents, and think this will > make
them
> less approachable/comprehensible. (I'm certainly fine with > it being > there, and hidden.) > > Is there a project/effort/output which would benefit > from<fix>
tags?
Yes. openscap can generate shell scripts from<fix> tags. The gentoo
demo shows
this. The aqueduct project is creating remediation scripts in shell.
So, it
sounds like we ought to work towards one document with guidance, check,
and fix
so that we can make remediation easy.
FWIW, a big +1 to this.
I understand that we can generate whatever we want from the <fix> tags but I want to ensure the generated content is consumable by the larger community. Are the <fix> tags flexible enough to support the forward movement of system configuration tools?
I know the rest of this is long but bear with me here because, much like SCAP, there are a lot of relationships that must be addressed by a successful solution.
There are hard fixes and there are easy fixes. Let's look at one publicly available validated solution:
http://people.redhat.com/sgrubb/files/usgcb/rhel5/workstation-ks.cfg
NIST published an exact copy of that file. Look at what is being done to configure the system. The vast majority break down to this:
chkconfig chmod echo gconftool-2 mkdir rpm --import sed touch useradd
They are all one liners. Now if a package was required and it needing to be in a specific configuration and it drags in dependencies and they also have changes to their configs or perhaps have multilpe daemons which may or may not need to be enabled or disabled...we have a hard problem. In which case, maybe the solution is:
echo "Requirement xyz cannot be met by this script, please solve it manually. Do you understand? [y/n]" read ANS
That's a great idea. It would also be good to have a yum-like "-y" option for automation. One wouldn't want to run the remediation on 1000 systems interactively by hand.
Are you thinking of something significantly different from the secstate effort?
https://fedorahosted.org/secstate/
I wonder if it would be good to have a to-do checklist / report at the end in say .csv? Do as much as possible in an automated way, and then have a to-do list that people can print out, check the box when done with an element, do the next one, etc.
I forgot to mention this part below. This is exactly what we are working towards. We will generate a report that can used as part of the larger body of C&A evidence. It will also generate an SRTM and developer guidance ala SNAC. This will effectively be a table that includes automated and manual controls. Then they can fill in the gaps. We will be upstreaming the content and accompanying transformations into ssg (aside from DCID 6/3 which is FOUO).
--Spencer
Dave
And then when/if the remediation standards mature, we can address the hard problems. Just making the simple solutions available is a big first step in the right direction.
-Steve
While I would like to see a single source for all SCAP content, the mechanisms to address remediation under SCAP aren't mature. It has taken the Puppet/Augeas teams a lot of effort to get to the current state which can be leveraged to address remediation while SCAP-standard remediation matures. It may not be the ideal solution but it is a huge step in the right direction. I think the goal here, and I think this is what Steve is saying, should be to start implementing a binding between the XCCDF, OVAL, and remediation content. Of course this is supported by the defined standards but someone has to write the content to actually perform the binding.
As Jeff states, there are going to be gaps. There won't always be remediation content available for numerous reasons. We are trying to address part of that problem. Tresys is currently mapping several requirement sets to controls and implementation (DCID 6/3 PL4 High/High, CNSSI 1253, NIST 800.53). We are starting with the SNAC guide to provide the implementation guidance. Where necessary we are writing Puppet content to address controls and remediation. We are also writing OVAL content to complement and test the remediation content.
I would appreciate comments and feedback on the above but I'm really interested in knowing the community's opinion on how to handle binding XCCDF/OVAL to remediation in the short-term. The hope is that the remediation language will mature and the remediation content we are all working on now can be re-used in the future.
CLIP was developed to reduce the burden associated with creating a C&A'able solution based on Red Hat Enterprise Linux. This has been accomplished through configuration, customization of packages, and providing supporting evidence mapping the implementation into requirements and controls. We are now taking the next steps by:
- ensuring all targeted requirement sets are in XCCDF,
- ensuring the implementation guidance is available in a similar
format (SNAC->XCCDF), 3. filling the implementation documentation gaps found in #2 above (basically adding to SNAC guidance), 4. determining where OVAL content can test the implementation, 5. ensuring OVAL content is developed that addresses the gap identified in #4 above, 6. developing puppet content to address as many reqs and controls as we can.
As if there aren't enough goals described above - I think the pen-ultimate goal for reqs management from Tresys' upcoming XCCDF/OVAL contributions to scap-security-guide is to see SCAP content that can be consumed by developers, accreditors, and admins. We hope this binding will be flexible enough to facilitate tying the XCCDF to other types of content in the future, like OCIL.
Thanks, --Spencer
There are some fixes that are hard. I'd like to say we should
incorprate the easy
ones and identify the hard ones. Whene we have several of these, then
we can
start looking for how to solve the hard problems.
I'm not to concerned about the hard fixes, largely as they've already been addressed through CLIP and/or Aqueduct. For example, DoDIIS open sourced their baseline (accredited to PL3) and we can pull a good bit from that. _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
-- David D. Egts, RHCA, RHCSS #805007796228001 Principal Architect, Red Hat, Inc. _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
----- Original Message -----
On 3/14/12 12:49 PM, "David Egts" degts@redhat.com wrote:
----- Original Message -----
On Wednesday, March 14, 2012 12:41:51 AM Spencer R. Shimko wrote:
On 3/13/12 9:52 PM, "Shawn Wells" shawn@redhat.com wrote:
On 3/13/12 9:44 PM, Steve Grubb wrote:
On Tuesday, March 13, 2012 07:37:07 PM Jeffrey Blank wrote: > > A nicely loaded question. > > > > As you've noticed, we don't have any<fix> tags. > > Such commands, when available, are just in > > the<description> > > or > >possibly > > > <rationale>, and marked up with xhtml. > > > > I also might expect there to be plenty of<Rule>s which > > simply won't > > have<fix> tags (such as edits to configuration files > > like > > pam.d/system-auth or sshd_config, or disk partitioning > >instructions). > > > On the plus side, it would obviously be a cheap/easy way > > to > > annotate > > remediation instructions. On the minus side, I see it as > > leading to > > sed/awk in some of our output documents, and think this > > will > > make > >them > > > less approachable/comprehensible. (I'm certainly fine > > with > > it being > > there, and hidden.) > > > > Is there a project/effort/output which would benefit > > from<fix> > >tags? > Yes. openscap can generate shell scripts from<fix> tags. The gentoo
demo shows
this. The aqueduct project is creating remediation scripts in shell.
So, it
sounds like we ought to work towards one document with guidance, check,
and fix
so that we can make remediation easy.
FWIW, a big +1 to this.
I understand that we can generate whatever we want from the
<fix> tags but I want to ensure the generated content is consumable by the larger community. Are the <fix> tags flexible enough to support the forward movement of system configuration tools?
I know the rest of this is long but bear with me here because, much like SCAP, there are a lot of relationships that must be addressed by a successful solution.
There are hard fixes and there are easy fixes. Let's look at one publicly available validated solution:
http://people.redhat.com/sgrubb/files/usgcb/rhel5/workstation-ks.cfg
NIST published an exact copy of that file. Look at what is being done to configure the system. The vast majority break down to this:
chkconfig chmod echo gconftool-2 mkdir rpm --import sed touch useradd
They are all one liners. Now if a package was required and it needing to be in a specific configuration and it drags in dependencies and they also have changes to their configs or perhaps have multilpe daemons which may or may not need to be enabled or disabled...we have a hard problem. In which case, maybe the solution is:
echo "Requirement xyz cannot be met by this script, please solve it manually. Do you understand? [y/n]" read ANS
That's a great idea. It would also be good to have a yum-like "-y" option for automation. One wouldn't want to run the remediation on 1000 systems interactively by hand.
Are you thinking of something significantly different from the secstate effort?
If that's the accepted approach, great! I'm just saying that automation (however we do it) is highly desired.
So does SSG plan to provide secstate remediation content? Apologies for the n00b question.
Also, it looks like secstate is tied closely with Puppet (good intro for me = https://fedorahosted.org/secstate/wiki/RemediationContentHowTo). How would one use secstate if their DAA doesn't allow packages from community supported sources (i.e., puppet from EPEL)? Maybe Red Hat's possible formal support for Puppet in the future will eventually solve this, but I wonder what the plan would be in the mean time.
Thanks for helping me learn more about this Spencer!
Dave
I wonder if it would be good to have a to-do checklist / report at the end in say .csv? Do as much as possible in an automated way, and then have a to-do list that people can print out, check the box when done with an element, do the next one, etc.
I forgot to mention this part below. This is exactly what we are working towards. We will generate a report that can used as part of the larger body of C&A evidence. It will also generate an SRTM and developer guidance ala SNAC. This will effectively be a table that includes automated and manual controls. Then they can fill in the gaps. We will be upstreaming the content and accompanying transformations into ssg (aside from DCID 6/3 which is FOUO).
--Spencer
Dave
And then when/if the remediation standards mature, we can address the hard problems. Just making the simple solutions available is a big first step in the right direction.
-Steve
While I would like to see a single source for all SCAP content, the mechanisms to address remediation under SCAP aren't mature. It has taken the Puppet/Augeas teams a lot of effort to get to the current state which can be leveraged to address remediation while SCAP-standard remediation matures. It may not be the ideal solution but it is a huge step in the right direction. I think the goal here, and I think this is what Steve is saying, should be to start implementing a binding between the XCCDF, OVAL, and remediation content. Of course this is supported by the defined standards but someone has to write the content to actually perform the binding.
As Jeff states, there are going to be gaps. There won't always be remediation content available for numerous reasons. We are trying to address part of that problem. Tresys is currently mapping several requirement sets to controls and implementation (DCID 6/3 PL4 High/High, CNSSI 1253, NIST 800.53). We are starting with the SNAC guide to provide the implementation guidance. Where necessary we are writing Puppet content to address controls and remediation. We are also writing OVAL content to complement and test the remediation content.
I would appreciate comments and feedback on the above but I'm really interested in knowing the community's opinion on how to handle binding XCCDF/OVAL to remediation in the short-term. The hope is that the remediation language will mature and the remediation content we are all working on now can be re-used in the future.
CLIP was developed to reduce the burden associated with creating a C&A'able solution based on Red Hat Enterprise Linux. This has been accomplished through configuration, customization of packages, and providing supporting evidence mapping the implementation into requirements and controls. We are now taking the next steps by:
- ensuring all targeted requirement sets are in XCCDF,
- ensuring the implementation guidance is available in a
similar format (SNAC->XCCDF), 3. filling the implementation documentation gaps found in #2 above (basically adding to SNAC guidance), 4. determining where OVAL content can test the implementation, 5. ensuring OVAL content is developed that addresses the gap identified in #4 above, 6. developing puppet content to address as many reqs and controls as we can.
As if there aren't enough goals described above - I think the pen-ultimate goal for reqs management from Tresys' upcoming XCCDF/OVAL contributions to scap-security-guide is to see SCAP content that can be consumed by developers, accreditors, and admins. We hope this binding will be flexible enough to facilitate tying the XCCDF to other types of content in the future, like OCIL.
Thanks, --Spencer
There are some fixes that are hard. I'd like to say we should
incorprate the easy
ones and identify the hard ones. Whene we have several of these, then
we can
start looking for how to solve the hard problems.
I'm not to concerned about the hard fixes, largely as they've already been addressed through CLIP and/or Aqueduct. For example, DoDIIS open sourced their baseline (accredited to PL3) and we can pull a good bit from that. _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
-- David D. Egts, RHCA, RHCSS #805007796228001 Principal Architect, Red Hat, Inc. _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
On 03/14/2012 02:23 PM, David Egts wrote:
----- Original Message -----
On 3/14/12 12:49 PM, "David Egts"degts@redhat.com wrote:
----- Original Message -----
On Wednesday, March 14, 2012 12:41:51 AM Spencer R. Shimko wrote:
On 3/13/12 9:52 PM, "Shawn Wells"shawn@redhat.com wrote:
On 3/13/12 9:44 PM, Steve Grubb wrote: > On Tuesday, March 13, 2012 07:37:07 PM Jeffrey Blank wrote: >>> A nicely loaded question. >>> >>> As you've noticed, we don't have any<fix> tags. >>> Such commands, when available, are just in >>> the<description> >>> or >> possibly >> >>> <rationale>, and marked up with xhtml. >>> >>> I also might expect there to be plenty of<Rule>s which >>> simply won't >>> have<fix> tags (such as edits to configuration files >>> like >>> pam.d/system-auth or sshd_config, or disk partitioning >> instructions). >> >>> On the plus side, it would obviously be a cheap/easy way >>> to >>> annotate >>> remediation instructions. On the minus side, I see it as >>> leading to >>> sed/awk in some of our output documents, and think this >>> will >>> make >> them >> >>> less approachable/comprehensible. (I'm certainly fine >>> with >>> it being >>> there, and hidden.) >>> >>> Is there a project/effort/output which would benefit >>> from<fix> >> tags? >> > Yes. openscap can generate shell scripts from<fix> tags. The > gentoo > > demo shows > > this. The aqueduct project is creating remediation scripts in > shell. > > So, it > > sounds like we ought to work towards one document with > guidance, > check, > > and fix > > so that we can make remediation easy. FWIW, a big +1 to this.
I understand that we can generate whatever we want from the
<fix> tags but I want to ensure the generated content is consumable by the larger community. Are the<fix> tags flexible enough to support the forward movement of system configuration tools?
I know the rest of this is long but bear with me here because, much like SCAP, there are a lot of relationships that must be addressed by a successful solution.
There are hard fixes and there are easy fixes. Let's look at one publicly available validated solution:
http://people.redhat.com/sgrubb/files/usgcb/rhel5/workstation-ks.cfg
NIST published an exact copy of that file. Look at what is being done to configure the system. The vast majority break down to this:
chkconfig chmod echo gconftool-2 mkdir rpm --import sed touch useradd
They are all one liners. Now if a package was required and it needing to be in a specific configuration and it drags in dependencies and they also have changes to their configs or perhaps have multilpe daemons which may or may not need to be enabled or disabled...we have a hard problem. In which case, maybe the solution is:
echo "Requirement xyz cannot be met by this script, please solve it manually. Do you understand? [y/n]" read ANS
That's a great idea. It would also be good to have a yum-like "-y" option for automation. One wouldn't want to run the remediation on 1000 systems interactively by hand.
Are you thinking of something significantly different from the secstate effort?
If that's the accepted approach, great! I'm just saying that automation (however we do it) is highly desired.
So does SSG plan to provide secstate remediation content? Apologies for the n00b question.
Also, it looks like secstate is tied closely with Puppet (good intro for me = https://fedorahosted.org/secstate/wiki/RemediationContentHowTo). How would one use secstate if their DAA doesn't allow packages from community supported sources (i.e., puppet from EPEL)? Maybe Red Hat's possible formal support for Puppet in the future will eventually solve this, but I wonder what the plan would be in the mean time.
Thanks for helping me learn more about this Spencer!
Dave
Leveraging the SSG for fix automation would be ideal. We already have a milestone for a complete prose guide that is being worked toward. I'd suggest we add another for a guide with the complete prose and check content. We can then add a third milestone for complete fix content, even if we have to resort to "go forth and remediate" for the more complex fixes.
-Kevin
I wonder if it would be good to have a to-do checklist / report at the end in say .csv? Do as much as possible in an automated way, and then have a to-do list that people can print out, check the box when done with an element, do the next one, etc.
I forgot to mention this part below. This is exactly what we are working towards. We will generate a report that can used as part of the larger body of C&A evidence. It will also generate an SRTM and developer guidance ala SNAC. This will effectively be a table that includes automated and manual controls. Then they can fill in the gaps. We will be upstreaming the content and accompanying transformations into ssg (aside from DCID 6/3 which is FOUO).
--Spencer
Dave
And then when/if the remediation standards mature, we can address the hard problems. Just making the simple solutions available is a big first step in the right direction.
-Steve
While I would like to see a single source for all SCAP content, the mechanisms to address remediation under SCAP aren't mature. It has taken the Puppet/Augeas teams a lot of effort to get to the current state which can be leveraged to address remediation while SCAP-standard remediation matures. It may not be the ideal solution but it is a huge step in the right direction. I think the goal here, and I think this is what Steve is saying, should be to start implementing a binding between the XCCDF, OVAL, and remediation content. Of course this is supported by the defined standards but someone has to write the content to actually perform the binding.
As Jeff states, there are going to be gaps. There won't always be remediation content available for numerous reasons. We are trying to address part of that problem. Tresys is currently mapping several requirement sets to controls and implementation (DCID 6/3 PL4 High/High, CNSSI 1253, NIST 800.53). We are starting with the SNAC guide to provide the implementation guidance. Where necessary we are writing Puppet content to address controls and remediation. We are also writing OVAL content to complement and test the remediation content.
I would appreciate comments and feedback on the above but I'm really interested in knowing the community's opinion on how to handle binding XCCDF/OVAL to remediation in the short-term. The hope is that the remediation language will mature and the remediation content we are all working on now can be re-used in the future.
CLIP was developed to reduce the burden associated with creating a C&A'able solution based on Red Hat Enterprise Linux. This has been accomplished through configuration, customization of packages, and providing supporting evidence mapping the implementation into requirements and controls. We are now taking the next steps by:
- ensuring all targeted requirement sets are in XCCDF,
- ensuring the implementation guidance is available in a
similar format (SNAC->XCCDF), 3. filling the implementation documentation gaps found in #2 above (basically adding to SNAC guidance), 4. determining where OVAL content can test the implementation, 5. ensuring OVAL content is developed that addresses the gap identified in #4 above, 6. developing puppet content to address as many reqs and controls as we can.
As if there aren't enough goals described above - I think the pen-ultimate goal for reqs management from Tresys' upcoming XCCDF/OVAL contributions to scap-security-guide is to see SCAP content that can be consumed by developers, accreditors, and admins. We hope this binding will be flexible enough to facilitate tying the XCCDF to other types of content in the future, like OCIL.
Thanks, --Spencer
> There are some fixes that are hard. I'd like to say we should > > incorprate the easy > > ones and identify the hard ones. Whene we have several of > these, > then > > we can > > start looking for how to solve the hard problems. I'm not to concerned about the hard fixes, largely as they've already been addressed through CLIP and/or Aqueduct. For example, DoDIIS open sourced their baseline (accredited to PL3) and we can pull a good bit from that. _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
-- David D. Egts, RHCA, RHCSS #805007796228001 Principal Architect, Red Hat, Inc. _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
On 3/14/12 2:46 PM, "Kevin Spargur" kspargur@redhat.com wrote:
Leveraging the SSG for fix automation would be ideal. We already have a milestone for a complete prose guide that is being worked toward. I'd suggest we add another for a guide with the complete prose and check content. We can then add a third milestone for complete fix content, even if we have to resort to "go forth and remediate" for the more complex fixes.
Darn duplication of effort. We had started down the path of completing the merge of the SNAC prose into the SSG. I thought the ball had dropped there so we picked it up. Is someone actively working towards that initial milestone or are should we keep going?
This is my fault for not communicating more openly as we started tackling tasks. What can we do to help get you to that milestone?
Thanks, --Spencer
-Kevin
On 3/14/12 2:23 PM, "David Egts" degts@redhat.com wrote:
----- Original Message -----
On 3/14/12 12:49 PM, "David Egts" degts@redhat.com wrote:
----- Original Message -----
On Wednesday, March 14, 2012 12:41:51 AM Spencer R. Shimko wrote:
On 3/13/12 9:52 PM, "Shawn Wells" shawn@redhat.com wrote:
On 3/13/12 9:44 PM, Steve Grubb wrote: > On Tuesday, March 13, 2012 07:37:07 PM Jeffrey Blank wrote:
<snip> >> > >> > I understand that we can generate whatever we want from the >> > <fix> >> > tags but >> > I want to ensure the generated content is consumable by the >> > larger >> > community. Are the <fix> tags flexible enough to support the >> > forward >> > movement of system configuration tools? >> > >> > I know the rest of this is long but bear with me here because, >> > much >> > like >> > SCAP, there are a lot of relationships that must be addressed by >> > a >> > successful solution. >> >> There are hard fixes and there are easy fixes. Let's look at one >> publicly >> available validated solution: >> >> http://people.redhat.com/sgrubb/files/usgcb/rhel5/workstation-ks.cfg >> >> NIST published an exact copy of that file. Look at what is being >> done >> to configure >> the system. The vast majority break down to this: >> >> chkconfig >> chmod >> echo >> gconftool-2 >> mkdir >> rpm --import >> sed >> touch >> useradd >> >> They are all one liners. Now if a package was required and it >> needing >> to be in a >> specific configuration and it drags in dependencies and they also >> have changes to >> their configs or perhaps have multilpe daemons which may or may >> not >> need to be >> enabled or disabled...we have a hard problem. In which case, maybe >> the solution >> is: >> >> echo "Requirement xyz cannot be met by this script, please solve >> it >> manually. Do >> you understand? [y/n]" >> read ANS > >That's a great idea. It would also be good to have a yum-like "-y" >option for automation. One wouldn't want to run the remediation on >1000 >systems interactively by hand.
Are you thinking of something significantly different from the secstate effort?
If that's the accepted approach, great! I'm just saying that automation (however we do it) is highly desired.
So does SSG plan to provide secstate remediation content? Apologies for the n00b question.
Jeff and I have been discussing this and I think that we will host the Puppet remediation content as part of the CLIP project. When/if the SCAP remediation standard is mature enough to handle the task we will convert the content and push it to SSG.
We have also discussed the issue of binding the two sets of content (SSG and Puppet in CLIP). We have some ideas here but nothing significant.
I'm definitely interested in any input you or other members of the list have on this plan. Particularly since I see the binding of content from two repos to be very fragile.
Also, it looks like secstate is tied closely with Puppet (good intro for me = https://fedorahosted.org/secstate/wiki/RemediationContentHowTo). How would one use secstate if their DAA doesn't allow packages from community supported sources (i.e., puppet from EPEL)? Maybe Red Hat's possible formal support for Puppet in the future will eventually solve this, but I wonder what the plan would be in the mean time.
This is certainly an issue and I don't have an answer. To-date our CLIP user base has been OK with us including Puppet and a few other necessary packages from EPEL. It is basically devs rolling custom ISOs with the EPEL packages already included. I'm not sure if their DAAs have been made aware. For better or worse I think they just aren't telling them this level of detail.
Thanks, --Spencer
Thanks for helping me learn more about this Spencer!
Dave
On Wednesday, March 14, 2012 02:59:30 PM Spencer R. Shimko wrote:
Jeff and I have been discussing this and I think that we will host the Puppet remediation content as part of the CLIP project. When/if the SCAP remediation standard is mature enough to handle the task we will convert the content and push it to SSG.
Simple question, what is SSG?
-Steve
On 3/14/12 9:36 PM, Steve Grubb wrote:
On Wednesday, March 14, 2012 02:59:30 PM Spencer R. Shimko wrote:
Jeff and I have been discussing this and I think that we will host the Puppet remediation content as part of the CLIP project. When/if the SCAP remediation standard is mature enough to handle the task we will convert the content and push it to SSG.
Simple question, what is SSG?
shorthand for SCAP Security Guide ;)
On Wednesday, March 14, 2012 01:43:05 PM Spencer R. Shimko wrote:
There are hard fixes and there are easy fixes. Let's look at one publicly available validated solution:
http://people.redhat.com/sgrubb/files/usgcb/rhel5/workstation-ks.cfg
NIST published an exact copy of that file. Look at what is being done to configure the system. The vast majority break down to this:
chkconfig chmod echo gconftool-2 mkdir rpm --import sed touch useradd
They are all one liners. Now if a package was required and it needing to be in a specific configuration and it drags in dependencies and they also have changes to their configs or perhaps have multilpe daemons which may or may not need to be enabled or disabled...we have a hard problem. In which case, maybe the solution is:
echo "Requirement xyz cannot be met by this script, please solve it manually. Do you understand? [y/n]" read ANS
That's a great idea. It would also be good to have a yum-like "-y" option for automation. One wouldn't want to run the remediation on 1000 systems interactively by hand.
Are you thinking of something significantly different from the secstate effort?
There is a lot of overlap between what is shipped with RHEL and secstate. We have had teleconferences on combining codebases somewhat, but that was a long time ago. We can restart that discussion if you want, but not on this mail list.
-Steve
On 3/14/12 9:33 PM, "Steve Grubb" sgrubb@redhat.com wrote:
On Wednesday, March 14, 2012 01:43:05 PM Spencer R. Shimko wrote:
There are hard fixes and there are easy fixes. Let's look at one publicly available validated solution:
http://people.redhat.com/sgrubb/files/usgcb/rhel5/workstation-ks.cfg
NIST published an exact copy of that file. Look at what is being done to configure the system. The vast majority break down to this:
chkconfig chmod echo gconftool-2 mkdir rpm --import sed touch useradd
They are all one liners. Now if a package was required and it needing to be in a specific configuration and it drags in dependencies and they also have changes to their configs or perhaps have multilpe daemons which may or may not need to be enabled or disabled...we have a hard problem. In which case, maybe the solution is:
echo "Requirement xyz cannot be met by this script, please solve it manually. Do you understand? [y/n]" read ANS
That's a great idea. It would also be good to have a yum-like "-y" option for automation. One wouldn't want to run the remediation on
1000
systems interactively by hand.
Are you thinking of something significantly different from the secstate effort?
There is a lot of overlap between what is shipped with RHEL and secstate. We have had teleconferences on combining codebases somewhat, but that was a long time ago. We can restart that discussion if you want, but not on this mail list.
Sounds good. We'll sync up separately.
I think the topic at-hand focuses on requirement content and remediation content - not the tools. As of right now I think this list is the best place to have those conversations. However if the general sentiment of the list is that remediation needs to be discussed elsewhere (since it won't be SCAP) I'll happily move it to the CLIP mailing list.
Thanks, --Spencer
-Steve
On Thursday, March 15, 2012 09:10:23 AM Spencer R. Shimko wrote:
Are you thinking of something significantly different from the secstate effort?
There is a lot of overlap between what is shipped with RHEL and secstate. We have had teleconferences on combining codebases somewhat, but that was a long time ago. We can restart that discussion if you want, but not on this mail list.
Sounds good. We'll sync up separately.
I think the topic at-hand focuses on requirement content and remediation content - not the tools.
I thought secstate was a tool and not content. Is there more to secstate than code? I might have missed that.
As of right now I think this list is the best place to have those conversations.
For content, sure.
However if the general sentiment of the list is that remediation needs to be discussed elsewhere (since it won't be SCAP) I'll happily move it to the CLIP mailing list.
Is that where you discuss the secstate code? I was thinking of the openscap mail list which is where all the previous discussion of secstate/openscap code merging occurred. :)
-Steve
On 3/15/12 9:32 AM, "Steve Grubb" sgrubb@redhat.com wrote:
On Thursday, March 15, 2012 09:10:23 AM Spencer R. Shimko wrote:
Are you thinking of something significantly different from the
secstate
effort?
There is a lot of overlap between what is shipped with RHEL and
secstate.
We have had teleconferences on combining codebases somewhat, but that was
a
long time ago. We can restart that discussion if you want, but not on this mail list.
Sounds good. We'll sync up separately.
I think the topic at-hand focuses on requirement content and remediation content - not the tools.
I thought secstate was a tool and not content. Is there more to secstate than code? I might have missed that.
You are in correct regarding sec state being a tool. However, in the midst of a conversation about content a question was asked about a tool. I responded by providing a link to the tool. The details of that tool should definitely be discussed on the OpenSCAP list (as you mention below). But I digress because this I think we are going down a rabbit hole.
As of right now I think this list is the best place to have those conversations.
For content, sure.
Even for puppet content? While I would really like to get it into a SCAP remediation standard it will be in Puppet for now. I know there has been movement towards BASH scripts for the content and honestly the content we written in the past was basically BASH scripts wrapped in a Puppet module. This time around we're using Augeas which I hope will allow us to develop more robust content with far fewer BASH scripts wrapped in Puppet. Thoughts?
I guess the real question here is if we should ignore the fact that it isn't in a SCAP standard and push the Puppet-based remediation content into SSG. I would really prefer this approach but I completely understand if the SSG community doesn't want to start cramming non-SCAP content in SSG's git repo.
However if the general sentiment of the list is that remediation needs to be discussed elsewhere (since it won't be SCAP) I'll happily move it to the CLIP mailing list.
Is that where you discuss the secstate code? I was thinking of the openscap mail list which is where all the previous discussion of secstate/openscap code merging occurred. :)
Heh I think I left out a critical word up there :P Should have read "remediation *content* could be discussed on the CLIP list." The rationale being that we have hosted puppet remediation content there for years and distributed it as part of CLIP.
Thanks, --Spencer
-Steve
On Thursday, March 15, 2012 10:14:46 AM Spencer R. Shimko wrote:
As of right now I think this list is the best place to have those conversations.
For content, sure.
Even for puppet content? While I would really like to get it into a SCAP remediation standard it will be in Puppet for now. I know there has been movement towards BASH scripts for the content and honestly the content we written in the past was basically BASH scripts wrapped in a Puppet module. This time around we're using Augeas which I hope will allow us to develop more robust content with far fewer BASH scripts wrapped in Puppet. Thoughts?
One of the goals I have in mind is being able to take an XCCDF file and run it through oscap to generate a fix. Then slap on a begining section that defines a few global settings that anaconda needs and then we have a kickstart script. Its possible to do this because the basic commands are present. But if you get too far from that using augeas, for example, then the command might not exist prior to install. I think busybox has the commands that are using during kickstart.
I guess the real question here is if we should ignore the fact that it isn't in a SCAP standard and push the Puppet-based remediation content into SSG. I would really prefer this approach but I completely understand if the SSG community doesn't want to start cramming non-SCAP content in SSG's git repo.
I'd like to think both can be done. But maybe not. Managing a system by puppet is very different than use cases I am considering. If you ran a scan and found something wrong, wouldn't you need to remediate the repository and push the changes to the system being scanned? Which is a whole kettle of fish different than what I was thinking of.
-Steve
On 3/15/12 1:42 PM, "Steve Grubb" sgrubb@redhat.com wrote:
On Thursday, March 15, 2012 10:14:46 AM Spencer R. Shimko wrote:
As of right now I think this list is the best place to have those conversations.
For content, sure.
Even for puppet content? While I would really like to get it into a SCAP remediation standard it will be in Puppet for now. I know there has been movement towards BASH scripts for the content and honestly the content we written in the past was basically BASH scripts wrapped in a Puppet module. This time around we're using Augeas which I hope will allow us to develop more robust content with far fewer BASH scripts wrapped in Puppet. Thoughts?
One of the goals I have in mind is being able to take an XCCDF file and run it through oscap to generate a fix.
Do you mean OVAL? I'm not sure how XCCDF can be used to accomplish this.
Then slap on a begining section that defines a few global settings that anaconda needs and then we have a kickstart script.
Now you lost me. Why is anaconda part and parcel to the end solution? Or is this for integration into Satellite?
Its possible to do this because the basic commands are present. But if you get too far from that using augeas, for example, then the command might not exist prior to install. I think busybox has the commands that are using during kickstart.
Is this based on the assumption that the fixes will be applied in a spec %post and not a ks %post? If so, why is that desirable? Is there an issue with doing this in %post as opposed to anaconda "proper"?
I guess the real question here is if we should ignore the fact that it isn't in a SCAP standard and push the Puppet-based remediation content into SSG. I would really prefer this approach but I completely understand if the SSG community doesn't want to start cramming non-SCAP content in SSG's git repo.
I'd like to think both can be done. But maybe not. Managing a system by puppet is very different than use cases I am considering. If you ran a scan and found something wrong, wouldn't you need to remediate the repository and push the changes to the system being scanned?
Ah is this coming from the thought of using Puppet Master (puppet server)? While we hope to support that eventually as it is being adopted in some environments right now we just want to run it locally. Install the content in an RPM containing content, run puppet in a %post to remediate. If necessary update puppet content and re-run locally. We aren't to the point of using the puppet master model.
Which reminds me - the first step down this path is to ensure the generated remediation content can be reliably re-applied (e.g. Running it twice in a row won't break things). Then we are closer to integrating into the full Puppet model including Puppet master.
Thanks, --Spencer
Which is a whole kettle of fish different than what I was thinking of.
-Steve
On Thursday, March 15, 2012 01:59:25 PM Spencer R. Shimko wrote:
Then slap on a begining section that defines a few global settings that anaconda needs and then we have a kickstart script.
Now you lost me. Why is anaconda part and parcel to the end solution? Or is this for integration into Satellite?
No. There are 2 kinds of system. The ones running and the ones needing to be installed. The ones needing to be installed can be kickstarted into the correct configuration from the beginning. Then its easy for a content developer to go through the guide, make some choices, save, and then run the oscap tool to make the fix script. Then you just add some preample stuff and you have a golden master for deployments.
We use kickstart for many things, like the livecd creator and the appliance creator. So, its really the ubiquitous file for system creation on RHEL. I'd like to see as many uses enabled as possible. I'm also thinking of this guide being used for other security purposes than government security. Like PCI-DSS where they may be making a minimal system to be a database server.
Its possible to do this because the basic commands are present. But if you get too far from that using augeas, for example, then the command might not exist prior to install. I think busybox has the commands that are using during kickstart.
Is this based on the assumption that the fixes will be applied in a spec %post and not a ks %post?
No. I'd have to see it work. But in the appliance situation they want a minimal system. So, the common denominator is shell and busybox.
If so, why is that desirable? Is there an issue with doing this in %post as opposed to anaconda "proper"?
I guess the real question here is if we should ignore the fact that it isn't in a SCAP standard and push the Puppet-based remediation content into SSG. I would really prefer this approach but I completely
understand
if the SSG community doesn't want to start cramming non-SCAP content in SSG's git repo.
I'd like to think both can be done. But maybe not. Managing a system by puppet is very different than use cases I am considering. If you ran a scan and found something wrong, wouldn't you need to remediate the repository and push the changes to the system being scanned?
Ah is this coming from the thought of using Puppet Master (puppet server)?
Yeah.
-Steve
On 3/16/12 12:47 PM, "Steve Grubb" sgrubb@redhat.com wrote:
Its possible to do this because the basic commands are present. But if you get too far from that using augeas, for example, then the command might not
exist
prior to install. I think busybox has the commands that are using during kickstart.
Is this based on the assumption that the fixes will be applied in a spec %post and not a ks %post?
No. I'd have to see it work. But in the appliance situation they want a minimal system. So, the common denominator is shell and busybox.
So all we have to do is get Ruby, Puppet, and Augeas in busy box right? Or perhaps just switch RPM's baked-in Lua interpreter to Ruby. ;)
Our experiences developing appliances based on Red Hat leads me to believe that sticking to the least common denominator is not appropriate approach. We tried this for years before switching to Puppet. Add the package you need to leverage to the packages list, e.g. Puppet, then remove it at the end of %post. Hacking around in shell scripts is far from a robust solution to t‡he problem. Of course this doesn't help at run-time but our customers have totally different ideas about handling systems at run-time and tend to completely avoid changes once a system is deployed.
This triggers another thought though - how do you account for the deps for the shell scripts themselves? Granted most will be sed/awk/etc but once again this is an issue that increases the fragility of the shell script solution. Perhaps it can be solved by stating you can only use things in @Base and @Core but we intentionally don't leverage groups when building our solutions. At least with the pure Puppet/Augeas solution that isn't an issue.
--Spencer
-Steve
On 03/19/2012 02:45 PM, Spencer R. Shimko wrote:
On 3/16/12 12:47 PM, "Steve Grubb" sgrubb@redhat.com wrote:
Its possible to do this because the basic commands are present. But if you get too far from that using augeas, for example, then the command might not
exist
prior to install. I think busybox has the commands that are using during kickstart.
Is this based on the assumption that the fixes will be applied in a spec %post and not a ks %post?
No. I'd have to see it work. But in the appliance situation they want a minimal system. So, the common denominator is shell and busybox.
So all we have to do is get Ruby, Puppet, and Augeas in busy box right? Or perhaps just switch RPM's baked-in Lua interpreter to Ruby. ;)
What about small/embedded devices. Or some medical appliances with small memory, augeas is simply too heavy for them. So it boils down to shell or even C. (Maybe these devices are out of concern for this list. (?))
Our experiences developing appliances based on Red Hat leads me to believe that sticking to the least common denominator is not appropriate approach. We tried this for years before switching to Puppet. Add the package you need to leverage to the packages list, e.g. Puppet, then remove it at the end of %post. Hacking around in shell scripts is far from a robust solution to t‡he problem. Of course this doesn't help at run-time but our customers have totally different ideas about handling systems at run-time and tend to completely avoid changes once a system is deployed.
This triggers another thought though - how do you account for the deps for the shell scripts themselves? Granted most will be sed/awk/etc but once again this is an issue that increases the fragility of the shell script solution. Perhaps it can be solved by stating you can only use things in @Base and @Core but we intentionally don't leverage groups when building our solutions. At least with the pure Puppet/Augeas solution that isn't an issue.
--Spencer
-Steve
On 04/03/2012 05:38 AM, Simon Lukasik wrote:
On 03/19/2012 02:45 PM, Spencer R. Shimko wrote:
On 3/16/12 12:47 PM, "Steve Grubb" sgrubb@redhat.com wrote:
Its possible to do this because the basic commands are present. But if you get too far from that using augeas, for example, then the command might not
exist
prior to install. I think busybox has the commands that are using during kickstart.
Is this based on the assumption that the fixes will be applied in a spec %post and not a ks %post?
No. I'd have to see it work. But in the appliance situation they want a minimal system. So, the common denominator is shell and busybox.
So all we have to do is get Ruby, Puppet, and Augeas in busy box right? Or perhaps just switch RPM's baked-in Lua interpreter to Ruby. ;)
What about small/embedded devices. Or some medical appliances with small memory, augeas is simply too heavy for them. So it boils down to shell or even C. (Maybe these devices are out of concern for this list. (?))
My personal take on this (and it is in no way reflective of Red Hat/etc.) is that ideally tools like Aqueduct should support as many devices, low and high end as possible. Why? I noticed a lot of hospital equipment with network jacks that was being used to keep my kids alive and well when they were born. So on a purely selfish basis I'd like to ensure as much of our infrastructure is as robust as possible. Now the question is how far down do you go? An extreme example:
http://linux.slashdot.org/story/12/04/02/191203/gnulinux-running-on-an-8-bit...
I think in general a good compromise is bash based scripts, an embedded device with no shell would most likely require a custom solution any ways which is outside the remit of this project (at least for now). Bash is universal, relatively lightweight, and easy to work with. For devices incapable of supporting bash they'll either have to write their own tests in C/Java/whatever they are using or examine the device some other way (e.g. talk to the maker, examine source code, whatever).
TLDR: the bash method is probably sufficient to handle low level/embedded devices sanely, anything else just gets way to complicated to deal with.
(altering the subject appropriately)
What about small/embedded devices. Or some medical appliances with small memory, augeas is simply too heavy for them. So it boils down to shell or even C. (Maybe these devices are out of concern for this list. (?))
In fact this list is primarily concerned with security guidance and SCAP content. If a device can run oscap, it should be able to generate a report about the system's configuration (and whether this meets a compliance goal).
We wish to generally remain agnostic with regard to hardening/remediation resources. There is a variety of tools for managing/deploying systems and the most appropriate one varies by use case.
HOWEVER, we respect the utility of Bash as a lowest common denominator. In a recent meeting, it was decided to permit <fix> tags in scap-security-guide and for these to include Bash content.
It was left undecided whether these tags should be inlined with the other XCCDF content (in "shorthand" in src/input/services and src/input/system) or if they should be kept in a separate file or files (and then merged into the final XCCDF), perhaps linked by Rule id. The argument for keeping it separate is that some of the Bash content may turn into several lines, and separation may simplify matters. This may also be more consistent with the eventual form of proposed CRE content (http://scap.nist.gov/specifications/cre/).
In any event, the <fix> tags would be available as part of final XCCDF output, and would enable generation of some remediation resources directly from the SCAP content such as in http://dev.gentoo.org/~swift/docs/genoval.xml
Puppet is very compelling for certain use cases. A decision was also made to develop Puppet content elsewhere (and this would link to compliance items on scap-security-guide). It would simply be too much for one project/versioning system to handle SCAP content and Puppet modules. (It would also be out of scope. Well, even further out of scope than the Bash.)
The best way to express a linkage between the XCCDF Rules and Puppet modules is also somewhat of an open question. More information about the relationship between an XCCDF document and the remediation resources available for it may be helpful; the CRE draft from NIST/Mitre did not yet seem to concretely express what this would look like.
I guess the real question here is if we should ignore the fact that it isn't in a SCAP standard and push the Puppet-based remediation content into SSG. I would really prefer this approach but I completely understand if the SSG community doesn't want to start cramming non-SCAP content in SSG's git repo.
Yes. It remains possible for us to add non-SCAP stuff (as shorthand/macros we invent, and then transform out of the "final" SCAP-only content), but this is really not preferable.
I would like our outputs to be either: 1) in SCAP formats (with intended usage of the elements), if machine-consumable 2) in human-readable formats
To me, this means that the <fix> tags should only contain simple bash commands. Hopefully linkage to things like Puppet modules can be achieved in a manner that is
To that end, it is my intention to (at M.1 perhaps) declare Rule IDs frozen, so that any external tools which process results can have confidence that the world won't be shifting underneath them. I've renamed the subject line to match this thread.
I also haven't read the CRE draft (Dec 2011) published by NIST/Mitre yet. It may not relate to our short-term efforts, but we may want to keep it in mind.
___________________________ Jeffrey Blank 410-854-8675 Global Mitigations NSA Information Assurance
Hello,
My name is Francisco Slavin. I am working with Spencer Shimko on the CLIP update work. He is primarily concerned with the SCAP content itself; I am working on updates to the Secstate tool [1] in order to consume this content. I wanted to chime in here regarding the way Secstate handles remediation content to help inform a the discussion of how best to approach the assessment-remediation link.
When we initially developed Secstate, the way we linked XCCDF to remediation content was largely a proof-of-concept to show how the tool can integrate the find-and-fix process of security hardening. We did use the system attribute of the <fix> element to specify that this was being done with Puppet content, thusly: <fix system="urn:xccdf:fix:script:puppet">
With that in mind, the idea was to eventually support content types other than puppet (i.e. link in legacy bash scripts, or hook in to the developing standard remediation language when that matures). We used puppet for our example content because we had a set of puppet content already developed in CLIP, so it was an easy tie-in. We used JSON in the <fix> tag for convenience, and turned that in to External Variable files for use with Puppet. By doing this we were able to run just the segments of Puppet content pertinent to a specific fix, using Puppet as a direct remediation tool instead of its designed purpose of general system management.
With the current work to update Secstate (I will be posting an announcement to that list shortly as well), we would like to reconsider the way we approach the assessment-remediation link. The main goal of Secstate is to make it as easy as possible to automate the assessment and remediation of a system; with that in mind, we will support whatever approach the community settles on for this aspect of content authorship.
Thank you - Francisco Slavin
[1] Secstate tool -https://fedorahosted.org/secstate/
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Jeffrey Blank Sent: Friday, March 16, 2012 12:28 PM To: scap-security-guide@lists.fedorahosted.org Subject: interoperation with remediation capabilities
I guess the real question here is if we should ignore the fact that it isn't in a SCAP standard and push the Puppet-based remediation content into SSG. I would really prefer this approach but I completely understand if the SSG community doesn't want to start cramming non-SCAP content in SSG's git repo.
Yes. It remains possible for us to add non-SCAP stuff (as shorthand/macros we invent, and then transform out of the "final" SCAP-only content), but this is really not preferable.
I would like our outputs to be either: 1) in SCAP formats (with intended usage of the elements), if machine-consumable 2) in human-readable formats
To me, this means that the <fix> tags should only contain simple bash commands. Hopefully linkage to things like Puppet modules can be achieved in a manner that is
To that end, it is my intention to (at M.1 perhaps) declare Rule IDs frozen, so that any external tools which process results can have confidence that the world won't be shifting underneath them. I've renamed the subject line to match this thread.
I also haven't read the CRE draft (Dec 2011) published by NIST/Mitre yet. It may not relate to our short-term efforts, but we may want to keep it in mind.
___________________________ Jeffrey Blank 410-854-8675 Global Mitigations NSA Information Assurance _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
On 3/16/12 6:24 PM, Francisco Slavin wrote:
Hello,
My name is Francisco Slavin. I am working with Spencer Shimko on the CLIP update work. He is primarily concerned with the SCAP content itself; I am working on updates to the Secstate tool [1] in order to consume this content. I wanted to chime in here regarding the way Secstate handles remediation content to help inform a the discussion of how best to approach the assessment-remediation link.
First, welcome! Really looking forward to seeing how you progress with integrating SSG into secstate!
When we initially developed Secstate, the way we linked XCCDF to remediation content was largely a proof-of-concept to show how the tool can integrate the find-and-fix process of security hardening. We did use the system attribute of the<fix> element to specify that this was being done with Puppet content, thusly:
<fix system="urn:xccdf:fix:script:puppet">
With that in mind, the idea was to eventually support content types other than puppet (i.e. link in legacy bash scripts, or hook in to the developing standard remediation language when that matures). We used puppet for our example content because we had a set of puppet content already developed in CLIP, so it was an easy tie-in. We used JSON in the<fix> tag for convenience, and turned that in to External Variable files for use with Puppet. By doing this we were able to run just the segments of Puppet content pertinent to a specific fix, using Puppet as a direct remediation tool instead of its designed purpose of general system management.
With the current work to update Secstate (I will be posting an announcement to that list shortly as well), we would like to reconsider the way we approach the assessment-remediation link. The main goal of Secstate is to make it as easy as possible to automate the assessment and remediation of a system; with that in mind, we will support whatever approach the community settles on for this aspect of content authorship.
In the upcoming weeks we'll be dropping a "alpha" release which contains base prose and some OVAL content. As we finalize the OVAL content I'd be highly interested in working with you to incorporate the <fix>'s you've been using and seeing what happens.
----- Original Message -----
On 3/13/12 9:44 PM, Steve Grubb wrote:
On Tuesday, March 13, 2012 07:37:07 PM Jeffrey Blank wrote:
A nicely loaded question.
As you've noticed, we don't have any<fix> tags. Such commands, when available, are just in the<description> or possibly <rationale>, and marked up with xhtml.
I also might expect there to be plenty of<Rule>s which simply won't have<fix> tags (such as edits to configuration files like pam.d/system-auth or sshd_config, or disk partitioning instructions). On the plus side, it would obviously be a cheap/easy way to annotate remediation instructions. On the minus side, I see it as leading to sed/awk in some of our output documents, and think this will make them less approachable/comprehensible. (I'm certainly fine with it being there, and hidden.)
Is there a project/effort/output which would benefit from<fix> tags?
Yes. openscap can generate shell scripts from<fix> tags. The gentoo demo shows this. The aqueduct project is creating remediation scripts in shell. So, it sounds like we ought to work towards one document with guidance, check, and fix so that we can make remediation easy.
FWIW, a big +1 to this.
There are some fixes that are hard. I'd like to say we should incorprate the easy ones and identify the hard ones. Whene we have several of these, then we can start looking for how to solve the hard problems.
I'm not to concerned about the hard fixes, largely as they've already been addressed through CLIP and/or Aqueduct. For example, DoDIIS open sourced their baseline (accredited to PL3) and we can pull a good bit from that.
Note that Aqueduct didn't address many of the hard fixes depending upon how you define hard.
For instance, we do what we can via automated remediation (prod) and save the rest for manual checks (manual-checks)...
http://svn.fedorahosted.org/svn/aqueduct/trunk/compliance/Bash/STIG/rhel-5-b...
If you want, you can poke around the prod directory to see how we do the remediation for each STIG configuration element. One design goal is to allow the script to be run multiple times without making things crufty. This makes the scripts more complex, but the benefit is that they are smarter.
In my mind, these scripts look a lot like what /could/ be output from oscap using <fix> tags. I wonder if review of the Aqueduct content as examples could help ease the addition of <fix> content in SSG?
Side note: We made the decision for the time being to use bash instead of Puppet since not all DAAs allow code from community supported sources (i.e., Puppet from EPEL). As Red Hat's next generation systems management tools may include general commercial support for Puppet, Aqueduct will re-evaluate its position and act accordingly.
Good discussion!
Dave
scap-security-guide@lists.fedorahosted.org
-
David Egts -
Francisco Slavin -
Jeffrey Blank -
Kevin Spargur -
Kurt Seifried -
Shawn Wells -
Spencer R. Shimko -
Steve Grubb -
Šimon Lukašík