Subject: [OPSAWG] csaf addition to draft-ietf-opsawg-sbom-access

From: Eliot Lear <[email-masked]>
Date: Tue, 25 May 2021 15:01:14 +0200

Hi,

For those of you who don’t know, Common Security Advisory Format (CSAF) 
is an evolution on Common Vulnerability Reporting Framework.  Such an 
object could easily be delivered with an SBOM.  It has a slightly 
different characteristic in terms of update frequency.  CSAF changes may 
happen independently of software updates, and generally would*not* be 
hosted on individual devices (at least, I don’t see the use case).

CSAF files indicate what products and versions are vulnerable (and what 
are not), and what if any remediations are available, not unlike a 
classic PSIRT advisory.

My proposal is to add into the draft an optional URL that indicates the 
CSAF object for This device, a’la:

> container sbom {
> …
>    leaf csaf-location {
>       type inet:uri;
>       description “Location of CSAF file”;
>   }

I would add some descriptive text similar to the above in as well.

Does this raise any concerns?

Eliot

---

From: Patrick Dwyer <[email-masked]>
Date: Tue, 25 May 2021 23:51:41 +1000

Hi Eliot,

A well-known URI is just one way of enabling delivery of an SBOM.

Because of this, I think suppliers will need to include the CSAF location
in the SBOM itself.

I also think this is one of those things that crosses a logical boundary
that is no longer about discovering and accessing an SBOM.

Regards,
Pat

On Tue, May 25, 2021 at 11:01 PM Eliot Lear <[email-masked]> wrote:

> Hi,
> For those of you who don’t know, Common Security Advisory Format (CSAF) is
> an evolution on Common Vulnerability Reporting Framework.  Such an object
> could easily be delivered with an SBOM.  It has a slightly different
> characteristic in terms of update frequency.  CSAF changes may happen
> independently of software updates, and generally would *not* be hosted on
> individual devices (at least, I don’t see the use case).
>
> are not), and what if any remediations are available, not unlike a classic
> PSIRT advisory.
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 May 2021 18:37:26 +0200

> A well-known URI is just one way of enabling delivery of an SBOM.

YYyyyes...  but did you mean CSAF above?

>
> Because of this, I think suppliers will need to include the CSAF 
> location in the SBOM itself.
>
That would tightly bind the CSAF to the SBOM, and I don't think they are 
tightly bound.  That is, one could release a CSAF without an SBOM (as is 
pretty much done today).

> I also think this is one of those things that crosses a logical 
> boundary that is no longer about discovering and accessing an SBOM.

That is true.  But not a huge stretch.

Eliot

---

From: Patrick Dwyer <[email-masked]>
Date: Wed, 26 May 2021 13:08:42 +1000

See comments below. Please note, I'm not firmly in opposition of the idea.
Just contributing my viewpoint on it.

> YYyyyes...  but did you mean CSAF above?

No, I meant SBOM. It was context for the following comment.

