RE: Vulnerability Description Ontology

["Booth, Harold (Fed)" <harold.booth@nist.gov>]

Both Kurt and Tom hit at some of the issues. To be elaborate a bit more.

The NVD has had a vulnerability format of sorts for at least ten years (if not longer) but there are not enough hooks to enable a machine to make decisions about vulnerabilities without direct human assistance, and creating some sort of automated mechanism for identifying the intrinsic properties of a vulnerability has been of interest to me since I started working on the NVD. As we were looking at how to produce CVSS v2 and v3 scores we really wanted a way to analyze vulnerabilities once and then generate scores for both CVSS v2 and v3 which is what prompted us to start work on this approach. While I had originally planned to have more of a working implementation within the NVD prior to creating the document, with the recent renewed focus on CVE and vulnerabilities in general I believe that getting this document out there to start a conversation about the best way to talk about vulnerabilities and perhaps using this document as a foundation for an automatable methodology for exchanging vulnerability information would be of some use. I also think a common way to talk about vulnerabilities and being able to identify the types of information that could be provided about a vulnerability will allow consumers of vulnerability information to specify what information they need in order to accomplish their goals. Finally, I really want to be able to exchange vulnerability information across linguistic boundaries and the only way I know to do that in a scalable manner (read: automated) is by creating something like this. So to summarize:

* analyzing vulnerabilities once (preferably as early in the process as possible),

* automate handling and processing (answer the questions: Do I have it? What’s the impact?),

* allow end users to identify and ask for information they require, and

* exchange across linguistic boundaries

To be clear, this is only a first draft and if anyone has some good ideas that would be useful I would be happy to talk. I have already received a few comments that will likely result in some substantive changes to improve the organization and structure.

 

Regards,

 

-Harold

 

From: Kurt Seifried [mailto:kseifried@redhat.com]
Sent: Wednesday, October 05, 2016 9:00 PM
To: Millar, Thomas <Thomas.Millar@hq.dhs.gov>
Cc: jericho <jericho@attrition.org>; Booth, Harold (Fed) <harold.booth@nist.gov>; cve-editorial-board-list@lists.mitre.org
Subject: Re: Vulnerability Description Ontology

 

What we currently have (e.g. CVRF) is not only laughably out of date (can we have CVSSv3 please?) but solves a problem that no longer exists (in the sense of the problem has gotten so much worse...). Our current problems are much scarier, and the problems we will have in 5 years ... Yeah. If we don't strongly automate this (like I mentioned int he call we need the low level bits like ASN.1->X.509->HTTPS) we are doomed. 

 

I'll be honest, the whole reason the DWF is moving so slowly is I'm not doing any work on it in order to let it pile up and see what we need to do to automate it and how (now I'm playing catch up on the first bits, and documenting what/how this will all be automated). The problem is we're going to be automating something that heavily involves humans as the source (computers produce nice data, humans produce... stuff =). 

 

On Wed, Oct 5, 2016 at 6:44 PM, Millar, Thomas <Thomas.Millar@hq.dhs.gov> wrote:

This might come off like a rant but it's really not

NVD (namely, Harold) has been working on a bigger and better structured format for security bug data for ages, especially since CVRF came out, and was/is basically an advisory format so multiple incumbent vendors share testing and patch data.

This ontology m,from my perspective, is a strong attempt at creating a way for security-affecting bug knowledge to be captured in a structure that accommodates for all the wacky use cases we've learned about over the decades (decades!) so that various collectors, curators and creators of such data can share alike.

A few years ago it was okay to have proprietary scripts and expert knowledge serving the purpose, but now there's too many vulns (with and without CVEs) and too many DBs and tools. Harold's ontology draft is the beginning of a better and more systematic approach.

Did I overdo it? Am I false?



Tom Millar, US-CERT

Sent from +1-202-631-1915
https://www.us-cert.gov

 

---

From: owner-cve-editorial-board-list@lists.mitre.org on behalf of jericho
Sent: Wednesday, October 05, 2016 11:37:19 PM
To: Booth, Harold (Fed)
Cc: cve-editorial-board-list@lists.mitre.org
Subject: Re: Vulnerability Description Ontology

: This is the first of hopefully several drafts and we are looking at the
: comments to see in which ways we need to modify in order to satisfy the
: needs for vulnerability management.

I am curious what perceived 'gap' in vulnerability management this is
designed to fill. Can you elaborate on the origins of this initiative?

Brian

 

--

 

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com