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