GithubHelp home page GithubHelp logo

oasis-tcs / csaf Goto Github PK

View Code? Open in Web Editor NEW
134.0 134.0 37.0 39.15 MB

OASIS CSAF TC: Supporting version control for Work Product artifacts developed by members of TC, including prose specifications and secondary artifacts like meeting minutes and productivity code

Home Page: https://github.com/oasis-tcs/csaf

License: Other

HTML 95.94% Shell 0.93% Python 2.42% JavaScript 0.07% CSS 0.64%

csaf's People

Contributors

bentolor avatar bernhardreiter avatar ericjohnson-tibco avatar mprpic avatar robincover avatar santosomar avatar sthagen avatar tibcodenny avatar tiegz avatar tlimmer avatar tolim avatar tschmidtb51 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

csaf's Issues

Product_status artifacts

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

Reference artifacts

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

Product_id type

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.

CVRF 1.2 - Document Tracking – Revision History – Revision – Date - documented incorrectly

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

New Product_status: under_investigation

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.

Version type

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

CSAF version artifact

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.

Branch_branches_t artifacts

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

Language type regular expression

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

CVRF 1.2 - Aggregate Severity Namespace attribute documented incorrectly

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

Aggregate_severity artifacts

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

CVSS information is not in the FIRST recommended data representation format

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.

Prohibit empty strings

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.

Safety-related impact field

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.

Prohibit empty arrays

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.

Boolean field: restart_required

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

Language type

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.

Group_id and groups type

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.

Consider adding support / integration with the Traffic Light Protocol (TLP) classifications

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.

Product Tree Enhancement

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.

Publisher artifacts

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

Add automated tests to repository

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!

Remove branch_product_t

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

CVRF V1.2 Schema Locations Broken

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/

Prohibit empty objects

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.