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.
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.
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).
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.
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.
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))
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.comhttp://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