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