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

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 19 Nov 2014 01:25:17 +0000

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

---

From: David Harrington <[email-masked]>
Date: Tue, 18 Nov 2014 23:36:42 -0500

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

David Harrington
[email-masked]

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 19 Nov 2014 06:50:34 -0500

Hi Dave,

SWID is a minor contender in the software
tagging arena.  It would be also nice if the
somewhat closed activities relating to the
SWID ISO/IEC venue could be opened up and
the specifications made available.

There is also a much larger universe into which
SACM needs to be playing - even within the IETF.
A couple of handy diagrams are provided to help
assist in that mapping.  SACM's ultimate value
will be dependent on its larger involvements.
Toward this end, TC CYBER is publishing a "living"
Technical Report elaborating on the ecosystem.

best,
--tony

---

From: "Cheikes, Brant A." <[email-masked]>
Date: Wed, 19 Nov 2014 12:41:32 +0000

I don't understand the claim that SWID (aka ISO/IEC 19770-2) is a "minor contender" in the software tagging arena. What then are the "major contenders"? Speaking as the former moderator of the CPE project at MITRE, I don't consider CPE a satisfactory solution, and I'm quite confident there's a strong consensus to that effect among potential implementers in industry. The existing SWID specification, as well as the pending revision to it, addresses a wide range of use cases, and answers the question of how tags may be discovered on endpoints and related to the products they claim to identify and describe. While it is unfortunate that the ISO/IEC standards development process is less accessible than, say, the IETF's, it isn't particularly hard or expensive to obtain a copy of the specification. It just goes against the knee-jerk reaction that everything must be free.

/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S M300
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352 

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Tony Rutkowski
Sent: Wednesday, November 19, 2014 6:51 AM
To: Waltermire, David A.; 'Gunnar Engelbach'; Chris Inacio; [email-masked]
Subject: Re: [sacm] SCAP Specifications related to the SACM Information Model (was RE: information model)

Hi Dave,

SWID is a minor contender in the software tagging arena.  It would be also nice if the somewhat closed activities relating to the SWID ISO/IEC venue could be opened up and the specifications made available.

There is also a much larger universe into which SACM needs to be playing - even within the IETF.
A couple of handy diagrams are provided to help assist in that mapping.  SACM's ultimate value will be dependent on its larger involvements.
Toward this end, TC CYBER is publishing a "living"
Technical Report elaborating on the ecosystem.

best,
--tony

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 19 Nov 2014 13:57:59 -0500

Hi Brent,

Let me recount the basics and history.

SWID is (yet another) of the instantiations of a single
global registry solution to identify and authenticate
software objects.  Such singularities do not work and
are basically phantasies.  All the developers of software
will not use a common global registration solution.

3GPP - which is by any metric the world's largest standards
body with significant leverage - spent 18 months across three
standards committees contemplating the SWID challenge with
respect to software in the mobile infrastructure, and rejected
a common global registration scheme.  Instead, they wisely
developed a specification for Rel. 12 (the current mobile
infrastructure instantiation) that is basically a UUID based
signature that accommodates the real world.

There is a 30 year road littered with SWID attempts.  The
first significant one occurred in the mid-80s among the
OSI community that created the Object IDentifier (OID)
spec that was designed in part to deal with the SWID
problem.  See http://www.oid-info.com/  OIDs are still
used among some communities for this purpose, and
they are embedded in EVcerts used for software source
identification.  OIDs are even used in the IETF for several
purposes, including MIB identifiers. OIDs have also achieved
a kind of new lease on life with their instantiation in a
real-time DNS based resolver infrastructure (along with
Universal Product Codes - which are yet another SWID
solution).

Bob Kahn at CNRI developed another scheme known as
Digital Object Identifiers (DOIs) in the mid-90s and they
can even be found in some informational RFC's together
with his meta pointer platform, Handles.  Bob had the good
sense to realize that not everyone in the world would use
DOIs, and Handles became his solution to pointing to
everyone else.  His presentations on this subject can even
be found in a two day workshop earlier this week in Geneva.
See http://www.itu.int/en/ITU-T/C-I/Pages/WSHP_counterfeit.aspx

The largest and most successful "SWID" instantiations today are
those of Google and Apple in conjunction with their respective
OS platforms.  They have their own unique software/app
identifier systems.  Indeed, at the SWID session at the Baltimore
SCAP Conference two years ago where some presenters
attempted to sell the ISO/IEC SWID notion to attendees, a
representative of one of the major OS vendors suggested that
the presenter get real and they (the OS vendor) were not
changing.

The fact that 19770 is a product of ISO - one of the last
dinosaurs in the IT/telecom closed standards "publishing
for profit" business, doesn't help.  The scheme they are
using simply doesn't have viability in the real world, and
all the government project money thrown at it will not
change that.

