oasis-tcs / csaf Goto Github PK

Create a markdown document with existing CVRF repositories

The field "text" in "aggregate_severity" should be required as stated in the specification of CVRF 1.2 (see CSAF-4.8-2).

This issue has been created to collect feedback on the CSAF 2.0 JSON schema draft Product Tree section/element.

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.

This issue has been created to collect feedback on the CSAF 2.0 JSON schema draft Document Root section/element.

I would like to suggest that we try to enhance the Product Tree schema/model.
The intent is to support more automation for (examples of use cases):

1. Automated generation of OVAL content
2. Automated generation of mitigations for COAs (e.g. OpenC2 context)

For 1), e.g. with the Microsoft API (ref. https://blogs.technet.microsoft.com/msrc/2016/11/08/furthering-our-commitment-to-security-updates/ ), it would be needed information like filenames, file versions and/or hashes (or other 'objects' "artifacts"/""observables"" like registry keys) to completely automate the generation of OVAL Definitions
Note that for nix systems packages could be already somehow covered as products

BUT software packages, like .jar files still seem not covered, leading to issues like https://opensource.googleblog.com/2017/03/operation-rosehub.html

For 2) e.g. for web vulnerabilities, information like URLs/webpage names, and parameters/functions would be needed in order to, i.e., automate the generation of WAF signatures (or more generally IDS/IPS signatures)
We need to resolve Wordpress/Struts "funny" stories...

The best approach, imho, to define and include these information in the schema/model, would be to reuse the (OASIS CTI STIX) CybOX objects (observables) models, so that more interoperability and automation into related playbooks will be obtained
e.g.
=> new CVRF
==> new STIX/IODEF package
===> new OVAL Definition, trigger for SACM (assets/endpoints/nodes affected identified from the inventory)
===> new COA for OpenC2, mitigation with IDS/IPS/WAF signatures, apt-get update like commands, or monitoring SIEM rules, etc.

The schema uses arrays in the definition. However, it still validates successful if they are empty which could allow defeating a required information by putting in an empty array. I suggest to prohibit empty arrays - if no information is present, the field should not be present as well.

