On 3/29/13 9:07 AM, Matt Micene wrote: 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. 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.

Shawn, I am not as familiar with xmldsig-core or TMSAD but have you consider the “Trust Model for Security Automation Data”. It seems to leverage xmldsig-core and is intended for SCAP. Link to http://csrc.nist.gov/publications/nistir/ir7802/NISTIR-7802.pdf http://scap.nist.gov/specifications/tmsad/ Thanks. -ln From: scap-security-guide-bounces(a)lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Matt Micene Sent: Friday, March 29, 2013 1:55 PM To: scap-security-guide(a)lists.fedorahosted.org Subject: RE: Signed content purpose question Thanks for the link, didn’t find that in the archives. Using XML Signature simplifies things actually. It is possible to sign part of a document according to the standard (one or more resources). It should be possible to deliver signed content that can be locally modified with an extended profile without affecting the signature. Management and verification of the locally modified content would still be separate, but you could verify the DISA and local signatures. Matt From: scap-security-guide-bounces(a)lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Shawn Wells Sent: Friday, March 29, 2013 1:28 PM To: scap-security-guide(a)lists.fedorahosted.org Subject: Re: Signed content purpose question 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> "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.