Subject: Re: [sacm] SCAP Specifications related to the SACM Information Model (was RE: information model)

From: [email-masked]
Date: Thu, 20 Nov 2014 21:19:49 -0600 (CST)

David and all:

The SCAP specifications have no private intellectual claims.

These open characteristic have high appeal to security-minded organizations and security tool companies.

David Oliva

On 11/18/14, David Harrington<[email-masked]> wrote:

are any of these encumbered by intellectual property claims, or other restrictions?

David Harrington
[email-masked]

On Nov 18, 2014, at 8:25 PM, Waltermire, David A. <[email-masked]> wrote:

> XCCDF and OVAL are part of the SCAP collection of specifications, many of which should be considered by SACM. These specifications are implemented by a number of commercial and open source products and are in use internationally.
>
> Some work has been done to transport SCAP information over IETF NEA/TCG TNC protocols:
>
> http://www.trustedcomputinggroup.org/resources/tnc_scap_messages_for_ifm
>
> The following is a quick summary of the SCAP specifications found here: http://scap.nist.gov/revision/1.2/.
>
> Much of this is also discussed in draft-wandw-sacm-information-model-00 in section 11.
>
> Data Models:
>
> - The Extensible Configuration Checklist Description Format (XCCDF) 1.2 - A checklist data model and reporting format (also published as ISO/IEC 18180).
> - Open Vulnerability and Assessment Language (OVAL) 5.10 - A number of specifications supporting assessment evaluation guidance, posture collection guidance, posture collection results, and evaluation results
> - Asset Identification 1.1 - A data model for expressing identifying information for different types of assets
> - Asset Reporting Format (ARF) 1.1 - A data model for associating any arbitrary information with one or more identified assets
>
> Asset Identification was posted as I/D a while back as draft-montville-sacm-asset-identification-00.
>
> Identifier Formats:
>
> - Common Configuration Enumeration (CCE) 5 - Identification of configuration issues
> - Common Vulnerabilities and Exposures (CVE) - A format for identifying vulnerability issues (typically software flaws)
> - Common Platform Enumeration (CPE) 2.3 - A number of specifications supporting identification of products and statements of applicability to products
>
> An overview of CVE and CCE was posted as an I/D as draft-landfield-scap-naming-00.
>
> Scoring systems:
>
> - Common Vulnerability Scoring System (CVSS) v2 - Attributes for scoring the relative impact and exploitability of vulnerabilities
> - Common Configuration Scoring System (CCSS) 1.0 - Attributes for scoring the relative impact and exploitability of mis-configurations
>
> Other:
>
> - Trust Model for Security Automation Data 1.0 - Guidance for applying XML digital signature to SCAP content
>
> Another SCAP-related specification is the Asset Summary Reporting (ASR) Format which was originally published as NISTIR 7848. This data format can be used to exchange summary information or metrics pertaining to a set of assets. It may be useful for use as a reporting format. This specification was posted as an I/D as draft-davidson-sacm-asr-00.
>
> Additionally, an alternative to software identification is Software Identification (SWID) tags defined by ISO/IEC 19770-2. This specification addresses some of the capabilities provided by CPE (above). There is ongoing work to extend the CPE Applicability Language to add support for SWID tags. IMHO, the use of SWID is worthwhile to discuss in SACM.
>
> There has also been some work on transporting SWID tags over IETF NEA/TCG TNC protocols:
>
> http://www.trustedcomputinggroup.org/resources/tnc_swid_messages_and_attributes_for_ifm_specification
>
> Thanks,
> Dave
>
> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
> Sent: Monday, November 17, 2014 12:27 PM
> To: Chris Inacio; [email-masked]
> Subject: Re: [sacm] information model
>
>
>
> On 11/15/2014 11:00 PM, Chris Inacio wrote:
>>
>>
>> I’ve been thinking a bit harder about the information model and where we stand as a group. So I have a “lay your cards” on the table questions for the group: (1) I believe that various participants have some type of data model that is envisioned to be supported by SACM. So, the question, what data format do you want included in the SACM system? What role do you expect that data format to provide?
>>
>>
>>
>> (2) Second question: What other protocols/standards do you expect SACM to build upon, leverage, or work in parallel with? (In other words, what would you say is a solved problem by using already standardized X, Y, or Z that will narrow the scope of SACM?) I expect NEA to show up here, and to provide a certain set of capabilities.
>
>
> To put it simply, I haven't seen any standards that are better suited to this purpose than the combination of XCCDF and OVAL.
>
> And that also determines the answer to your first question.
>
>
>
>>
>>
>> My follow on to this stuff will hopefully to think more clearly about
>> the information model. The nice thing about working for a university,
>> I don’t particularly have any cards to lay on the table here. I don’t
>> have any expectations for question 1 or 2. But I have been thinking
>> about the various possibilities for an information model and the
>> negotiation capabilities. Right now, my personal feeling is that the
>> SACM protocol is really a wrapper / negotiation protocol that allows
>> disparate systems to decide how to talk - BUT it leaves the giant
>> mandatory to implement hanging over our heads. (The wrapper would
>> allow all the proxy/security/auth/etc. to happen even with protocols /
>> data formats that don’t include that notion. That said, this is very
>> far from my first preference in design.) Secondly, I’m mostly opposed
>> to a strict graph model. I think you can take the nature of the data
>> (at least as I see it) and turn it into a directed graph – but I’m not
>> in favor of
> a model that would require a graph representation in order to function.
>>
>>
>> --
>> Chris Inacio
>> [email-masked]
>>
>>
>>
>> _______________________________________________
>> sacm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sacm
>>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

_______________________________________________
sacm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sacm

---

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 21 Nov 2014 07:10:15 -0600

I’m not sure that is true, David O.  OVAL is covered by trademark and potentially copyright, as are many of the other SCAP constituents.

However, we are not necessarily planning to take them under our wing.  In many cases I expect we will take lessons learned and apply them to SACM specifications, in which case intellectual property rights matter little, if at all.   The intellectual property rights that would be at play are not something that should prevent us from looking at and learning from the SCAP constituent specifications.

> On Nov 20, 2014, at 9:19 PM, [email-masked] wrote:
> 
>  
>  David and all:
>  
> On 11/18/14, David Harrington<[email-masked] <mailto:[email-masked]>> wrote:
>  
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> On Nov 18, 2014, at 8:25 PM, Waltermire, David A. <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > http://www.trustedcomputinggroup.org/resources/tnc_scap_messages_for_ifm <http://www.trustedcomputinggroup.org/resources/tnc_scap_messages_for_ifm>
> > 
> > The following is a quick summary of the SCAP specifications found here: http://scap.nist.gov/revision/1.2/. <http://scap.nist.gov/revision/1.2/>
> > 
> > http://www.trustedcomputinggroup.org/resources/tnc_swid_messages_and_attributes_for_ifm_specification <http://www.trustedcomputinggroup.org/resources/tnc_swid_messages_and_attributes_for_ifm_specification>
> > 
> > Thanks,
> > Dave
> > 
> > From: sacm [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Gunnar Engelbach
> > To: Chris Inacio; [email-masked] <mailto:[email-masked]>
> >> [email-masked] <mailto:[email-masked]>
> >> 
> >> 
> >> 
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> >> 
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>