RE: [csaf] Re: [External] : [csaf] Provider Metadata - Feedback needed

["Schmidt, Thomas" <thomas.schmidt@bsi.bund.de>]

Dear Feng,

please find the responses inline:

> I agree that the discovery about which organisations providing CSAF
> documents is a valid issue and should be addressed when there are many
> organizations using CSAF.

It is not only about the discovery, this question is really about distributing CSAF documents. We are in a unique position with the fresh start of CSAF 2.0:
- Asset owners (especially in the OT/ICS space) are searching for a system to automate their advisory handling. They have a lot of different vendors - so they want a system that is easy and just works.
- Additionally, new vendors (especially in that area) are now starting to implement the vulnerability management in their own processes (and of course we want them to use CSAF...)
- the VEX profile gets CSAF additional attention in the SBOM community
- national CSIRTs are looking into CSAF to use it for their own processes and provide CSAF documents of relevant vendors as a service to their critical infrastructure
=> If people start to implement CSAF 2.0 and didn't had anything before, it is always easier to start with all parts of automation from the beginning rather than add that part later when everybody has a different (incompatible) system.
=> It makes it much easier for users, if they can use one implementation for all vendors instead of having a different one for each vendor. This will aid in the adoption of CSAF 2.0.

And to be clear: Even though I would recommend to support automation (and provide the necessary information) - no one is required to. The role "CSAF publisher" has the minimal requirements (see https://github.com/oasis-tcs/csaf/blob/master/csaf_2.0/prose/csaf-v2-editor-draft.md#71-requirements 1 to 4) - none of them is about providing support for automation.
I hope that this will be solved by the market - either through paid services which collect CSAF document from different parties and provide them in a single location (role "CSAF aggregator") or by the customers who require the vendor to become a "CSAF provider" during the purchase process... (Looking at EO14028, I guess the govs will use the second approach. Having that in the standard will also help to prevent that companies have to provide their CSAF documents in multiple different ways because every country came up with a novel solution.) 

> But is it really needed to be in CSAF 2.0? If there will be many
> organizations providing CSAF in the next several months, please let me
> know.

Probably not right after the standard is release but we are working on that. And I'm sure you're too.
We are in contact with a lot of companies (both asset owners and vendors) about the introduction of CSAF 2.0. Moreover, CSAF 2.0 get advertised all our CVD cases. There are presentations at conferences like Black Hat USA and FIRST.

> A quick alternative solution might be to provide a host page (probably
> in oasis or github) listing the organizations and their directories for
> CSAF documents (the page format can be discussed), and this page can be
> mentioned in CSAF 2.0 document so that each organization will have its
> CSAF info added into the page. This TC can be in charge of the page and
> approve/add the new CSAF info when a request from an organization is
> received.

The PR suggests a format for such a list. But the benefit here is, that the users are not limited to the list the TC (or any other central party) provides. Since the format is specified, everyone can setup a list and the user chooses whom to trust. Moreover, we provide the opportunity for people to create a business model around that and still ensure that it benefits the community as they are all compatible due to the common format.

I hope that clarifies the intentions and benefits of that PR.

Best regards,
Thomas
 

> -----Original Message-----
> From: csaf@lists.oasis-open.org <csaf@lists.oasis-open.org> On Behalf Of
> Feng Cao
> Sent: Tuesday, July 13, 2021 8:24 PM
> To: Schmidt, Thomas <thomas.schmidt@bsi.bund.de>
> Cc: csaf@lists.oasis-open.org
> Subject: [csaf] Re: [External] : [csaf] Provider Metadata - Feedback needed
> 
> I agree that the discovery about which organisations providing CSAF
> documents is a valid issue and should be addressed when there are many
> organizations using CSAF.
> 
> But is it really needed to be in CSAF 2.0? If there will be many
> organizations providing CSAF in the next several months, please let me
> know.
> 
> A quick alternative solution might be to provide a host page (probably
> in oasis or github) listing the organizations and their directories for
> CSAF documents (the page format can be discussed), and this page can be
> mentioned in CSAF 2.0 document so that each organization will have its
> CSAF info added into the page. This TC can be in charge of the page and
> approve/add the new CSAF info when a request from an organization is
> received.
> 
> Thanks,
> 
> --Feng
> 
> On 7/12/2021 4:55 PM, Schmidt, Thomas wrote:
> > Dear colleagues,
> >
> > you were probably expecting the next (and hopefully final) editor revision
> right now. Unfortunately, it is not ready yet. We made significant progress
> but came across one problem:
> >
> > As we all know automation is needed and this includes the discovery which
> organisations provide CSAF documents. Several options were defined for
> that:
> > - through security.txt
> > - through Well-known URL
> > - through DNS path
> >
> > However, it might be tricky to have an idea under which domain to look for
> those - especially if you provide your services in more than one country and
> therefore have multiple domains under different TLDs (e.g. .com, .de,
> .co.au,...). To solve this problem, the CSAF lister was suggested (in #152,
> previously known as CSAF aggregator light). It is basically a role which
> provides a list of URLs of known CSAF distribution points. That means where
> issuing parties (CSAF publisher, CSAF provider, CSAF trusted provider)
> publish their CSAF documents.
> >
> > To ease the adoption (especially for SME and starters) we specified 2
> approaches how to distribute CSAF documents:
> > - a directory-based approach
> > - a ROLIE based approach
> >
> > Unfortunately, this makes it harder for the user to determine which
> approach is used (since currently the issuing party doesn't have to tell that
> explicitly).
> >
> > CSAF publisher (which is the basic role) don't even provide any level of
> automation. As the number of issuing parties can get big easily (with
> different level of automation), the CSAF aggregator was suggested (also in
> #152). It collects the CSAF documents from different issuing parties and
> provides them as a one-stop-shop in the best automatable way.
> >
> > Given that the metadata is currently missing, it is a real hard problem to
> collect/add this data as a CSAF aggregator in an automated way. Moreover, it
> is unclear where the issuing party is okay with a mirror of its documents.
> >
> > To solve these issues, I came up with a (simple) solution: The issuing party
> provides the metadata itself. We can than extract the necessary data
> automated. This does not apply for CSAF publisher which currently do not
> support any automation - so there is no need for that additional
> requirement. A CSAF aggregator has to list the manually anyway. (At that
> time they SHOULD try to convince them to become a CSAF provider ;-)).
> >
> > Please see the full amount of changes for that solution sketched out in
> https://urldefense.com/v3/__https://github.com/oasis-
> tcs/csaf/pull/290__;!!ACWV5N9M2RV99hQ!a71VyHtiyQg2EVyuCJ4gvBYmy2Q
> 7vH7_BPWlmUtx6eXsPFlpH0Drho0xkYFp21M$ . Please provide feedback
> (either directly at the PR (preferred) or on the mailing list).
> >
> > If you have any questions, do not hesitate to contact me.
> >
> > Best regards,
> > Thomas
> >
> > PS: As soon as we have a consens here, I'm happy to add the additional
> examples.