Subject: [mile] Clarifying iodef:SoftwareType (Issue #47)

From: "Roman D. Danyliw" <[email-masked]>
Date: Tue, 24 Mar 2015 19:55:00 +0000

Good afternoon!

One of the remaining issues with rfc5070bis is to clarify the iodef:SoftwareType.  See Issue #47 [1].  We discussed this impasse in Honolulu [2].

--[ snip discussion from IETF 91 ]--
Q1: (Roman Danyliw) Last mailing list discussion on clarifying iodef:Software produced no result.  What does the group want to do?
A: (David Waltermire) Extensibility is key dimension.  Consider just using swid and reference the ISO standard.  Alternatively, redefine the class to be AdditionalData.
A: (Adam Monteville) Reiterated the importance of extensibility
A: Isn't swid support already in the spec?
A: (Roman Danyliw) There is an attribute named "swid" but this comes from RFC5070 which just happened to use this name without reference to the ISO standard.
A: (Takeshi Takahashi) IODEF-SCI can embed SWID and CPE as well, but the context is different; it is added under AdditionalData. If we need the data here, we could make a model here like the SCI draft does.
--[ end snip ]--

The four options mentioned to date (not just at IETF 91) are:

(1) Use OVAL [3]

(2) Use swid referencing ISO/IEC 19770-2:2009 (with XML schema at [4])

(3) Don't define it and use AdditionalData

(4) Support mutiple techniques to reference software in the same way  (like IODEF-SCI and ENUM)

Approach (1) and (2) are require little further explanation.  Hence, let me describe (3) in more detail.

The thinking would be to create an IANA registry to maintain a list of external references, in this case application reference techniques (e.g., swid and CPE), just like IODEF-SCI and ENUM current do.  The class using this technique might look as follows:
             +---------------------+
             | Application         |
             +---------------------+
             | ENUM SpecID         |<>--(0..*)-[ SpecData ]
             | STRING ext-SpecID   |
             |                     |
             +---------------------+

** SpecID would map to an IANA registry of application reference techniques
** ext-SpecID would allow for private enumerated value extensions as currently done in the draft
** SpecData would be defined as follows allowing both XML or atomic data types such as a string.
     <xs:complexType name="AppIdType" mixed="true">  
      <xs:sequence>
        <xs:any namespace="##any" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>

In the same way that the general purpose ENUM approach was useful to SACM and MILE, SACM has also expressed interest in a common approach on this class too.

What does the community feel is the correct approach?

Roman

[1] http://trac.tools.ietf.org/wg/mile/trac/ticket/47
[2] http://www.ietf.org/proceedings/91/minutes/minutes-91-mile
[3] https://nvd.nist.gov/cpe.cfm
[4] http://standards.iso.org/iso/19770/-2/2009/schema.xsd

---

From: "Adam W. Montville" <[email-masked]>
Date: Tue, 24 Mar 2015 16:46:47 -0500

> On Mar 24, 2015, at 2:55 PM, Roman D. Danyliw <[email-masked]> wrote:
> 
> Good afternoon!
> 

The SACM working group will indeed have the same problem to solve shortly.  Enabling the use of multiple software identification mechanisms, (simply because it’s unlikely just one will suffice), *seems* to be the better choice.  

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

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 24 Mar 2015 18:00:06 -0400

+1

On 2015-03-24 5:46 PM, Adam W. Montville wrote:
> The SACM working group will indeed have the same problem to solve shortly.  Enabling the use of multiple software identification mechanisms, (simply because it’s unlikely just one will suffice),*seems*  to be the better choice.

---

From: Sean Turner <[email-masked]>
Date: Tue, 24 Mar 2015 18:31:14 -0500

Roman,

Clarifying questions:
1. Can you get a SWID for free?
2. Is there a mapping between CPE <-> SWID?

spt

---

From: Jerome Athias <[email-masked]>
Date: Wed, 25 Mar 2015 09:10:20 +0100

Hi

(4) seems the best approach IMHO for now (would allow use of OVAL/CPE,
SWID, or any others. And the "any others" is needed.)

Warning regarding OVAL vs IODEF-SCI (4.5.2.) for the -Platform-
definition and use: different
Little warning regarding "Application" vs "Software"

Note: a IANA registry tentative would be difficult, IMHO, and not
flexible enough (potentially too restrictive) IF the extension
mechanism is not allowing others (e.g. own organisation
classification/categories). Furthermore, I'm not sure a IANA registry
with just 2 entries would need effort put in it. Cristal clear
recommandations/guidances for use of CPE or SWID could be enough.

(2) is not free
Any stats on real/current usage rate of SWID?

PS: SWID->CPE mapping is possible

My 2c for now
Best regards

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 25 Mar 2015 04:39:38 -0500

Hi,

As a person who had engaged in IODEF-SCI, I would be happy if we can use 
IODEF-SCI.
(It does not mean I am objecting any other options for this issue.)

I was planning to propose some minor changes after the IODEF-bis is 
finalized.
So, if some changes to IODEF-SCI may help here, I am happy to do so.
The current IODEF-SCI (RFC 7203) was made for IODEF v1, and it anyway needs 
some small changes to cope with IODEF-bis.

The current IODEF-SCI defines one basic structure, and it is used by its 
inherited classes: AttackPattern, Platform, Vulnerability, Scoring, 
Weakness, EventReport, Verification, or Remediation classe.
The structure of all these classes are more-or-less the same as the basic 
structure, but the location to use them are restricted.
If it helps, we could for instance remove these inherited classes and just 
define the basic structure so that it can be used by any of the 
AdditionalData class inside IODEF document.
In this way, we do not have to re-invent new data model for this discussion.

Kind regards,
Take

-----Original Message----- 
From: Jerome Athias
Sent: Wednesday, March 25, 2015 3:10 AM
To: Roman D. Danyliw
Cc: [email-masked]
Subject: Re: [mile] Clarifying iodef:SoftwareType (Issue #47)

Hi

(2) is not free

My 2c for now
Best regards

2015-03-24 20:55 GMT+01:00 Roman D. Danyliw <[email-masked]>:
> Good afternoon!
>
> One of the remaining issues with rfc5070bis is to clarify the 
> iodef:SoftwareType.  See Issue #47 [1].  We discussed this impasse in 
> Honolulu [2].
>
> Q1: (Roman Danyliw) Last mailing list discussion on clarifying 
> iodef:Software produced no result.  What does the group want to do?
> A: (David Waltermire) Extensibility is key dimension.  Consider just using 
> swid and reference the ISO standard.  Alternatively, redefine the class to 
> be AdditionalData.
> A: (Roman Danyliw) There is an attribute named "swid" but this comes from 
> RFC5070 which just happened to use this name without reference to the ISO 
> standard.
> A: (Takeshi Takahashi) IODEF-SCI can embed SWID and CPE as well, but the 
> context is different; it is added under AdditionalData. If we need the 
> data here, we could make a model here like the SCI draft does.
> --[ end snip ]--
>
> The thinking would be to create an IANA registry to maintain a list of 
> external references, in this case application reference techniques (e.g., 
> swid and CPE), just like IODEF-SCI and ENUM current do.  The class using 
> this technique might look as follows:
>              +---------------------+
>              | Application         |
>              +---------------------+
> In the same way that the general purpose ENUM approach was useful to SACM 
> and MILE, SACM has also expressed interest in a common approach on this 
> class too.
>

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Wed, 25 Mar 2015 10:33:30 +0000

Hello Sean!

Response inline ...

> On Mar 24, 2015, at 6:31 PM, Sean Turner <[email-masked]> wrote:
> 
> Roman,
> 
> Clarifying questions:

Yes.

> 2. Is there a mapping between CPE <-> SWID?

There isn't one of which I am aware. Does anyone know differently?

Roman

---

From: Sean Turner <[email-masked]>
Date: Wed, 25 Mar 2015 06:50:44 -0500

> There isn't one of which I am aware. Does anyone know differently?

Thanks, my thinking then is:

1. It seems kind of odd to force all of those folks with CPEs already to switch, i.e., it’s too onerous and frankly unlikely to happen.

2. It seems odd to force new folks to a USG site, even if it is a defacto standard in some sense, especially when there’s a “free” alternative.

3. We could do a mapping, but if there’s a away to avoid it then maybe we should.

Seems like of the options you listed below #3 or #4 with a slant towards #4, because it’s already defined, is the way to go here.

spt

---

From: "Cheikes, Brant A." <[email-masked]>
Date: Wed, 25 Mar 2015 12:59:20 +0000

Sorry for jumping late into the SWID conversation, but I think I can help here. In the past I was the MITRE lead for CPE, and more recently I've been working with TagVault and various US Government stakeholders interested in and/or considering promoting use of SWID tags.

The group should be aware that a major revision to the ISO/IEC 19770-2 SWID tag specification is going through final balloting within ISO. The new standard should be available in June or July, with a small chance of a glitch delaying release to the fall. The 2015 version will be *much* better than the 2009 version, and is worth waiting for.

Regarding the question, "Can you get a SWID for free?" Anyone can generate a SWID tag, of course; you just need to validate against the SWID schema. ISO charges a fee to obtain a copy of the actual specification document, and this seems to greatly irritate some people, but if you can get past that, all you need is a copy of the spec and the XSD and you're good to go.

TagVault is trying to develop a self-sustaining business model (they're a non-profit chartered under IEEE ISTO) in which they would provide a fee-based tag certification service. But this certification program is not really in operation, and would always be optional. The main point of certification is to ensure that there has been some basic quality control and data normalization of the supplied tag data elements (a kind of "good housekeeping" seal of approval), and allow an independent third-party to digitally sign a tag and its data elements to provide a cryptographic tamper indicator. But the bottom line is: no fee required to produce or consume a valid SWID tag.

Regarding CPE<->SWID mapping: In fact, I worked with TagVault to develop such a mapping for the 2009-era tag; see: 
http://tagvault.org/2012/04/23/cpe-integration/

There is no "perfect" mapping because many of the CPE components (e.g., target_sw, target_hw, language) have never been well defined or even widely used. But we came up with a basic plan for populating a CPE name from a subset of the SWID tag data elements, and also for using elements of a CPE name to populate a basic SWID tag. But that's by no means an ideal solution, only a stopgap. I won't bore this audience with all the details, but the requirements on CPE name components and SWID tag data elements simply do not align perfectly, so using a SWID tag as a source of a CPE name (or vice versa) will leave you with a less than ideal (in terms of data quality and normalization) CPE name or SWID tag.

I think that's a long enough message for one day. I hope that helped, and I'll try to stay tuned in case other related questions arise.

Cheers,
/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: mile [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Wednesday, March 25, 2015 7:51 AM
To: Roman D. Danyliw
Cc: [email-masked]
Subject: Re: [mile] Clarifying iodef:SoftwareType (Issue #47)

1. It seems kind of odd to force all of those folks with CPEs already to switch, i.e., it's too onerous and frankly unlikely to happen.

2. It seems odd to force new folks to a USG site, even if it is a defacto standard in some sense, especially when there's a "free" alternative.

3. We could do a mapping, but if there's a away to avoid it then maybe we should.

Seems like of the options you listed below #3 or #4 with a slant towards #4, because it's already defined, is the way to go here.

spt