--tony

---

From: "Watson, Kimberly" <[email-masked]>
Date: Wed, 19 Nov 2014 19:48:58 +0000

We are currently working on an informational document that associates the OVAL components with the SACM information model. the draft-wandw-sacm document was focused around the IM and had OVAL pieces and parts strewn through it...this will attempt to be more "OVAL-centric" so it is easy to see what components have some application to SACM requirements and how. We hope to have this posted and sent to the mailing list middle of next month.

The reason this is not a simple "OVAL does" conversation and is a "this part of OVAL can" conversation is because the A is for assessment.  The current language merges specifications or establishes relationships between elements that express collection guidance, evaluation guidance, collection results, and evaluation results. SACM has intentionally broken these apart and we need to see how much of the existing specification  can be "reused" or "leveraged".

--
Kim Watson
Office of Cybersecurity and Communications
Federal Network Resilience
Blackberry: (202) 494-2534

-----Original Message-----
From: Waltermire, David A. [mailto:[email-masked]] 
Sent: Tuesday, November 18, 2014 8:25 PM
To: 'Gunnar Engelbach'; Chris Inacio; [email-masked]
Subject: [sacm] SCAP Specifications related to the SACM Information Model (was RE: information model)

Data Models:

Identifier Formats:

Scoring systems:

Other:

Thanks,
Dave

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 19 Nov 2014 15:05:11 -0500

Here here, well stated.

But I will add that some vendors are making SWIDs available as part of 
their software distribution.  That's a trove of information is a simple 
to process format and, in the case of signed SWID identifiers, 
trustworthy.  So it makes sense to be able to take advantage of it.

That's not the same thing as saying it should be what is used by SACM. 
in fact, for the types of things needed to be accomplished by SACM, I 
see self-referential CPE identifiers as a better solution.

--gun

On 11/19/2014 1:57 PM, Tony Rutkowski wrote:
>> I don't understand the claim that SWID (aka ISO/IEC 19770-2) is a
>> "minor contender" in the software tagging arena. What then are the
>> "major contenders"? Speaking as the former moderator of the CPE
>> project at MITRE, I don't consider CPE a satisfactory solution, and
>> I'm quite confident there's a strong consensus to that effect among
>> potential implementers in industry. The existing SWID specification,
>> as well as the pending revision to it, addresses a wide range of use
>> cases, and answers the question of how tags may be discovered on
>> endpoints and related to the products they claim to identify and
>> describe. While it is unfortunate that the ISO/IEC standards
>> development process is less accessible than, say, the IETF's, it isn't
>> particularly hard or expensive to obtain a copy of the specification.
>> It just goes against the knee-jerk reaction that everything must be free.
>>
>> /Brant
>>
>> Brant A. Cheikes
>> The MITRE Corporation
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 19 Nov 2014 21:49:59 +0000

I agree with Tony's remarks about global registries or "singularities" do not work well. As an organization that has operated such a singularity for CPE, this approach doesn't scale well and shifts the normalization burden to a 3rd party which does not work in practice. Unlike CPE, ISO/IEC 19770-2 SWID tags do not require or need a global registry to operate. Each provider of software is responsible for maintaining their own collection of tags and the normalization of data within their collection. This is a very desirable property of the ISO/IEC 19770-2 standard.

I believe we will need to have a flexible method of using multiple software identification approaches to account for a number of current implementations and use cases.

Dave

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Wednesday, November 19, 2014 3:05 PM
To: [email-masked]; Cheikes, Brant A.; [email-masked]
Subject: Re: [sacm] SCAP Specifications related to the SACM Information Model (was RE: information model)

Here here, well stated.

But I will add that some vendors are making SWIDs available as part of their software distribution.  That's a trove of information is a simple to process format and, in the case of signed SWID identifiers, trustworthy.  So it makes sense to be able to take advantage of it.

That's not the same thing as saying it should be what is used by SACM. 
in fact, for the types of things needed to be accomplished by SACM, I see self-referential CPE identifiers as a better solution.

--gun

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 19 Nov 2014 17:12:39 -0500

Hi Dave,

SA3's spec has merit in this regard - as they sought
to accommodate all the varieties of software and
applications now resident within and external to
the global mobile infrastructure on user devices
They also spent some considerable time relatively
recently working this challenge.  And their specs
are open, freely available, well versioned, with
stable URLs for both the text and the structured
language versions.  They will also apparently be
using the spec for their current equivalent of
SACM - SCAS.

It would be nice if all the groups working on
the same problems could begin working together
better.  You have two NIST people at the SA3
meeting out in San Francisco this week, so that's
a start. :-)

--tony

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 19 Nov 2014 22:24:08 +0000

Can you provide a link to the specification you are referencing and any pointers to the relevant sections?

Thanks,
Dave

