[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:comment-tabpanel&focusedCommentId=67651#comment-67651 ] Omar Santos commented on CSAF-26: --------------------------------- This is a very interesting and relevant suggestion. The ability to automate the creation of an OVAL definition or COA is definitely a great value add. We will need to work carefully on determining what OVAL product schema will be used based on a new CVRF entry. For example, OVAL currently has schemas for Windows, Cisco IOS, Cisco IOS-XE, different flavors of Linux, and others. However, without a consistent product naming (perhaps via SWID/CPE), this will be hard to correlate. I am assuming that these will be optional fields, since there are no OVAL schemas for numerous operating systems and products in the industry. > 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): > 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. -- 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]