Wrt “if we want to move forward with CSAF to become an OASIS standard”:
I’m torn on which side of the “if” to support. My natural tendency is to be agile and push for moving to standard – and just put out a new version if something needs to be added. But historically standards
have not been as agile as I would have liked and people resist changing something “standardized” (and I would like to see something added to CSAF).
I would like to see the CSAF VEX profile enhanced to include machine readable “not affected flags” and “affected flags”. For example the reason the author says this product is not affected is “component_not_present”
which may invoke a different policy than “vulnerable_code_cannot_be_controlled_by_adversary” which is different than etc. Similarly for affected, “known_exploits_in_the_wild” might invoke a different policy than “theoretically_exploitable”. My particular interest
is automated cybersecurity decision making (eg CACAO playbooks) based on these “flags/attributes/whatevertheygetcalled”. Note it’s possible to do this with the current CSAF spec using existing freeform text fields but I think machine readable attributes would
lead to fewer interworking issues and to greater adoption.
There is not yet consensus on the number/definition/placement of these flags - even whether to call them “flags” - so I don’t want to bog down CSAF moving to standard. Conversely I don’t want to delay adding
the flags because “CSAF is going thru full OASIS standards approval” or “it just got approved so don’t change it for a year”. Personally I’m favoring holding off to get the flags in, but I’d welcome feedback from others on how soon the “flags” could be agreed
to and whether we should hold off until then.
--
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
From:
csaf@lists.oasis-open.org <csaf@lists.oasis-open.org> on behalf of Schmidt, Thomas <thomas.schmidt@bsi.bund.de>
Date: Friday, January 14, 2022 at 12:41 PM
To: csaf@lists.oasis-open.org <csaf@lists.oasis-open.org>
Subject: [csaf] CSAF - Statement of use (Template)
Dear colleagues,
if we want to move forward with CSAF to become an OASIS standard, we need Statements of use. Stefan and I have worked on a template which we could use for those. (As I write text only - please find the statement below in markdown-like format).
You can either state the implementation of Conformance targets [see section 9](https://docs.oasis-open.org/csaf/csaf/v2.0/cs01/csaf-v2.0-cs01.html#9-conformance)
or Roles in the Distribution [see section 7.2](https://docs.oasis-open.org/csaf/csaf/v2.0/cs01/csaf-v2.0-cs01.html#72-roles) or both. To simply this, please see the
lists below:
Conformance targets:
- CSAF document: A security advisory text document in the format defined by this document.
- CSAF producer: A program which emits output in the CSAF format.
- CSAF direct producer: An analysis tool which acts as a CSAF producer.
- CSAF converter: A CSAF producer that transforms the output of an analysis tool from its native output format into the CSAF format.
- CVRF CSAF converter: A CSAF producer which takes a CVRF document as input and converts it into a valid CSAF document.
- CSAF content management system: A program that is able to create, review and manage CSAF documents and is able to preview their details as required by CSAF viewer.
- CSAF post-processor: A CSAF producer that transforms an existing CSAF document into a new CSAF document, for example, by removing or redacting elements according to sharing policies.
- CSAF modifier: A CSAF post-processor which takes a CSAF document as input and modifies the structure or values of properties. The output is a valid CSAF document.
- CSAF translator: A CSAF post-processor which takes a CSAF document as input and translates values of properties into another language. The output is a valid CSAF document.
- CSAF consumer: A program that reads and interprets a CSAF document.
- CSAF viewer: A CSAF consumer that reads a CSAF document, displays a list of the results it contains, and allows an end user to view each result in the context of the artifact in which it occurs.
- CSAF management system: A program that is able to manage CSAF documents and is able to display their details as required by CSAF viewer.
- CSAF asset matching system: A program that connects to or is an asset database and is able to manage CSAF documents as required by CSAF management system as well as matching them to assets of the asset database.
- CSAF basic validator: A program that reads a document and checks it against the JSON schema and performs mandatory tests.
- CSAF extended validator: A CSAF basic validator that additionally performs optional tests.
- CSAF full validator: A CSAF extended validator that additionally performs informative tests.
Roles:
- CSAF publisher (https://docs.oasis-open.org/csaf/csaf/v2.0/cs01/csaf-v2.0-cs01.html#721-role-csaf-publisher)
- CSAF provider (https://docs.oasis-open.org/csaf/csaf/v2.0/cs01/csaf-v2.0-cs01.html#722-role-csaf-provider)
- CSAF trusted provider (https://docs.oasis-open.org/csaf/csaf/v2.0/cs01/csaf-v2.0-cs01.html#723-role-csaf-trusted-provider)
- CSAF lister (https://docs.oasis-open.org/csaf/csaf/v2.0/cs01/csaf-v2.0-cs01.html#724-role-csaf-lister)
- CSAF aggregator (https://docs.oasis-open.org/csaf/csaf/v2.0/cs01/csaf-v2.0-cs01.html#725-role-csaf-aggregator)
Best regards,
Thomas
Statement of use - Template
---------------
**Official address, contacts etc. of the <entity>**
# General Statement
<entity> has successfully used or implemented the Common Security Advisory Framework Version 2.0 <csaf_conformance_targets_or_whatever> as specified in the CSAF specification [1] in accordance with the conformance clauses specified therein and OASIS policy.
# Detailed Statement
<entity> has successfully used, or implemented, a <csaf_conformance_targets_or_whatever> supporting the stated functionality defined in the CSAF specification [1], in accordance with the conformance clauses specified therein.
{OPTIONAL: <entity> has become a <csaf_distribution_role> satisfying the requirements defined in the CSAF specification [1]. {OPTIONAL_ALTERNATIVE_1: The provider metadata is available at: <url_to_provider-metadata.json_of_entity>}{OPTIONAL_ALTERNATIVE_2: The
aggregator metadata is available at: <url_to_aggregator.json_of_entity>}}
[1] Common Security Advisor Framework Committee Specification 01, 12 November 2021,
https://docs.oasis-open.org/csaf/csaf/v2.0/cs01/csaf-v2.0-cs01.md
---------------------------------------------------------------------
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