Re: [csaf] Suggested enhancements to CSAF spec

[Eric Johnson <eric@tibco.com>]

Hi Thomas,

Thanks so much for contributing possible improvements.

One general comment - for the moment, the TC has taken the approach of mapping, as closely as possible the CVRF format to the CSAF JSON format, rather than adding any enhancements. There are several reasons for this, but one of them has been a lack of clarity about how the JSON format will be used.

Ideally, we get the JSON 2.0 format done, and then address additional use cases in a newer version (2.1?)

That said, some comments / feedback on the items below:

On Wed, Apr 29, 2020 at 4:17 AM Proell, Thomas <thomas.proell@siemens.com> wrote:

Dear colleagues,

thank you for accepting us as new participants in the group.

We would like to shortly introduce our motivation: In Germany, there is a growing pressure for asset owner (mostly in the OT world but IT as well) to improve the efficiency of their vulnerability risk and patch management. The number of devices and vendors rises. At the same time, more and more devices are looked into and analyzed which leads to discovering vulnerabilities.
Security becomes a selling point so that vendors release more and more security advisories. However, asset owners cannot manually look through all of them anymore and in the current state it is hard to automate the process since the vendors provide their advisories in many different formats.
Therefore, the asset owners long for a machine readable format. Vendors, at least in Germany, get these requests for such a format. This led into a meeting between representatives from both sides to discuss solutions.

Siemens as well as BSI and CERT@VDE believe that CSAF 2.0 is the format to use. Therefore, we would like to contribute in developing the specification and promoting it.

There are a couple of things we would like to suggest and discuss:

1. The Traffic Light Protocol (TLP; https://www.first.org/tlp/) is an important part of our work to make sure information is distributed correctly. At the moment there is only the field "document":"distribution" which is string-based. We suggest an object which includes an optional attribute "tlp" ("enum": ["white", "green", "amber", "red"]) and the required string attribute "description". This would aid in the automated processing of the documents and implementing constraints based on distribution restrictions. If the attribute is not present in a document the standard should suggest one of the following 3 options: either it is treated as undefined (user has to calculate it from the context) or as tlp:white or as tlp:green.

This seems like an enhancement that I suggestion fits with a 2.1 release.

Â

2. To be prepared for coming changes in the document specification CSAF 2.0 should contain a version field that indicates the CSAF-Version the document was created with. This enables the parser to check for the correct syntax and find the right fields even if they would change from version to version. Furthermore, it enables customers and asset owners to require a certain minimum standard on the security advisory once it is widely adopted.

Ugh, yes. This is an oversight. The XML format obviously captured this information as part of the namespace, so we absolutely need to address this for compatibility.

Â

3. The fields "document":"tracking":"version" and "document":"tracking":"revision_history" are not listed as required in CSAF 2.0 (https://github.com/oasis-tcs/csaf/blob/master/sandbox/csaf_2.0/json_schema/csaf_json_schema.json) anymore. We believe that these information are easy to create and maintain and provide huge benefit to the audience. Therefore, the should stay mandatory (as they were in CVRF 1.2).

As our goal has been migration of CVRF 1.2, this seems like an oversight. I don't recall discussion about these fields to change their status.

Â

4. For our customers include in their risk analysis and patch evaluation the question whether a reboot is needed after applying a patch. Therefore, we suggest an additional boolean field restart_required in "vulnerabilities":"remediations" to provide them this information in an easily accessible way.

The point that I've been driving with moving to JSON format is to allow for exactly these kinds of vendor extensions without compatibility concerns. If we do anything about this, I would suggest that we document a way for vendors to provide extensions such as this in a way that prevents conflict with future standardization. Perhaps "{vendor}_{prop_name}". So this would be "siemens_restart_required". Or maybe that's overkill, and simply "x_restart_required".

Also, I wonder if this might also be appropriate to add as an extension to CVE JSON data?

5. As we develop products which are used in industry where safety is the biggest concern, we would like to provide our customers a field which indicates whether the vulnerability has an impact on the safety functions of the product. E.g. a DoS on the webserver does not (necessarily) affect the safety function - the logic program is still running within the given parameter of cycle times. A vulnerability which changes states of outputs on the contrary would compromise the functional safety.

Again, part of the point of the JSON format is to allow for extensions. This seems like a good candidate for an extension.

6. The documentation/standard specification should recommend best practices (as non-normative comments) for certain fields: e.g.
   a) which type (summary, description, details, general) should be (or is preferable) used for describing a vulnerability ("vulnerabilities": "notes")
   b) give an idea what could be part of the remediation description (description of the impact of the component, changes in functions, name of the patch (this could even be a separate field or link back to a ProductID))

Fully agree. I've been editing the document with this kind of thinking in mind. Hopefully we can discuss this during the meeting, as I would like to make sure I have a good idea of what would be valuable here.

Eric

Â

We are happy to open Github issues for 1-5 and provide PRs to resolve them.
We guess issue 6 could be discussed first in a meeting.


With best regards,
Dr. Thomas Proell

Siemens AG
Corporate Technology
Cybersecurity
Europe 1
CT CYS DEF EU1
Otto-Hahn-Ring 6
81739 Muenchen, Germany
mailto:thomas.proell@siemens.com

http://www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322




---------------------------------------------------------------------
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