-----Original Message-----
From: Tony Rutkowski [mailto:[email-masked]] 
Sent: Wednesday, November 19, 2014 5:13 PM
To: Waltermire, David A.; Gunnar Engelbach; Cheikes, Brant A.; [email-masked]
Subject: Re: [sacm] SCAP Specifications related to the SACM Information Model (was RE: information model)

Hi Dave,

SA3's spec has merit in this regard - as they sought to accommodate all the varieties of software and applications now resident within and external to the global mobile infrastructure on user devices They also spent some considerable time relatively recently working this challenge.  And their specs are open, freely available, well versioned, with stable URLs for both the text and the structured language versions.  They will also apparently be using the spec for their current equivalent of SACM - SCAS.

It would be nice if all the groups working on the same problems could begin working together better.  You have two NIST people at the SA3 meeting out in San Francisco this week, so that's a start. :-)

--tony

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 19 Nov 2014 17:29:21 -0500

Considering for a moment just the usage of SWIDs for applicability 
checks, I'm just not seeing it.

Embedding a SWID XML document within another document as part of the 
applicability check is just a non-starter.  Particularly when you 
consider the need to have multiple entries.

So it would be done using the ID from the SWID.

But the ID from the SWID is just an arbitrary string*:  it doesn't mean 
anything until you resolve that ID to the SWID.  So you still have to do 
a lookup to make use of the SWID ID, so a repository containing that 
SWID ID needs to be available, and it needs to be the correct repository 
for that ID.

Sure, since the ID is just a string it can be formatted so that it 
contains descriptive information identifying the product -- just like 
CPE does.  But now it has the same problem with ambiguity that CPE does.

Also, for use in applicability checks, the SWID ID has to be known at 
the time the content is authored.  So content that relies on SWIDs as 
the applicability check can only be authored for software for which the 
SWIDs are already known.  This goes for any other identifier.

Which is why I prefer what I call self-referential applicability 
identifiers, which is how CPE is being used today (I'm not aware, in 
fact, of anybody that bothers to use the CPE dictionary).  In this usage 
the guidance contains evaluation code that is used to determine 
applicability and the result of this self-test is expressed as a string 
value.  Which happens to be formatted as a CPE identifier.

So, yeah, taking advantage of SWIDs makes sense.  But they don't have to 
be part of SACM for that to happen.

* Nearly arbitrary:  it must be unique.

---

From: Simon Lukasik <[email-masked]>
Date: Wed, 19 Nov 2014 23:54:07 +0100

Hello Tony,

I agree.

The problem with prior approaches was that they were try to enumerate 
all the software packages. However, SWID takes this to the next level, 
requiring that each vendor will ship the tag and store it on the filesystem.

I would much rather see a solution that would not only require each 
modular software system to provide an API to list the software included. 
A lot of operating systems already have some kind of database of 
installed packages. The common API could be easily added on top of each 
software stack (OS, virtualization, application servers, containers, 
software collections, markets, ...) and then the data could be collected 
from each recursively.

Example: Consider a Windows host running some virtualization stack and 
Linux guest on top of it, running a CRM on an application server in a 
container. When asked for software listing, host would see the installed 
applications in registry, some of them would be recognized as having the 
software-listing API as well -- it would query each. One of them is the 
virtualization stack that reports software-listing for each guest, etc.

Perhaps, some might argue that the introspection into the virtual system 
should be avoided. Nevertheless, the problems with auditing software in 
containers is similar and needs to be handled.

I wonder, if the API focused approach is more viable?

This idea could be implemented by a third-party, so I can't see a reason 
why a standard API could not be possible.

Best regards,

-- 
Simon Lukasik
Security Technologies, Red Hat, Inc.
https://github.com/isimluk

---

From: "Cheikes, Brant A." <[email-masked]>
Date: Thu, 20 Nov 2014 15:26:33 +0000

Could you explain what a self-referential CPE identifier is?

I'm in the camp that feels that SACM needs to rally around a very small number of schemes for uniquely identifying software products. Such a scheme needs to provide scalable and sustainable answers to these questions:

1. Assignment. Who assigns identifiers to software products, and how is this done?

2. Attachment. Once an identifier is assigned, how does it become "attached" to a software product, such that one can straightforwardly analyze an endpoint and reliably ascertain the identifiers associated with all products present on that endpoint?

3. Public discovery. Once an identifier is assigned, how do arbitrary third parties (e.g., issuers of security bulletins) determine the right identifier for a product to which they need to refer in machine-consumable guidance?

I think this group would make more constructive progress if (a) it could confirm whether a consensus exists around whether or not unique software ID schemes are needed, and (b) it could look thoughtfully at existing solutions and see whether they offer scalable and sustainable answers to the three questions above.

