[OASIS Issue Tracker] (CSAF-26) Product Tree Enhancement

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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