-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Guidance on how and where to find CSAF documents #152
Comments
This should also be linked to #140 . |
Here are some idea for the requirements in general (which should be divide for the levels as stated above):
|
To provide better insights please find below a table with the requirements and the roles:
Edit: The numbers in brackets refer to the description in #152 (comment) Edit: Removed the mandatory API and made it optional. |
Please also see the email thread at the OASIS Open mailing list. |
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:
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 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. |
I still wonder if we need some document level specification for that „role“.
In summary I think for that additional end-to-end „authenticated integrity capability“ we require changes to the document schema or at least some processing specification where we then can attach the conformance clauses. |
@tschmidtb51 Thank you for the additional details (both here and in our conversation yesterday)! As long as the different roles are communicated as guidance for any CSAF adopters, this will be a nice way to get them up to speed on best practices. The proposal for an aggregator also makes sense and I hope some national CERTs will pick this up. I still have some reservations about URL requirements ( Related to this is also the fact that some vendors may implement serving CSAFs not as documents but as REST API endpoints. Red Hat too publishes CVRF as both individual files and API responses:
Expecting specific API endpoints to conform to a well-known URL would then make them inconsistent with the rest of the API URLs and most likely difficult to implement. |
I agree here. I would go even further, as I do not see the advantage of having a fixed path inside the URL - the main domain of a company is usually not clear. So it always will need to be kept in a database, and the difference between storing |
@mprpic: I see your point. However, if we specify that this could be a redirect then we need to make sure that it works the same way as the URL which does not redirect. Otherwise, we make it nearly impossible for the end user to automate things. What do you think about using
If we add this to the standard, companies can still use their original patterns. For Red Hat it would look like this (assuming that you publish the security advisories under
A request to Would that be a reasonable compromise? |
@tlimmer: Please see the suggested compromise above.
I disagree. The whole point of the URL question is to aid in automation. As an end user I can simply scan all domains to see where security advisories are published as CSAF documents. Therefore, you can put in a list of your vendors and once they start to support CSAF you get the files as soon as you request the URL. Noone has to wait for the vendor to announce it (sometimes the relevant people won't see the announcement at all) or until the vendor get listed at a 3rd party website. |
Trust via URL path parts makes me feel dizzy 😜 I see this offering as guidance for implementers making it easier for consumers during discovery phase, but trust I would not associate. |
Some answers to the discussion about the fixed URL path:
|
I would suggest another alternative that might fit quite well: making use of the IETF Draft for security.txt, that already offers a standard way of retrieving vulnerability-related information from a vendor's web site (https://tools.ietf.org/html/draft-foudil-securitytxt-10). The file must be placed by web-based services in the location
What do you think? |
This is Stefan: I second this proposal. |
In general, I like the idea - we should not reinvent the wheel. However, I struggle at the moment identifying the implications: @tlimmer: Did you already check whether the people specifying the "security.txt" are open to this idea? How would that impact our schedule? The draft you mentioned expired today... |
The draft won't expire while it is under IESG review. However, we cannot add it to the draft as it is today, this would have to wait a few weeks/months until the IANA registry is created and the draft is published as an RFC. |
@nightwatchcyber : Thanks for answering directly! It's important to know that you are open to the idea, and we will get the opportunity to add our own field to the document. So we will wait until the IANA registry is created! |
One alternative solution for a lot of the requirements noted in #152 (comment) is to recommend the use of the ROLIE protocol for the discovery and publication of CSAF documents: https://tools.ietf.org/html/rfc8322 In simple words, the protocol defines a way to publish and consume a feed of all security-relevant documents from a vendor. The discovery of the feed file itself is still an unsolved problem but a proposal exists to use DNS Services Discovery for this: https://tools.ietf.org/html/draft-banghart-mile-rolie-discovery-00 The following tool exists to generate and consume ROLIE feeds: https://github.com/rolieup/golie Red Hat currently publishes a ROLIE feed (in both XML and JSON) for all OVAL definition files and SCAP content: https://www.redhat.com/security/data/oval/v2/ I'd be happy to prepare a demo of the protocol and the tooling that exists to support it if there is interest in this approach. @santosomar, could you add this to the agenda for the next TC meeting? |
- addresses part of oasis-tcs#152 - add basic requirements
- addresses part of oasis-tcs#152 - add role "CSAF publisher"
- addresses parts of oasis-tcs#152 - add requirements with draft description - add roles CSAF provider and CSAF trusted provider
- addresses parts of oasis-tcs#152 - add requirement for ROLIE to be JSON
- addresses parts of oasis-tcs#152 - add remarks about the fulfilling the requirements
- addresses parts of oasis-tcs#152 - add requirements in regard to ROLIE Co-authored-by: Martin Prpič <martin.prpic@gmail.com>
- addresses parts of oasis-tcs#152 - add remark about the secure drop
- addresses part of oasis-tcs#152 - add .well-known as option - rearrange order to ease reading
- addresses part of oasis-tcs#152 - split .well-known into 2 options - address referencing issues
- addresses part of oasis-tcs#152 - add RFC8615 as reference
- addresses part of oasis-tcs#289 and oasis-tcs#152 - add CSAF aggregator JSON schema
- addresses part of oasis-tcs#152 - add requirement for CSAF aggregator list - add role CSAF lister
- addresses part of oasis-tcs#289 and oasis-tcs#152 - add requirements for minimum size and mirroring - add role CSAF aggregator - fix naming (CSAF aggregator light => CSAF lister)
- addresses part of oasis-tcs#289 and oasis-tcs#152 - add metadata "last_updated" to be able to select the newest entry
- addresses part of oasis-tcs#289 and oasis-tcs#152 - add example for provider-metadata.json
- addresses part of oasis-tcs#289 and oasis-tcs#152 - add role into provider-metadata schema
- addresses part of oasis-tcs#289 and oasis-tcs#152 - refactor schema to reduce size
- addresses part of oasis-tcs#289 and oasis-tcs#152 - add example for aggregator.json
- addresses part of oasis-tcs#289 and oasis-tcs#152 - change domains to cleanup example
- addresses part of oasis-tcs#289 and oasis-tcs#152 - add example for mirror
- addresses part of oasis-tcs#289 and oasis-tcs#152 - refactor types to clean up
- addresses part of oasis-tcs#290, oasis-tcs#152 - correct mistake in provider metadata schema
- addresses part of oasis-tcs#290, oasis-tcs#152 - correct reference mistake in provider metadata schema
I suggest to close the ticket. |
We should provide some guidance how and where a publisher should provide the security advisories. This will also help the users to find the security advisories at a publisher’s / vendor’s website. Moreover, it aids in making the format machine processable.
Therefore, I suggest to define several
conformance targetslevels:CSAF modifier: provides CSAF documents which base on CSAF documents which have been published by another CSAF publisher.CSAF translator: translates a CSAF document from one language into another. See Conformance target CSAF translator #156 for details.Update: I removed CSAF translator and CSAF modifier from here and pasted them in #140 since they base on the definition of CSAF producers. Therefore, they are not related to the question where to find CSAF documents.
Edit: I removed the term conformance targets as there was some confusion. To clarify: This is independent from #140 - it does not specify anything at the document level.
The text was updated successfully, but these errors were encountered: