RE: [csaf] CSAF presentation & Where to find CSAF documents

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

Hi Martin,

thank you for your feedback. I think there is a misunderstanding, which I would like to clear up:

The different levels "CSAF publisher", "CSAF provider" and "CSAF trusted provider" were not meant to be used to dictate the issuer of a CSAF document what rules he/she has to follow. It should provide some guidance on what we think is the easiest way to help the customer to use the CSAF documents. It is not meant to put additional force on the issuers just to add convienence for the CSAF aggregators. The CSAF aggregator are only there to support the adoption of the standard: They provide information in a standardized way so that it is usable for the end users. However, they can always collect the advisories from the issuers directly.

The requirement sets given in "CSAF publisher", "CSAF provider" and "CSAF trusted provider" should not hinder any company in adopting the standard. They won't be referenced at the document-level conformance target section. So you can always provide valid CSAF documents without fulfilling any of the requirement levels below.

Please find the reasoning below:
**CSAF publisher**: This should be an easy step for anyone wanting to adopt the standard (and it could also be used as a marketing instrument as well). So I think the requirements are low - correct me if I'm wrong:
- Publish valid CSAF document: I think this one is obvious - if you do not publish valid CSAF documents than you have not adopted the standard.
- File name restriction: Most advisories that are available today use already the advisory id as the filename. Also the CVRF documents published by Cisco and Red Hat derivate their filename from the advisory id. The advisory id is represented in `document/tracking/id`. What was added here, is describing the way in which it should be converted. This helps so that any system (Windows, Linux, Mac) can use CSAF documents. If you think there is a problem with the rules, we can discuss them - this was a suggestion.
- TLS enforced: Most websites already have that available. It is no end-to-end integrity but at least you can be sure that it was not tampered with during the transport. As a customer, you can even implement then certificate pinning if you wish to.
- TLP:WHITE accessible freely: When an advisory is labeled TLP:WHITE the disclosure is not limited. Media can be involved. So from my perspective it makes perfect sense that also have the "raw" CSAF document freely accessible which gives everyone the opportunity to quickly check systems with some kind of automation than parsing a long press statement searching for the technical details which might not even be in there. The issuer could also link it below the article.

I think anyone who wants to adopt the standard can fulfil these requirements. If you already have an infrastructure for publishing advisories, you will most likely easily tick all the boxes. 

**CSAF provider**: This set of requirements is meant to aid in automation. I know that many IT and some OT (Operational Technology) vendors are publishing advisories for years and have their structure and URL. However, I've seen during CVD processes that no all vendors are already prepared to deal with vulnerabilities in their products. Therefore, I think we should take the opportunity to lead them directly to a set of requirements that allows native automation. Moreover, when I look into the German community of asset owners - they would like to have such a URL format to be able to download the advisories automatically and check them against their asset lists. At the moment, this is mostly a manual process and which is resource- and time-consuming.

**CSAF trusted provider**: This set of requirements is meant to add security to the automation. It places the end users in a position where they don't have to trust a third-party anymore that the advisory wasn't changed. They can check it themselves. *Edit:* Since itâs with regards to signatures and checksum verifications, probably âVerifiableâ may be more appropriate than âtrustedâ.

The **CSAF Aggregator** is a special case: You might use it to collect all your advisories from there - a one-stop-shop. Nevertheless, what I think is more important: The aggregator does all the management around finding new CSAF sources and providing them. He also provides the CSAF documents from CSAF publishers at a standardized location, which makes it easier for the end users to adopt the standard.

I strongly disagree with the idea of a central aggregator of CSAF documents because it comes with all sorts of problems: First of all: We add a single point of failure into the system. Then: Who is responsible? Who decides which vendor gets listed? Who maintains it? Is the content legal in all states? What about takedown-requests? What about censorship?
I just named a few.
Therefore, I think we should stick to a decentralized concept.

I totally agree that we need to make the standard approachable to new vendors and projects. However, I think we should not lose sight of the end users. If the standard requires a lot of work there it will not be adopted either since the market is missing. BSI is willing to support the adoption by making proof-of-concepts and tools available.

As mentioned on slide 16 these are open questions that, I think at least, we should not address in CSAF 2.0. SBOM might be able to solve the unique product identifier problem at some point. However, that problem is a completely different story.

Thanks again for the feedback!

Kind regards,
Thomas

-- 
Thomas Schmidt
Federal Office for Information Security (BSI) 

> -----Original Message-----
> From: csaf@lists.oasis-open.org <csaf@lists.oasis-open.org> On Behalf Of
> Martin Prpic
> Sent: Tuesday, January 19, 2021 8:55 PM
> To: csaf@lists.oasis-open.org
> Subject: Re: [csaf] CSAF presentation & Where to find CSAF documents
> 
> Schmidt, Thomas writes:
> 
> > Hi @all,
> > I wish you a happy and healthy New Year!
> >
> > Please find attached the presentation which I would like to give at our next
> call on Wednesday to be able to review it beforehand. You will find
> > - a general introduction: p. 2-5
> > - different maturity stages in regards to security advisories: p. 6-7
> > - conformance targets at document level: p. 8 (see also
> https://github.com/oasis-tcs/csaf/issues/140)
> > - a suggestion how issuers of advisories should provide them: p. 9-10 (see
> also https://github.com/oasis-tcs/csaf/issues/152)
> > - why aggregators are needed: p. 11-15 (see also https://github.com/oasis-
> tcs/csaf/issues/152)
> > - what I suggest to NOT solve in CSAF 2.0 but push to a later version: p. 16
> >
> 
> Hi Thomas,
> 
> Having thought about your presentation a bit, I have a couple of
> comments/questions:
> 
> I find the number of proposed requirements that a CSAF provider has to
> meet
> a bit high. At least in the open source world, CSAF definitely struggles
> with adoption so rating different vendors by their adherence to the
> proposed criteria to be able to be presented in some central aggregator as
> "trusted" seems a bit skewed towards vendors who can devote a lot of
> resources to their CSAF infrastructure. I also doubt many vendors will be
> happy to restructure their website to serve their CSAF content at a
> required location (especially if you expect it to work for any domain and
> subdomain of a vendor).
> 
> I generally like the idea of a central aggregator of CSAF documents, but in
> my opinion it should be community maintained. If I as a vendor want to
> participate in this aggregator, I should be able to provide a pointer to
> the location of all my CSAF documents and that's it. It might be easiest to
> start a csaf-manifest Git repo that may contain structured YAML files (or
> w/e machine readable markup) per vendor.
> 
> I think instead of focusing on added requirements in adopting CSAF, the
> community should make the standard more approachable to new vendors
> and projects.
> 
> Also, slide 16 mentions "Integration of SBOM", what exactly does that mean?
> How is an SBOM related to the content of advisories? Is the intention for
> CSAF documents to include entire SBOMs of artifacts that they provide
> updates for?
> 
> Thanks again for the presentation!
> 
> --
> Martin PrpiÄ / Red Hat Product Security
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php