On 03/26/2013 05:26 PM, Truhn, Chad M CTR NSWCDD, CXA30 wrote:
I don't know 5% of what you guys do when it comes to SCAP and the
way the content is manipulated, but one thing stuck out to me.
> The fix scripts should not be written to check system state at the
> granularity targeted by OVAL checks. But they should still be doing
> basic error checking and error handling.
While I think I agree with this as an idea, I think this may be somewhat more complicated
than that. When the OVAL check fails, it fails in a binary form (pass/fail). I would
argue that the remediation content will have to do a more granular check in some cases
where the current content may not be so straightforward. For example, PAM parses it's
configuration files in a specific order and you can't just stick the required line in
there anywhere. In my experience the check just looks for a regex match and gives a
pass/fail from that. The remediation content will have to "understand" the
proper layout of the file and handle variances within that file. This example is pretty
simple, but I hope I am getting across the point I am trying to make.
I agree. Scripts can be more complicated. (And in fact it *has to be*
complicated, because configuration is harder problem than assessment).
I honestly didn't know that OpenSCAP had the ability to do remediation
at all, and I'm in the process of trying to understand how that works
and reading the 7670 document, but from the OpenSCAP Remediation page
that Simon Lukasik so graciously wrote up I get the idea of how it all
ties together. That leads me to a question about the selective ability
to remediate findings though. Using that information alone it appears
that you can either a) wholesale remediate all failed findings right when
they are found using the 'eval' parameter or b) do the 'Offline'
remediation that does the same thing, but just gives you a chance to
see what needs to be changed first. Is it possible to add an option
to exclude or include particular things to be remediated while still
having them checked?
Yes, there is an option for selectively omit remediation of certain
rule. Though, it is not easy/nice yet. Today, You can either:
(*) Remove the fix element from that source XCCDF document
(*) Create new (inherited) profile for this special machine
which has the given Rule unselected. This option is getting
easier, as Martin has recently added tailoring file support
into OpenSCAP -> thus your new profile may be in external file.
(*) Use CPE identifier assigned to the fix. If the CPE does not match
on given system, the fix will not be executed.
Moreover, I can think of having some file like /etc/NONCRITICAL on
all my non critical systems. And then having CPE identifier which
matches this exact file. That way, no fix (with this CPE) will be
executed unless the machine has /etc/NONCRITICAL.
(*) Use offline remediation and proceed as described at
https://www.redhat.com/archives/open-scap-list/2013-March/msg00016.html
(*) Wait for new SCAP-Workbench, which should allow users to select
fix elements in GUI.
(*) File a feature request against OpenSCAP for interactive
(like: Yes/No/Quit) remediation.
On the other hand, I think that scenario of having a fix element for the
Rule and having the Rule failing on a machine is somewhat schizophrenic.
I either have a correct policy or not. I either want this exact machine
compliant or not. I either want it to be remediated automatically or
not. I either want to use some exact fix script or not.
Without thinking about it too much I can't think
of a good way to do that without it being cumbersome. But I can say
that in my years working with security measures I have never been able
to take the 'recommended' solution and fit 100% of it to my system.
There are always outliers.
I understand this. What of the above mentioned approaches would be the
viable for You? Or can You see any other?
Thanks,
--
Simon Lukasik
Security Technologies