----- 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.