[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (CSAF-26) Product Tree Enhancement
[ https://issues.oasis-open.org/browse/CSAF-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Hagen updated CSAF-26: ----------------------------- Reporter: Jerome Athias (was: Stefan Hagen) > Product Tree Enhancement > ------------------------- > > Key: CSAF-26 > URL: https://issues.oasis-open.org/browse/CSAF-26 > Project: OASIS Common Security Advisory Framework (CSAF) TC > Issue Type: Task > Reporter: Jerome Athias > Assignee: Jerome Athias > > Member Jerome Athias reported an enhancement (on github as https://github.com/oasis-tcs/csaf/issues/2 this has been moved here for eventual opening/processing/resolving ... etc by the TC): > 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): > Automated generation of OVAL content > 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. -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]