> tightly bound.  That is, one could release a CSAF without an SBOM (as is
True, although I wouldn't expect a CSAF reference in isolation in this
case.

> That is true.  But not a huge stretch.
It's not a huge stretch. But this is also tied to a particular format for
this type of information. Personally I think CSAF is *the* format to use.
But that might not be the case in some particular industries and countries.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 May 2021 08:38:58 +0200

Hi Patrick,

Snipping to the meat:

> True, although I wouldn't expect a CSAF reference in isolation in this 

I think different manufacturers will hold different points of view on 
this.  Some may simply be required to release an SBOM based on some 
regulatory requirement.  Some not, and some may wish to release an SBOM 
without using this mechanism.

> It's not a huge stretch. But this is also tied to a particular format 
> for this type of information. Personally I think CSAF is /the/ format 
> to use. But that might not be the case in some particular industries 
> and countries.

Yes.  I myself am hemming and hawing on this point a bit... Let's just 
delve into that a bit more:

On the one hand, we have one really good candidate, CSAF.  On the other 
hand, one might want to refer to the Old (more deployed) Stuff, which 
does almost as good a job, CVRF.  On the third hand, it is possible that 
this information could be included directly in a schema like CycloneDX, 
either directly or as an extension.  On the fourth hand, the information 
could be included as a reference by the underlying SBOM format, as you 
mentioned earlier.

So what are the principles here?  I think they are these:

 1. If the information exists outside the context of an SBOM, it should
    be made known.
 2. Don't make the end device do work.  Leave that to the network
    management.
 3. When there's one really overwhelmingly good candidate, use it and
    don't overcomplicate the network management.
 4. Provide some flexibility for the idea that these formats may change.
 5. Don't duplicate information elements.

Some of these principles conflict.  Here's what I suggest:

 1. If the information is included in the SBOM there is no need for a
    MUD file to include the new element.
 2. If the information is NOT included in the SBOM, or the SBOM isn't
    available, there is a need to provide the new element.
 3. Let's change the name of the element from "csaf-location" to
    "vulnerability-info", and make use of the same mechanism we used for
    SBOMs to decide, with a suggestion that CSAF be the preferred
    initial format for consumers.  This splits the baby a bit, but
    perhaps covers your concern?

Also note that with CSAF I am taking a certain liberty to constrain the 
CSAF reference in this case to contain a single product, so that we 
don't get into a naming fiasco.  Naming.  I hate naming.

Eliot

---

From: Patrick Dwyer <[email-masked]>
Date: Wed, 26 May 2021 21:46:04 +1000

I agree with all of that. Perhaps not on whether it belongs here though.
This draft, so far, is completely focused on SBOMs. Not on vulnerability
information or advisories.

Perhaps it would be better served as a separate MUD extension and
well-known URI?

On Wed, May 26, 2021 at 4:39 PM Eliot Lear <[email-masked]> wrote:

> hand, one might want to refer to the Old (more deployed) Stuff, which does
> almost as good a job, CVRF.  On the third hand, it is possible that this
> information could be included directly in a schema like CycloneDX, either
> directly or as an extension.  On the fourth hand, the information could be
> included as a reference by the underlying SBOM format, as you mentioned
> earlier.
>
>    "vulnerability-info", and make use of the same mechanism we used for SBOMs
>    to decide, with a suggestion that CSAF be the preferred initial format for
>    consumers.  This splits the baby a bit, but perhaps covers your concern?
>
> CSAF reference in this case to contain a single product, so that we don't
> get into a naming fiasco.  Naming.  I hate naming.
>
> Eliot
>
>
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 May 2021 17:20:44 +0200

I don't mind.  If it helps I can relabel some of the containers to 
generalize.  Also keep in mind, the extension does not REQUIRE any 
elements in the MUD file.  But I think the WG should make a call on 
this.  If it is a bit far aways from the SBOM, we could write another draft.

On 26.05.21 13:46, Patrick Dwyer wrote:
> I agree with all of that. Perhaps not on whether it belongs here 
> though. This draft, so far, is completely focused on SBOMs. Not on 
> vulnerability information or advisories.
>
> On Wed, May 26, 2021 at 4:39 PM Eliot Lear <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Patrick,
>
>     Snipping to the meat:
>
>>     True, although I wouldn't expect a CSAF reference in isolation in
>>     this case.
>
>     I think different manufacturers will hold different points of view
>     on this.  Some may simply be required to release an SBOM based on
>     some regulatory requirement. Some not, and some may wish to
>     release an SBOM without using this mechanism.
>
>>
>>
>>     It's not a huge stretch. But this is also tied to a particular
>>     format for this type of information. Personally I think CSAF is
>>     /the/ format to use. But that might not be the case in some
>>     particular industries and countries.
>
>     Yes.  I myself am hemming and hawing on this point a bit...  Let's
>     just delve into that a bit more:
>
>     On the one hand, we have one really good candidate, CSAF.  On the
>     other hand, one might want to refer to the Old (more deployed)
>     Stuff, which does almost as good a job, CVRF.  On the third hand,
>     it is possible that this information could be included directly in
>     a schema like CycloneDX, either directly or as an extension.  On
>     the fourth hand, the information could be included as a reference
>     by the underlying SBOM format, as you mentioned earlier.
>
>      1. If the information exists outside the context of an SBOM, it
>         should be made known.
>      3. When there's one really overwhelmingly good candidate, use it
>         and don't overcomplicate the network management.
>      1. If the information is included in the SBOM there is no need
>         for a MUD file to include the new element.
>      2. If the information is NOT included in the SBOM, or the SBOM
>         isn't available, there is a need to provide the new element.
>         "vulnerability-info", and make use of the same mechanism we
>         used for SBOMs to decide, with a suggestion that CSAF be the
>         preferred initial format for consumers.  This splits the baby
>         a bit, but perhaps covers your concern?
>
>     Also note that with CSAF I am taking a certain liberty to
>     constrain the CSAF reference in this case to contain a single
>     product, so that we don't get into a naming fiasco.  Naming.  I
>     hate naming.
>
>     Eliot
>
>

---

From: Patrick Dwyer <[email-masked]>
Date: Thu, 27 May 2021 08:12:27 +1000

Just to be clear. I'm on the fence.

SBOMs and security advisory information, although delivered separately, go
hand in hand.

I think this draft is pretty close to done. Adding security advisories to
it, in my opinion, would require changes to the introduction and security
considerations sections.

I think it's cleaner to leave security advisories out of scope for this.

Deferring to the WG sounds like a reasonable idea.

Thanks Eliot

On Thu, May 27, 2021 at 1:20 AM Eliot Lear <[email-masked]> wrote:

> generalize.  Also keep in mind, the extension does not REQUIRE any elements
> in the MUD file.  But I think the WG should make a call on this.  If it is
> a bit far aways from the SBOM, we could write another draft.
>> this type of information. Personally I think CSAF is *the* format to
>> use. But that might not be the case in some particular industries and
>> countries.
>>

---

From: "Dick Brooks" <[email-masked]>
Date: Wed, 26 May 2021 18:15:51 -0400

+1 I think it's cleaner to leave security advisories out of scope for this.

Thanks,

Dick Brooks

 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

 <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com

Email:  <mailto:[email-masked]> [email-masked]

Tel: +1 978-696-1788

From: OPSAWG <[email-masked]> On Behalf Of Patrick Dwyer
Sent: Wednesday, May 26, 2021 6:12 PM
To: Eliot Lear <[email-masked]>
Cc: [email-masked]
Subject: Re: [OPSAWG] csaf addition to draft-ietf-opsawg-sbom-access

SBOMs and security advisory information, although delivered separately, go hand in hand.

I think this draft is pretty close to done. Adding security advisories to it, in my opinion, would require changes to the introduction and security considerations sections.

Thanks Eliot

On Thu, May 27, 2021 at 1:20 AM Eliot Lear <[email-masked] <mailto:[email-masked]> > wrote:

I don't mind.  If it helps I can relabel some of the containers to generalize.  Also keep in mind, the extension does not REQUIRE any elements in the MUD file.  But I think the WG should make a call on this.  If it is a bit far aways from the SBOM, we could write another draft.

I agree with all of that. Perhaps not on whether it belongs here though. This draft, so far, is completely focused on SBOMs. Not on vulnerability information or advisories.

Perhaps it would be better served as a separate MUD extension and well-known URI?

On Wed, May 26, 2021 at 4:39 PM Eliot Lear <[email-masked] <mailto:[email-masked]> > wrote:

Hi Patrick,

Snipping to the meat:

True, although I wouldn't expect a CSAF reference in isolation in this case. 

I think different manufacturers will hold different points of view on this.  Some may simply be required to release an SBOM based on some regulatory requirement.  Some not, and some may wish to release an SBOM without using this mechanism.

It's not a huge stretch. But this is also tied to a particular format for this type of information. Personally I think CSAF is the format to use. But that might not be the case in some particular industries and countries. 

Yes.  I myself am hemming and hawing on this point a bit...  Let's just delve into that a bit more:

On the one hand, we have one really good candidate, CSAF.  On the other hand, one might want to refer to the Old (more deployed) Stuff, which does almost as good a job, CVRF.  On the third hand, it is possible that this information could be included directly in a schema like CycloneDX, either directly or as an extension.  On the fourth hand, the information could be included as a reference by the underlying SBOM format, as you mentioned earlier.

1.	If the information exists outside the context of an SBOM, it should be made known.
2.	Don't make the end device do work.  Leave that to the network management.
3.	When there's one really overwhelmingly good candidate, use it and don't overcomplicate the network management.
4.	Provide some flexibility for the idea that these formats may change.
5.	Don't duplicate information elements.

1.	If the information is included in the SBOM there is no need for a MUD file to include the new element.
2.	If the information is NOT included in the SBOM, or the SBOM isn't available, there is a need to provide the new element.
3.	Let's change the name of the element from "csaf-location" to "vulnerability-info", and make use of the same mechanism we used for SBOMs to decide, with a suggestion that CSAF be the preferred initial format for consumers.  This splits the baby a bit, but perhaps covers your concern?

Also note that with CSAF I am taking a certain liberty to constrain the CSAF reference in this case to contain a single product, so that we don't get into a naming fiasco.  Naming.  I hate naming.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 May 2021 23:33:02 -0400

Eliot Lear <[email-masked]> wrote:
    > different characteristic in terms of update frequency.  CSAF changes

It's not an SBOM, but it would be associated with a specific instance of an
SBOM, right?

    >> container sbom { …     leaf csaf-location {       type inet:uri;      

So, would this be an alternative to an actual SBOM?
Would the CSAF instead point to the SBOM indirectly?
Or would this be in addition to an SBOM?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Eliot Lear <[email-masked]>
Date: Thu, 27 May 2021 23:35:22 +0200

> It's not an SBOM, but it would be associated with a specific instance of an

I think the relationship varies on format.  They CAN be independent or 
related.

> So, would this be an alternative to an actual SBOM?

Patrick can say more here, but one could easily imagine an extension of 
CycloneDX that would contain CSAF info, and if that is the case, you 
wouldn't include this separate element in the MUD extension.

> Would the CSAF instead point to the SBOM indirectly?
Yes.
> Or would this be in addition to an SBOM?
And yes.  Depending on how the SBOM is constructed, and whether it's 
there at all.

Clear as mud?

---

From: Patrick Dwyer <[email-masked]>
Date: Fri, 28 May 2021 15:03:36 +1000

> wouldn't include this separate element in the MUD extension.

We have support for external references to security advisory information in
the core spec. We aren't prescriptive about the format used. Although we
recommend CSAF.