4:59 p.m.
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?
--
___________________________
Jeffrey Blank
410-854-8675
Global Mitigations
NSA Information Assurance
9:26 p.m.
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:
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)
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)
8:33 a.m.
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:
>
> 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)
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)
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/scap-security-guide
6:37 p.m.
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
8:44 p.m.
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
8:52 p.m.
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.
11:41 p.m.
On 3/13/12 9:52 PM, "Shawn Wells" <shawn(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/scap-security-guide
8 a.m.
On Wednesday, March 14, 2012 12:41:51 AM Spencer R. Shimko wrote:
On 3/13/12 9:52 PM, "Shawn Wells" <shawn(a)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:
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(a)lists.fedorahosted.org
>https://fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/scap-security-guide
11:49 a.m.
----- 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(a)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:
> 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(a)lists.fedorahosted.org
> >https://fedorahosted.org/mailman/listinfo/scap-security-guide
>
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/scap-security-guide
--
David D. Egts, RHCA, RHCSS #805007796228001
Principal Architect, Red Hat, Inc.
12:43 p.m.
On 3/14/12 12:49 PM, "David Egts" <degts(a)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(a)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:
> > 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(a)lists.fedorahosted.org
> > >https://fedorahosted.org/mailman/listinfo/scap-security-guide
> >
> > _______________________________________________
> > scap-security-guide mailing list
> > scap-security-guide(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/scap-security-guide
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/scap-security-guide
1:23 p.m.
----- Original Message -----
On 3/14/12 12:49 PM, "David Egts" <degts(a)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(a)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/
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:
>> > 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(a)lists.fedorahosted.org
>> > >https://fedorahosted.org/mailman/listinfo/scap-security-guide
>> >
>> > _______________________________________________
>> > scap-security-guide mailing list
>> > scap-security-guide(a)lists.fedorahosted.org
>> > https://fedorahosted.org/mailman/listinfo/scap-security-guide
>> _______________________________________________
>> scap-security-guide mailing list
>> scap-security-guide(a)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(a)lists.fedorahosted.org
>https://fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/scap-security-guide
--
David D. Egts, RHCA, RHCSS #805007796228001
Principal Architect, Red Hat, Inc.
1:46 p.m.
On 03/14/2012 02:23 PM, David Egts wrote:
----- Original Message -----
> On 3/14/12 12:49 PM, "David Egts"<degts(a)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(a)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/
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:
>>>> 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(a)lists.fedorahosted.org
>>>>> https://fedorahosted.org/mailman/listinfo/scap-security-guide
>>>> _______________________________________________
>>>> scap-security-guide mailing list
>>>> scap-security-guide(a)lists.fedorahosted.org
>>>> https://fedorahosted.org/mailman/listinfo/scap-security-guide
>>> _______________________________________________
>>> scap-security-guide mailing list
>>> scap-security-guide(a)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(a)lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/scap-security-guide
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/scap-security-guide
>
2:28 p.m.
On 3/14/12 2:46 PM, "Kevin Spargur" <kspargur(a)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
1:59 p.m.
On 3/14/12 2:23 PM, "David Egts" <degts(a)redhat.com> wrote:
----- Original Message -----
> On 3/14/12 12:49 PM, "David Egts" <degts(a)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(a)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?
>
> https://fedorahosted.org/secstate/
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
8:36 p.m.
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
10:31 p.m.
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 ;)
8:33 p.m.
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
8:10 a.m.
On 3/14/12 9:33 PM, "Steve Grubb" <sgrubb(a)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
8:32 a.m.
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
9:14 a.m.
On 3/15/12 9:32 AM, "Steve Grubb" <sgrubb(a)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
12:42 p.m.
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
12:59 p.m.
On 3/15/12 1:42 PM, "Steve Grubb" <sgrubb(a)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
11:47 a.m.
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
8:45 a.m.
On 3/16/12 12:47 PM, "Steve Grubb" <sgrubb(a)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
6:38 a.m.
On 03/19/2012 02:45 PM, Spencer R. Shimko wrote:
On 3/16/12 12:47 PM, "Steve Grubb"
<sgrubb(a)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
11:17 a.m.
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(a)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-...
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.
--
Kurt Seifried Red Hat Security Response Team (SRT)
11:55 a.m.
New subject: note on project scope, remediation relationship
(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.
11:27 a.m.
New 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
5:24 p.m.
New subject: interoperation with remediation capabilities
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(a)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(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/scap-security-guide
9:13 p.m.
New subject: interoperation with remediation capabilities
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.
11:38 a.m.
----- 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-...
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
--
David D. Egts, RHCA, RHCSS #805007796228001
Principal Architect, Red Hat, Inc.
4403
days inactive
4425
days old
scap-security-guide@lists.fedorahosted.org
31 comments
9 participants
participants (9)
-
David Egts -
Francisco Slavin -
Jeffrey Blank -
Kevin Spargur -
Kurt Seifried -
Shawn Wells -
Spencer R. Shimko -
Steve Grubb -
Šimon Lukašík