The type definition of "system_name" in vulnerabilities seems to be misplaced. The definition in "id" is the correct one according to CVRF 1.2 Section 6.3 (see https://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/cs01/csaf-cvrf-v1.2-cs01.html#_Toc493508716. Therefore, the one mentioned first is a duplicate and should be removed.

Sometimes a vendor is unable to tell which devices are affected but wants to inform that he is investigating the issue. This might be the case for a hardware vulnerability (e.g. Spectre, Meltdown, etc.). Therefore, we suggest a new product status "under_investigation" which allows a vendor (or any other publishing party) to state for which products a customer can expect to get a definitive / authoritative statement on the product status regarding the current vulnerability.

Add an additional boolean field restart_required in "vulnerabilities":"remediations" to provide them this information in an easily accessible way.

The definition of "version" is used multiple times. Following the DRY principle this should be extracted to a type.

Diagrams and figures should be updated in the CSAF 2.0 schema documentation draft

Hi,

the schema files in the repository and on the OASIS web site cannot currently be used to validate CVRF V1.2 files.

The namespace definition published at:

http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2/cvrf

refers to the schema location at:

http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/cs01/schemas

However, the cvrf.xsd in this GIT repository (cvrf_1.2/csaf_cvrf/schemas/cvrf.xsd), and on the OASIS website (http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/cs01/schemas/cvrf.xsd) reference schema files to be hosted on http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2:

<xs:import namespace="http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2/vuln" schemaLocation="**http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2/vuln.xsd**"/><xs:import namespace="http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2/common" schemaLocation="**http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2/common.xsd**"/><xs:import namespace="http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2/prod" schemaLocation="**http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2/prod.xsd**"/>

This breaks validation because the files are not available on this location. It would be either required to publish the schema files at

http://docs.oasis-open.org/csaf/ns/csaf-cvrf/v1.2/

or to change cvrf.xsd to point to the real location of the XSD files:

http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/cs01/schemas/

The schema uses strings in the definition. However, it still validates successful if they are empty which could allow defeating a required information by putting in an empty string. I suggest to prohibit empty strings - if no information is present, the field should not be present as well.

The fields "product_reference", "relates_to_product_reference" and "relationship_type" in items of the array "relationships" should be required as stated in the specification of CVRF 1.2 (see https://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/cs01/csaf-cvrf-v1.2-cs01.html#_Toc493508906).

Section 4.8 says: "The optional Namespace attribute’s value SHOULD be a URL (xs:anyURI) pointing to the namespace so referenced"

However, according to the XML Schema, the Namespace attribute, if present must be xs:anyURI.

Proposal: change the wording to "The optional Namespace attribute’s value
MUST be a URL (xs:anyURI) when specified, and SHOULD point to a document
documenting the Namespace values."

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.

Section 4.5.4.1.2 says "The element cvrf:Date MUST appear exactly once in cvrf:Revision and SHOULD record the date the revision was made and MUST be valid representative of the Date and Time model documented in section 2.2.1 Date and Time. "

However the XMLSchema indicates minOccurs = 0!

Proposal: update specification text to read:
The optional element cvrf:Date can appear exactly once in cvrf:Revision and SHOULD record the date the revision was made and MUST be valid representative of the Date and Time model documented in section 2.2.1 Date and Time.

Alternative proposal - update the schema to remove minOccurs (effectively making it a "1").

The schema should have an $id property.
"The $id property is a URI-reference that serves two purposes:

• It declares a unique identifier for the schema.
• It declares a base URI against which $ref URI-references are resolved.

It is best practice that every top-level schema should set $id to an absolute-URI (not a relative reference), with a domain that you control."
https://json-schema.org/understanding-json-schema/structuring.html#the-id-property

Review and update document references and footnotes of the CSAF 2.0 documentation draft.

The schema is missing a full regular expression to enforce CPE syntax. This issue should track suggestions and develop one / check existing ones.
A starting point could be figures 6-1 to 6-3 from Common Platform Enumeration: Naming Specification Version 2.3.

The value of "product_id" is used multiple times. Following the DRY principle and to prepare for a unique product identifier this should be extracted to a type.

Examples should be included for each objects/elements in the CSAF 2.0 schema documentation.

The field "document":"publisher":"type" is not required in the current JSON-Schema. This breaks compatibility to CVRF 1.2 which requires the field (see CSAF-4.4-1).

Re-organize Repository Elements based on feedback in the following thread: https://lists.oasis-open.org/archives/csaf/202005/msg00004.html

The value of "group_id" is used multiple times. However, it is semantically not the same as a "product_id". Following the DRY principle and to prepare for a unique product identifier where also the definition of these types will differ the corresponding definitions should be extracted to types.

The definition of "lang_t" is used multiple times but doesn't reference the type in "definitions". Following the DRY principle it should reference the existing definition.

Review the typography section to remove any typography styles not used in the CSAF 2.0 draft document.

Looks like the CVSS information is not encoded using the recommended JSON format:

CVSS SIG has a recommended JSON schema for storing and exchanging CVSS scores:
https://www.first.org/cvss/data-representations

There are few issues with CVSS in current csaf_json_schema.json:

1. CVSS scores are strings instead of a number. Which means consumers may have to convert a string to number to for proper processing. JSON allows numbers, so doesn't make sense to store a number as a string.
2. if CVSS version number is part of the field name (for eg., "base_score_v3") when there is a CVSS 3.1 or 4.0, you may have to change the schema (and CSAF version). The FIRST CVSS json schema encodes it in a "version" field. This allows better abstractions, and backwards/forwards compatibility.
3. No validation on format of the vector string format. The FIRST CVSS json schema does have validation builtin.

Suggested fix: make cvss_score_sets an array of objects that $ref to FIRST cvss json schema.

The field "type" in items of the array "remediations" should be required as stated in the specification of CVRF 1.2 (see https://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/cs01/csaf-cvrf-v1.2-cs01.html#_Toc493508946).

Relationship: prod:Relatinship
should be
Relationship: prod:Relationship

Update Appendix A - acknowledgments after the initial document draft is completed.

#67 was reviewed and approved by TC during the June 24, 2020 monthly meeting. @santosomar summarizes the discussions and call for suggestions about the pattern:

TC members are encouraged to suggest any additional edits to the pattern/string "pattern": "^[a-zA-Z]{2,3}(-.+)?$" . Additional information about the convention (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry) and other items are documented in the associated issue and were also discussed during the June 24, 2020 monthly meeting.

This is an issue to track and discuss these suggestions.

The fields "name" and "type" in "branch_branches_t" should be required as stated in the specification of CVRF 1.2 (see https://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/cs01/csaf-cvrf-v1.2-cs01.html#_Toc493508698). Moreover, "type" should be an enum following the Product Branch Type Model (see https://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/cs01/csaf-cvrf-v1.2-cs01.html#_Product_Branch_Type).

Create a new CSAF 2.0 parser to test the draft CSAF 2.0 documents.

The type definition of "branch_product_t" is a duplicate and never used. It should be removed.

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.

I suggest to add automated tests into the Github repository using Github actions. Triggered by pushed commits into the repository, the tests would automatically be executed and show the result on the repository's web site. If a test failed, an email would automatically be sent to the committer.

The following tests could be integrated:

• Check syntax of CSAF JSON schema
• Check syntax of CSAF examples (CVE-2018-0171-modified.json and cvrf-rhba-2018-0489-modified.json)
• Check validity of CSAF examples against JSON schema
• Check validity of CSAF examples against modified version of our JSON schema to enable strict checking (add "additionalProperties": false in each object)
• Perform automated conversion of the original CVRF 1.2 examples into CSAF and check their validity

The already implemented tests are available in our forked repository, please see an example here: https://github.com/tschmidtb51/csaf/runs/720620127?check_suite_focus=true)

I have the following questions:

• What do you think? As a next step, I would create a pull request using the current tests for this repository.
• What additional tests would make sense?

Thanks!

The object "product_status" should have a least one property as stated in the specification of CVRF 1.2 (see CSAF-6.10-1).

The schema uses objects in the definition. However, it still validates successful if they are empty which could allow defeating a required information by putting in an empty object. I suggest to prohibit empty objects - if no information is present, the object should not be present as well.

They don't appear to offer any value.

This issue has been created to collect feedback on the CSAF 2.0 JSON schema draft Vulnerability section/element.

The field "product_ids" and "group_id" in items of the array "product_groups" should be required as stated in the specification of CVRF 1.2 (see https://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/cs01/csaf-cvrf-v1.2-cs01.html#_Toc493508908).

This issue has been opened to change the CVSS "score sets" in CVRF 1.2 to "scores" in CSAF 2.0.

The type "references_t" doesn't define a default value for "type" which is required in CVRF 1.2 (see CSAF-4.9.1-4).

Translate the CVRF 1.2 examples and GitHub documentation.

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

The field "type" in items of the array "threats" should be required as stated in the specification of CVRF 1.2 (see https://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/cs01/csaf-cvrf-v1.2-cs01.html#_Toc493508928).

The type "branch_branches_t" should have either a "branches" or a "product" property as stated in the specification of CVRF 1.2 (see CSAF-5.1.1-2).

As discussed during the June 24, 2020 monthly meeting this is a reminder to change the URL to the official https://docs.oasis-open.org/csaf/ns/ namespace once the schema becomes official.