On 08/07/2012 09:47 PM, Vincent Passaro wrote:
It’s sad to see DISA SCAP taking the community 3 steps forward 4 steps
back.
We now have more manual checks than when we were using the SRR’s and
no standardization or reporting format. These two things combined
make it difficult to use the SCAP since we now have to run the XCCDF /
OVAL checks, go back into the manual checks, figure out what wasn’t
addressed, and then do it manually.
This is in large part due to the absence of an generally accepted
evaluation scheme (a "check language" in SCAP parlance) that allowed the
use of scripting languages in a mechanized fashion (and no, I'm not
talking about evaluations that cannot be performed on the ToE: that's
what OCIL is for). OVAL is inadequately expressive to handle, easily if
at all, many desired evaluations. The SCAP community (minus me at least)
has for many years resisted the introduction of arbitrary scripting into
OVAL. The resistance occurs at the dogma or doctrine level, not at the
implementation level.
There are already people using scripting languages within the general
context of SCAP-like checklist documents. It works, and works well. See,
e.g., CIS XML content (available to CIS members only, unfortunately),
and Peter Vrabec's slides
<
http://people.redhat.com/pvrabec/openscap/openscap-aqueduct.pdf> from
the 20120512 Aqueduct community call. What's lacking is general assent
that scripting languages should be used, and a structure in which such
scripting languages can be expressed that is compatible with, e.g.,
XCCDF, as well as fostering uniformity of expression. I'd like to see at
least shell commands and possibly Python. The former is IMO a necessity;
most POSIX-like systems can be interrogated, and additionally
configured, using commands executed within the context of a shell, and a
shell is almost always present (not so for network gear and the like,
but that's an arena for separate discussions).
And yes, scripting will work for "remediation" as well.