----- Original Message -----
On Wednesday, March 14, 2012 12:41:51 AM Spencer R. Shimko wrote:
On 3/13/12 9:52 PM, "Shawn Wells" shawn@redhat.com wrote:
On 3/13/12 9:44 PM, Steve Grubb wrote:
On Tuesday, March 13, 2012 07:37:07 PM Jeffrey Blank wrote:
A nicely loaded question.
As you've noticed, we don't have any<fix> tags. Such commands, when available, are just in the<description> or
possibly
<rationale>, and marked up with xhtml.
I also might expect there to be plenty of<Rule>s which simply won't have<fix> tags (such as edits to configuration files like pam.d/system-auth or sshd_config, or disk partitioning
instructions).
On the plus side, it would obviously be a cheap/easy way to annotate remediation instructions. On the minus side, I see it as leading to sed/awk in some of our output documents, and think this will make
them
less approachable/comprehensible. (I'm certainly fine with it being there, and hidden.)
Is there a project/effort/output which would benefit from<fix>
tags?
Yes. openscap can generate shell scripts from<fix> tags. The gentoo
demo shows
this. The aqueduct project is creating remediation scripts in shell.
So, it
sounds like we ought to work towards one document with guidance, check,
and fix
so that we can make remediation easy.
FWIW, a big +1 to this.
I understand that we can generate whatever we want from the <fix> tags but I want to ensure the generated content is consumable by the larger community. Are the <fix> tags flexible enough to support the forward movement of system configuration tools?
I know the rest of this is long but bear with me here because, much like SCAP, there are a lot of relationships that must be addressed by a successful solution.
There are hard fixes and there are easy fixes. Let's look at one publicly available validated solution:
http://people.redhat.com/sgrubb/files/usgcb/rhel5/workstation-ks.cfg
NIST published an exact copy of that file. Look at what is being done to configure the system. The vast majority break down to this:
chkconfig chmod echo gconftool-2 mkdir rpm --import sed touch useradd
They are all one liners. Now if a package was required and it needing to be in a specific configuration and it drags in dependencies and they also have changes to their configs or perhaps have multilpe daemons which may or may not need to be enabled or disabled...we have a hard problem. In which case, maybe the solution is:
echo "Requirement xyz cannot be met by this script, please solve it manually. Do you understand? [y/n]" read ANS
That's a great idea. It would also be good to have a yum-like "-y" option for automation. One wouldn't want to run the remediation on 1000 systems interactively by hand.
I wonder if it would be good to have a to-do checklist / report at the end in say .csv? Do as much as possible in an automated way, and then have a to-do list that people can print out, check the box when done with an element, do the next one, etc.
Dave
And then when/if the remediation standards mature, we can address the hard problems. Just making the simple solutions available is a big first step in the right direction.
-Steve
While I would like to see a single source for all SCAP content, the mechanisms to address remediation under SCAP aren't mature. It has taken the Puppet/Augeas teams a lot of effort to get to the current state which can be leveraged to address remediation while SCAP-standard remediation matures. It may not be the ideal solution but it is a huge step in the right direction. I think the goal here, and I think this is what Steve is saying, should be to start implementing a binding between the XCCDF, OVAL, and remediation content. Of course this is supported by the defined standards but someone has to write the content to actually perform the binding.
As Jeff states, there are going to be gaps. There won't always be remediation content available for numerous reasons. We are trying to address part of that problem. Tresys is currently mapping several requirement sets to controls and implementation (DCID 6/3 PL4 High/High, CNSSI 1253, NIST 800.53). We are starting with the SNAC guide to provide the implementation guidance. Where necessary we are writing Puppet content to address controls and remediation. We are also writing OVAL content to complement and test the remediation content.
I would appreciate comments and feedback on the above but I'm really interested in knowing the community's opinion on how to handle binding XCCDF/OVAL to remediation in the short-term. The hope is that the remediation language will mature and the remediation content we are all working on now can be re-used in the future.
CLIP was developed to reduce the burden associated with creating a C&A'able solution based on Red Hat Enterprise Linux. This has been accomplished through configuration, customization of packages, and providing supporting evidence mapping the implementation into requirements and controls. We are now taking the next steps by:
- ensuring all targeted requirement sets are in XCCDF,
- ensuring the implementation guidance is available in a similar
format (SNAC->XCCDF), 3. filling the implementation documentation gaps found in #2 above (basically adding to SNAC guidance), 4. determining where OVAL content can test the implementation, 5. ensuring OVAL content is developed that addresses the gap identified in #4 above, 6. developing puppet content to address as many reqs and controls as we can.
As if there aren't enough goals described above - I think the pen-ultimate goal for reqs management from Tresys' upcoming XCCDF/OVAL contributions to scap-security-guide is to see SCAP content that can be consumed by developers, accreditors, and admins. We hope this binding will be flexible enough to facilitate tying the XCCDF to other types of content in the future, like OCIL.
Thanks, --Spencer
There are some fixes that are hard. I'd like to say we should
incorprate the easy
ones and identify the hard ones. Whene we have several of these, then
we can
start looking for how to solve the hard problems.
I'm not to concerned about the hard fixes, largely as they've already been addressed through CLIP and/or Aqueduct. For example, DoDIIS open sourced their baseline (accredited to PL3) and we can pull a good bit from that. _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide