On 3/29/13 9:07 AM, Matt Micene wrote:

A follow up from the SCAP workshops that Shawn and Jeff hosted this week
(great job guys) on the topic of signed content.

What is the intent for having DISA / NIST / AuthorityX signing SCAP
content for delivery?  Are people looking for full attestation or
validation?  Neither addresses the challenge of what to do with local
content for waivers, but each poses different options for the local
maintainer.  The tooling also has different challenges if there's a need
to validate a digital signature versus verifying a digest.

By creating signed datastreams, content authors allow consumers to verify the provenance of the content (e.g. validation) and if changes are made the signature invalidates (attestation).

The spec is here: http://www.w3.org/TR/xmldsig-core/

OpenSCAP announcement: https://www.redhat.com/archives/open-scap-list/2012-December/msg00000.html

You'll notice that OpenSCAP doesn't perform the signature validation itself. As we (the SSG project) haven't gone through signing the content yet I'm sure there is much to discover around operations on the content.

Disjointed ancillary thought, is there an include function in the XCCDF?
I haven't been able to find one in the spec so far but it could be
useful for local waiver overrides while preserving the official content.
There's an obvious issue (as I type this) that any sort of standard
include statement would allow someone to completely override policy for
a scan while still mimicking the appropriate results.  Having a
reporting tool that can do diffs of the results and the policy settings
could catch that, but that may not be sufficient for reporting or
detection time.

I'm not aware of anything at runtime.

In the code you can reference other profiles through XCCDF "extends." For example, if you're a shop which follows the STIG, but wants to make local changes, you could create your own XCCDF profile like so:

<Profile id="my_custom_rule_selection" extends="stig-rhel6-server" xmlns="http://checklists.nist.gov/xccdf/1.1" >

Any variables you set will overwrite those within stig-rhel6-server, and rules you deselect will have "selected=false." Theoretically users would be able to show their custom profile to security teams to show what they changed away from the STIG defaults.