As an example, CPE does not have a scalable or sustainable answer to question 1. Identifier assignment entails human judgment, and there is no scalable process for creating identifiers in a timely way. CPE completely falls down on the attachment question--the standard does not explain how one may perform software asset discovery on an endpoint in a way that yields a list of CPE identifiers. CPE does address public discovery, in the sense that one can look identifiers up in a central dictionary at NIST. But ultimately this is a three-legged stool with two broken legs.

ISO 19770-2 is conceptually strong w/r/t issuance, though it hinges on the same leap of faith of any standard--that implementers adopt it. Success of 19770-2 also hinges on network effects: the value of the standard increases with adoption, so adoption drives adoption. It's an open question regarding how much adoption is "enough". No standard will be universally adopted (short of nation-state coercion), so we need a realistic plan for handling non-conformers while trying to drive those numbers low enough to be manageable.

19770-2 is also strong on attachment: it clearly explains how tags are to be linked to the associated products. Regarding public discovery, that's an issue that bears more thinking and specification, but there are plausible approaches out there that don't involve central authorities, so this shouldn't be hard to solve. (Gunnar: You were on the right track in an earlier posting--one would never embed an entire SWID tag in, say, an XCCDF benchmark, only a unique ID embedded in a published tag.)

In sum, I think effective software identification is key to the success of SACM. SACM can either create anew or reuse. The selected identification scheme (or schemes) need to address assignment, attachment, and public discovery. Those of us who have thought long and hard about CPE have not come up with a way to make it work. 19770-2 strikes many of us as far more promising, and has already achieved some (admittedly small) adoption, including by major vendors like Microsoft, IBM and HP. So I wouldn't dismiss it out of hand until the merits of alternatives (e.g., self-referential CPE identifiers) have been more clearly articulated.

/Brant

Brant A. Cheikes
The MITRE Corporation

-----Original Message-----
From: Gunnar Engelbach [mailto:[email-masked]] 
Sent: Wednesday, November 19, 2014 3:05 PM
To: [email-masked]; Cheikes, Brant A.; [email-masked]
Subject: Re: [sacm] SCAP Specifications related to the SACM Information Model (was RE: information model)

Here here, well stated.

--gun

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 20 Nov 2014 11:13:58 -0500

I'm just giving a name to the way CPE is currently being used in SCAP.

XCCDF benchmarks don't just plop a CPE identifier in as the 
applicability check and leave it at that, the identifier is actually a 
reference to a bit of OVAL included with the benchmark that determines 
whether or not that CPE string applies to the current assessment target.

In that usage the CPE string is just a function reference -- it could be 
any string.  But because it is formatted as CPE a human or a machine can 
use it to derive other information.  Which is handy.  And the function 
it references can take advantage of the existence of any tagging 
information inherent to the target.

The drawback to this approach is that it is unknown if any content 
applies or not until it is queried against each target.  There are 
certainly optimizations that can be made to that, but still...

There's a common problem with all of the software tagging approaches 
which is that none of them have universal coverage and never will (if 
for no other reason due to legacy items).

So SACM needs to have a mechanism that can cover all assets.  And since 
it needs such a mechanism, that mechanism with the universal coverage 
should be the default.

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 20 Nov 2014 23:08:40 +0000

Here is what I know of:

XCCDF, Asset Identification, ARF, and CCSS are NIST publications and are in the public domain.

XCCDF has also been published as an ISO specification - ISO/IEC 18180.

OVAL has IPR - http://datatracker.ietf.org/ipr/1846/
CVE has IPR - http://datatracker.ietf.org/ipr/1845/

I may need to update these as any IPR has been transferred to NIST. We do not intent to encumber this work going forward.
CCE - http://datatracker.ietf.org/ipr/1853/
CPE - http://datatracker.ietf.org/ipr/1852/

CVSS is a specification published by FIRST (http://www.first.org/cvss/cvss-guide) which is the official specification and also by NIST (http://csrc.nist.gov/publications/nistir/ir7435/NISTIR-7435.pdf). The first link is on a web page with FIRST copyright. There is also a PDF version that does not assert any copyrights (http://www.first.org/cvss/cvss-guide.pdf). The second is a NIST specification which is considered public domain. I'm not sure what to do about this one. Any guidance would be appreciated.

I think that is it. Please correct me if I have missed anything.

Thanks,
Dave

-----Original Message-----
From: David Harrington [mailto:[email-masked]] 
Sent: Tuesday, November 18, 2014 11:37 PM
To: Waltermire, David A.
Cc: Gunnar Engelbach; Chris Inacio; [email-masked]
Subject: Re: [sacm] SCAP Specifications related to the SACM Information Model (was RE: information model)

David Harrington
[email-masked]

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

> - 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
> 
> - 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
> 
> - 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:
> 
>> 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?
>> 
>> 
>> 
>> 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