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