note on project scope, remediation relationship

Jeffrey Blank blank at eclipse.ncsc.mil
Tue Apr 3 16:55:02 UTC 2012


(altering the subject appropriately)

> What about small/embedded devices. Or some medical appliances with small
> memory, augeas is simply too heavy for them. So it boils down to shell
> or even C. (Maybe these devices are out of concern for this list. (?))


In fact this list is primarily concerned with security guidance and SCAP 
content.  If a device can run oscap, it should be able to generate a 
report about the system's configuration (and whether this meets a 
compliance goal).

We wish to generally remain agnostic with regard to 
hardening/remediation resources.  There is a variety of tools for 
managing/deploying systems and the most appropriate one varies by use case.

HOWEVER, we respect the utility of Bash as a lowest common denominator. 
  In a recent meeting, it was decided to permit <fix> tags in 
scap-security-guide and for these to include Bash content.

It was left undecided whether these tags should be inlined with the 
other XCCDF content (in "shorthand" in src/input/services and 
src/input/system) or if they should be kept in a separate file or files 
(and then merged into the final XCCDF), perhaps linked by Rule id.  The 
argument for keeping it separate is that some of the Bash content may 
turn into several lines, and separation may simplify matters.  This may 
also be more consistent with the eventual form of proposed CRE content 
(http://scap.nist.gov/specifications/cre/).

In any event, the <fix> tags would be available as part of final XCCDF 
output, and would enable generation of some remediation resources 
directly from the SCAP content such as in
http://dev.gentoo.org/~swift/docs/genoval.xml

Puppet is very compelling for certain use cases.  A decision was also 
made to develop Puppet content elsewhere (and this would link to 
compliance items on scap-security-guide).  It would simply be too much 
for one project/versioning system to handle SCAP content and Puppet 
modules.   (It would also be out of scope.  Well, even further out of 
scope than the Bash.)

The best way to express a linkage between the XCCDF Rules and Puppet 
modules is also somewhat of an open question.  More information about 
the relationship between an XCCDF document and the remediation resources 
available for it may be helpful; the CRE draft from NIST/Mitre did not 
yet seem to concretely express what this would look like.


More information about the scap-security-guide mailing list