Out of all things in the world, it is now my pleasure to introduce you from the MITRE Corporation, Dan Adonofi and Anthony Singleton to talk about CVEs.
So, Anthony, Dan, take it away.
Thank you very much. Hi, folks. Welcome to DEF CON. Y'all having fun?
Yeah? All right, now I'm going to lay some facts on you here.
Okay, this is, the talk, the whole point of this talk is to give you, the audience, an understanding of, A, what CVE IDs are.
Okay, so it's, there's a lot of misconceptions about what CVE IDs are, how they're used, how they're assigned, why they're not assigned, things like that.
So we're going to talk a little bit about that. We're going to talk about how you get these things.
It's amazingly simple, but it's always, there's always a little catch, right?
So we're going to talk a little bit about what those catches are.
Getting a CVE ID assigned is different from getting it published.
So we're going to talk a little bit about that, and especially addressing why you might see a reference to a CVE ID in the public,
but you're not seeing it in the CVE ID list, and why that is.
We're also going to just mention how you can update and work with CVE to improve the content that we have,
improve the data that we have, so that the whole community benefits.
And then hopefully we'll have time at the end for some questions.
All right. So, first off, anyone in here who doesn't know what a CVE, has never heard of CVE?
Okay, good. Common Vulnerabilities and Exposures.
Okay, so CVE, it is a dictionary of publicly known cybersecurity vulnerabilities.
The whole point of CVE ID is to uniquely identify vulnerabilities,
so that you know when you're talking to a scanning vendor, some other security entity,
who's doing a vulnerability analysis on you, your own internal teams.
When you talk about a vulnerability, you're all talking about the same thing.
It's an apples-to-apples conversation, and you can use the CVE ID to pivot around all the different tools and conversations that might be out there.
If you look at the antivirus world, antivirus software vendors name things each differently.
You know, if you look at different viruses, they have like 10, 20 names, depending on who's named them,
and when they named them, and who they think did it, and all that.
It's very confusing. So CVE was created to address that kind of problem.
And so, again, when you're talking about a vulnerability, you're using a name that everyone understands from tool to tool and from conversation to conversation.
Yeah?
.
I'll talk a little bit more about what data we do have and what we can do in a bit.
So, again, there's a lot of misconceptions about CVE, a lot of misconceptions about what people expect of us.
We are, first of all, a de facto standard.
We're not a standard. IETF never said, let there be CVE.
It was something that MITRE and the U.S. government put together to initially help MITRE, actually.
It was an internal project that the government said, hey, this is a great idea.
We should do something with it.
And it grew from there.
It is, again, a dictionary.
And it acts as that pivot point.
Now, what it is not, CVE is not a vulnerability mitigation itself.
We sometimes get e-mail from people saying, how can I use this CVE to fix my computer?
That's not quite the right question, right?
The question should be, okay, I've identified a CVE.
Where do I get more information about it?
We're not a vulnerability database, okay?
To us, a vulnerability database is something that,
takes a CVE ID, a uniquely named object,
and then enriches the information that they have about it.
So, for example, the National Vulnerability Database, NVD.
They are a consumer of our information.
They take that information in, and then they add to it.
They add CVSS scores.
They add other references.
They add things like risk assessment or attack vectors.
Stuff that we don't necessarily publish in ours.
And that's done purposely.
We're not out there to compete with vulnerability vendors.
We're just there to name the vulnerabilities.
So, again, we don't include risk assessment.
We don't talk about impact.
We don't talk about the fixes.
We don't care if there's a fix or not.
We don't really dive too far into the technical information.
That's not what our service is about.
Now, that information is useful when determining whether or not something is a vulnerability.
And we'll talk about that in a minute.
But it is not required for a CVE ID to be assigned and published.
We also, by the way, we're not there to announce vulnerabilities.
CVE IDs are only published in our list when they have become public already.
There has to be a public reference to the vulnerability somewhere out there on the Internet that we can point to.
Because we don't want to be the first point of publishing for anything.
We don't want to be there.
Like announcing a zero day.
That's not what we are there for.
There's a few reasons for that.
Mainly, we just don't want to become...
There's a lot of legal stuff.
Let's just put it that way.
Our lawyers looked at it.
Our management looked at it.
And they just decided that's not what we want to do.
But this drives a lot of why you might have problems seeing CVE IDs published when they're assigned.
And, again, we'll talk about that in a minute.
So who can assign a CVE ID?
So the primary assigner of CVE IDs is still the MITRE Corporation.
Just so you understand, the MITRE Corporation is a not-for-profit organization.
We run seven federally funded research and development centers for the U.S. government.
CVE work is under one of those.
So MITRE does a whole bunch of things, CVE being one of them.
And we operate all the guts behind the program.
And we administer both the technology, the operational side, and the administrative side.
We work with our sponsors in the Department of Homeland Security.
And we work with stakeholders in the community to provide this service.
In addition to MITRE, we have what we call the CNAs, the CVE Numbering Authorities.
These are organizations that we've given the...
we've delegated authority to to assign CVE IDs based on a common set of rules that we call the CNA rules.
We're very good at naming things.
So these CNA rules define things like who's responsible for what, who should be assigning what,
what information they need to share, what information they need to make public.
Any CNA must have a disclosure policy, for example.
CNAs can be someone like Microsoft, Apple, Cisco.
It can also be research organizations like Cisco Talos or Rapid7.
Rapid7 is actually a hybrid because they have their products and they do their research.
It can also be individual researchers, people who have come to us and are working with us a little more closely
and are producing enough CVEs that it makes sense for them to get a stack of CVEs at the beginning of each year
and then just assign those as they need them.
That's the real...the main benefit of being a CNA is that you get a block of CVEs,
CIDs ahead of time, and you have more control when you're a product vendor, for example,
over the disclosure process.
Right now, if a company isn't a CNA and one of their products has a vulnerability in it,
it's discovered, the researcher comes to MITRE and says,
I found a vulnerability in product X.
If they're not a CNA, we'll say, yep, looks like a vulnerability.
We'll go through the assignment process.
If they are a CNA, if company X for product X is a CNA,
we would pass it to them, and they would have the first crack at understanding the vulnerability,
setting the timeline.
As long as they're following their published disclosure process, they have that control.
So if you work at a company that has a PCERT function, we'd love to talk to you.
If you're a researcher who's doing a lot of vulnerability research, we'd like to talk to you.
If you're a nation state who has a CERT, we'd like to talk to you.
We work with JP CERT CC, Korea CERT CC.
We're talking to Europe.
We're trying to get these out there to different entities that are involved in vulnerability disclosure
to help with that whole process.
That's a whole other talk.
But I just wanted to get that plug in there.
Because one of my hats is the CNA coordinator, so I have to do that.
The CNA ultimately would decide for their own product.
Oh, sure, yes.
The question was, if we're referring to a CNA, who decides if it's a vulnerability or not?
The CNA or MITRE?
So it depends.
If we hand it to the CNA and they look at it and they agree with the researcher,
yes, this is a vulnerability, then it follows the process through.
They look at it and say, no, this isn't a vulnerability.
We have a process.
We have an escalation process where the researcher could come to MITRE and say,
that CNA over there said that what I found wasn't a vulnerability.
Help me.
And what MITRE will do in that case is pull the CNA and say, what's your side of the story,
understand the researcher's side of the story,
and then make a determination based on the information that is available from the researcher
and from the vendor.
So we have the final say as the maintainer of the program,
but we want everyone in the room working to understand if something should be assigned or not
when there is a dispute.
Any other questions before I move on?
Okay.
So there's a value to having a CVID.
That value is you've named something, and once you've named it,
you can coordinate with other people, talk with other people about it,
and be clear about what you're talking about.
But when is the right time to actually go get your CVID?
So first thing, you have to identify a new or previously unassigned vulnerability in any product.
Okay.
Now, we have traditionally only been assigning in a very small scope up until the last year,
and some of you might have hit that wall where you're like,
I found this cool vulnerability in a skateboard.
And we said, well, we're not covering that.
I'm not going to go into why that was.
We've changed.
Anything can get a CVID now.
If you're in the IOT right now, you can get a CVID.
If you're in the room and you find something in there,
you can probably get a CVID for it.
If you're in the automotive hacking area, you can probably get a CVID for it.
We're working with the medical community.
We're working with, again, our international partners.
We don't care.
Why do we think that CNA should rule the world?
No.
No, of course not.
But what we do think is that we have this resource,
and that it's silly that it shouldn't be utilized by anyone else who needs to use it.
CV is a lot like an ISBN number in a book.
Each book has a unique ISBN number.
It's how you identify the books.
And they're used around the world.
People could come up with different ways of naming things in different countries, but why?
If this system works, or it's a system that exists that we can improve on,
you don't need to recreate everything.
So it doesn't matter the product.
Talk to us.
There are some exceptions.
We don't cover software as a service as of yet.
So, for example, if it's a bug in AWS,
it may not get a CV assigned to it.
But if it's software that is something that the end user can control,
that the consumer can control,
or hardware that the consumer can control,
it probably qualifies to get a CV ID.
So let's say you've discovered something.
The first step in a responsible or coordinated,
or whatever term you want to use, disclosure process,
is reaching out to the maintainer of that software.
So if it's a vendor, it would be a vendor.
If it's a project, an open source project,
it's reaching out to the people who run the project.
And get them in the loop.
They should be aware of it.
If they are a CNA, they have a process to get the CV ID assigned for it.
And they will have their own policies about what information they need from you,
what information they're going to give back to you, all that.
And that should all be documented.
And if you run into problems with that,
again, we can help.
We can intercede with that.
If they're not a CNA, though,
you have to make sure that it hasn't already been assigned.
So do a little research.
Do a little checking on the website.
See if there's anyone else who's found this vulnerability
and has assigned a CV ID to it.
If not, then you're good.
Now, some other cases could come up as well.
If you're working with a coordination center,
if it's a big deal, big product,
and you're working with CertCC,
JPCertCC, ICScert,
you want to make sure you're coordinating with them.
It really doesn't matter who assigns it, per se.
But you want to make sure that people aren't assigning
two CV IDs to the same thing.
The whole point is that each CV ID is unique.
So if you're working with a coordination center,
coordinate with them.
It helps make sure that there's less confusion.
Note, and as I said before,
the vulnerability does not have to be public
before you request it.
It won't be published in our list until it's public.
But if you found a vulnerability
and you're going through an embargo process,
having that CV ID early means that
everyone who's involved in the embargo
are going to use that when it goes public,
and can use it when it's being dealt with under the embargo.
So you can ask for it as soon as you realize it'll need one,
but then it won't get published publicly
until the information's been publicly given out
as part of the disclosure process.
So you don't have to wait,
but until it's public,
we don't put it in our list.
So before I move on,
any questions about any of that?
We have about 65 right now.
They range, again, from vendors,
we have a few bug bounty programs,
we have some national certs,
and we're always looking to get more.
Ideally, every vendor is a CNA,
every PCERT,
every vendor that has a mature vulnerability management process
can be a CNA,
and they should be for their own product.
We have one CNA that maybe issues a CV ID a year,
and then we have Adobe.
And with Flash going away,
I think we'll go out of business,
it's horrible.
So, I love Adobe.
So it doesn't matter the size,
it doesn't matter the vertical,
it can be anybody.
Right now it's 65.
In the last year, we went from 25 to 65,
so we're really trying to ramp it up.
And it is a community,
so that if you're working in a PCERT,
say, you get to talk to other PCERTs,
and you get to sort of get around the politics
that might be there.
It's like, why are you talking to our competitor?
You know, you get that sometimes.
We want to create a trust community
within the vulnerability management crowd
so that you all can talk to each other
and coordinate and learn from each other.
Because I think last year at Black Hat, right,
security, we don't compete on security, right?
We believe in that.
So.
Yes.
How do you address,
like, how would you represent
?
.
Right.
So how do you weed out,
how do you weed out duplicates
when what you find may be generically described already
in another CVID,
or that might be something
completely different?
The more information,
the better that you can provide us.
The more information you provide us,
the better, okay?
Because we do have,
you know, we can look at what is public.
We can do some of that analysis.
We hope that you will do that analysis as well.
This is a scaling problem.
If you all in the room came to me today
with one of these,
like, I'd have to get back to you, right?
But if you do some of the due diligence yourself
and come to us,
we'll be able to work much more quickly.
This comes up with things like fuzzing.
We can sometimes get requests
for dozens of CVIDs
from somebody who's doing fuzzing.
It's unclear, based on the information
that we've been given,
whether or not it's actually just one vulnerability
that's been kicked off a bunch of times,
or if it's actually a dozen different vulnerabilities.
Because they haven't actually provided the information
to make that determination,
or they haven't done that due diligence.
We have a set of rules that we follow,
and sometimes we have to make judgment calls,
but that's built into our process.
We try to do it consistently.
But the more information that you have
and you can give to us,
and you can say,
I don't know if this is a duplicate of this other one.
It looks kind of similar.
That is information that, if it's us,
we can look at and analyze.
If it's a CNA, they'll know, certainly,
because hopefully they know their product.
Hopefully.
So, yeah.
It's about...
It's really that due diligence is important.
We don't have access to magic source code
that you all don't.
And even open source software...
I mean, there's a lot of code out there,
and we're a very small team.
So the more you can give to us
that you've sort of generated through,
the faster and easier it is for us to work through it
and to get back to you.
Okay?
So I mentioned these rules.
We call this counting.
Okay?
So counting asks two questions.
Is it a vulnerability per CVE?
Is it a vulnerability?
And if it is a vulnerability,
how many vulnerabilities are there?
Okay?
This is exactly what we were talking about here.
And I'm going to pass it over to Anthony
to talk a little bit more about counting.
Thank you, Dan.
Thank you, Dan.
So the runoff that...
So we have this process in place,
this method in place,
because in the industry,
there's so many different definitions
for vulnerabilities and, again,
even more definitions for bugs.
So instead of trying to come up
with our own definition of the two,
we've set a method called counting
in place to kind of help you figure out,
as Dan talked,
about seeing if the bug is a vulnerability
and then seeing how many there actually are.
And so those are the two phases
that it's actually broken into.
So the first thing we're going to do
is determine the number of vulnerabilities.
So we do...
This is going to be how we do it
at internal CVE.
We start by breaking the report
into the individual bugs.
And then from there,
we determine if those bugs themselves
are vulnerabilities.
For those that do,
we then go to the next step.
But for the ones that don't,
we then put them together and see
if there's a combination of bugs
that will give you a vulnerability.
And then we move on.
Once we have that listed or figured out,
you then determine whether
the vulnerability occurs
due to shared code,
protocol, or standard.
And if it does,
we then merge those vulnerabilities
into one.
Because the issue is now in that
either the shared library,
protocol, or standard.
After you do that,
now you know how many vulnerabilities there are.
Which then leads you into your second phase
of figuring out
does these vulnerabilities warrant a CVE ID?
Well,
you determine that because you have to understand
that there's a certain value,
as we talked about earlier in the slide deck,
what the purpose and value is
of CVE.
So for that, we have to start off by saying
or thinking or determining
whether the information for that vulnerability
will be released.
So it will be public information for people to have.
So it doesn't make sense to have an ID
if you're going to restrict access to the information.
So if no one can know about the vulnerability,
why have an ID?
So that's the first thing you have to know,
is that we're going to release that information publicly,
we give an ID to it,
so now everyone that also talks about that
knows that we're actually talking about this one CVE ID.
The next thing for that
is you have to understand
the community must be able to do something
to mitigate the vulnerability.
So a lot of this comes back to being something
that's considered customer controlled.
Meaning that you release a report
and you agree on this vulnerability,
and now the community can say,
well okay, I know if I apply this patch
I can then remove this vulnerability.
So that's another benefit of having it.
And then the last one is kind of subjective,
but the community has to be concerned
about the security of the product.
Again, it's subjective,
so when you make the request,
you would tell us what the impact of that vulnerability is,
and most likely we'll agree with you
based on your research.
And then again, like we talked about a little bit earlier,
we want to make sure we're not duplicating requests.
We want to make sure there's no,
if it hasn't been assigned,
we'll also work with you if there is a duplicate.
So,
the community must be concerned
about the security of the product.
So yes, it's subjective,
but it can also be very easy.
For example, this bug allows you
to turn the color of the page to blue.
Okay.
Is that a security vulnerability?
It depends.
If you're in a power plant,
and you need to know that if something turns red,
it's bad, and if it's blue, it's good.
Well, if you can arbitrarily change the color,
that's a security problem, right?
So there's like this policy
that you have to take into consideration.
Whereas, if it's like a web browser,
it turns it blue,
that's really more of a bug than a vulnerability.
The community must be able to do something
to mitigate the vulnerability.
That doesn't mean that there is a bug,
I'm sorry,
that doesn't mean that there is a patch already.
It means that it has to be something
under their control.
So again, back to the AWS example.
If there's a bug in AWS's stack
that is above user land,
above where a user can actually
affect something in it,
you know,
that's not something that we'll probably
assign a CVID for.
Because Amazon certainly needs to handle that,
they need to market it,
they need to spin it,
whatever they need to do,
but they're the only ones
who can do anything about it.
Their users might need to be aware of it,
but giving it a CVID,
that doesn't have value.
Giving it some other way of labeling it,
that may have value.
This is a discussion that we're having
with the community in CVE,
and if you have thoughts on that,
we'd love to hear them.
And again, the vulnerability must be public.
One example where this is not the case
is we don't want CVEs to be used
for internal bug tracking,
for code commit,
and so you find a bug.
You don't want to issue a CVID
if you're going to fix it that night
and it'll be gone and it was never seen
by the general public.
Again, there's no value there.
It's only valuable if it's out in the world
and people need to talk about it
and know about it.
Questions?
Let's say it's an old proprietary bit of code
that the community can't affect,
the code, right?
They can't patch it,
the company's out of business, whatever.
They can mitigate the risk, though.
Either turn it off
or put a firewall in front of it
or whatever they have to do to mitigate that risk.
So in that case, yes,
we would have probably assigned to it.
Even if the company doesn't exist anymore,
the vulnerability exists
because the consumer can do something about it.
Not necessarily
as much as they'd like,
but there's something that can be done.
So, all of that
discussion boils down to
this one bullet.
How do you get a CVID?
You go to that website.
Thank you, good night.
It is just that easy.
It's mostly that easy.
There's a form there
and an injection strip.
No, no, there's a form there
and the form asks for specific bits of information.
There is a minimum set of information
we need to start the process.
We need to have a general idea
of what the vulnerability type is.
Now, there isn't a list
of canonical vulnerability types.
Like the definition
for vulnerability,
there's tons of different ways
to cut vulnerability types.
But you just need to describe it.
Buffer overflow,
cross-site scripting,
things like that.
Common terms, that's good enough.
If you want to get into more depth, you can.
We need to know what the product and vendor is
or the project that's affected.
You need to tell us what you found the bug in.
And also the version information.
You need to be clear on
when you talk about version
what you're talking about.
You can't just say all versions
because what if
a new version came out tomorrow?
Would that still be true?
So you want to be very explicit
if it's all versions prior to 1.1.1
or only version 2.5.
If you've only seen the vulnerability
in one particular version
and you don't know about the rest,
just tell us about that one particular version.
You could always update it later.
So that's what we require
to start the process.
If you have other information,
like we were talking earlier,
please give it to us. We'll take it.
Anything that helps
describe the vulnerability.
We don't care
as far as whether it's a vulnerability or not
about things like impact
or the attack vectors.
NVD does and other vulnerability databases do
because that's enriched
information about the vulnerabilities.
But
that helps us understand that
this is a unique vulnerability
because we can compare it with other things
that might be out there.
And also it helps with the counting question.
And public references are always great.
Again, in order for this to be public
on our website,
you have to have public references.
Now if you don't have them yet,
that's okay. You can still submit.
Again, the minimum is up here.
But if you do already have something public
or you found somebody's research
and hey, that should get a CVID,
that's a public reference, that works too.
Okay?
Now, any questions about that?
Yeah?
.
.
So, like I said before,
we traffic only in public information
when possible.
So we do have an embargo policy on our website.
The embargo policy basically says
if you give us information,
we're not going to share it
until the information is made public.
So we actually do sometimes receive information
that isn't in the references.
We publish that information.
But if someone gives us something
and says that it's public
or will be public,
then we'll publish it along with everything else.
We try to stay out of the embargo world, though.
If you're giving us something
that's under embargo
that's not public yet,
we'll take very good care of it,
I swear.
We'll treat it like our own baby.
But again, we don't want to be like
having tons and tons of zero days
just sitting there waiting for people to get to them.
We want to encourage them to get public
as fast as possible.
But we don't.
We have, there's a lot of sausage making
in the background.
The stuff that comes in,
it gets stored off the internet.
In quotes.
The stuff that's on our public website,
there's nothing there that isn't public.
Does that make sense?
And also, by the way,
you can always PGP encrypt it.
If you don't trust how we store it,
that helps a little bit.
But you can do that as an extra bonus
if you want to.
Yeah?
They suck.
Yeah.
Right.
So again, we have an escalation process for that.
So you go to the vendor,
CNA or not,
and you say, hey, I found this bug.
The escalation process only matters if there's CNA.
If you go to the vendor and the vendor says,
that ain't nothing,
you come to us and we give you a CVID
if it follows the counting rules and works.
If it's a CNA, there's a disagreement.
If they sit on it for too long,
if they break their embargo policy,
because some of the vendors say,
it may take up to nine months before you hear anything from us
because we have to analyze this.
You've got to respect that.
Or at least we have to respect that.
We can't stop you.
But we will listen to what our vendors say.
But the minute they break their promise,
you come to us.
And we say, okay, what's the deal?
And we will push it to some kind of resolution.
We're not,
we're going to act as a third party.
We don't,
we want the information to be out there
if it's supposed to be out there.
So we'll do what we can
to understand the situation
and satisfy,
what's best for everybody.
Don't let your vulnerability requests
fall into a hole.
Or your vulnerability disclosures fall into a hole.
We're not a coordination center.
We have friends who are.
If it's a really big deal,
we can go talk to CertCC and say,
hey guys, are you aware of this thing?
But we can also pressure our CNAs
because we do have expectations,
community expectations.
And if they don't follow those community expectations,
we can take them out.
No matter the size.
We've had some very hard discussions
with some of the bigger vendors about this.
So what happens after that?
Sausage.
There's a lot of sausage being made in the background.
But what you see is that you'll get,
when you email,
if you use the web form,
you'll get an email response with a ticket number.
This should seem like nothing unusual
if you've ever used any kind of help desk system.
We take that information,
we review it.
If there's enough information in what you've given us
to assign it,
the content team will say,
here's the CV ID you're going to use.
If it's a CNA covered product,
it goes to the CNA.
Or we help you redirect them.
We don't actually take,
so back to what you were saying,
we don't take that information and forward it.
We'll get back to you and say,
you need to talk to the CNA.
So that way,
if you disclose something that's super sensitive to us,
but you are reluctant to talk to the vendor,
we'll encourage you to reach out to the vendor
and coordinate with them.
We're not going to pass the information
that you've passed us to them.
So we want to keep that,
if there's a concern about sensitivity,
we try to keep that control in your hands.
But if you give us enough information
that not only is it available
as a valid CV ID request
or a valid vulnerability,
and we have all the information we need,
we'll publish it.
We'll just send it up in the database.
Until it is published in our database,
it is marked as reserved.
You've seen this, I'm sure.
You've looked at a CV ID in the CV list
and it just says reserved.
Why?
It's reserved because we don't have enough information
to publish it in our database.
We either don't have the public references
or the information that we've been given
by whoever requested it
was not enough to say,
yes, this is a unique vulnerability.
That's why you see so many of these.
A lot of times people come to us
and they say,
I need a vulnerability for X, Y, and Z.
And we get those first three things,
but that's not enough.
You need the references to publish.
So they get this and they go off
and then they post it on their blog somewhere,
but they never got back to us
with more information.
They never clarified, they never gave us a reference.
So we don't publish until we have that.
So if you see something
and you know there's public information about it,
you can tell us
and we will immediately get it published
if that's what we needed.
And we'll talk about that in a second.
So at this point, again,
it's reserved unless it has enough information.
It is going to stay reserved
until it has been populated.
So,
if you're disclosing something,
you need to notify us
when it's public.
We won't know.
We have some web scrapers out there.
We're trying to find this information proactively.
It's really hard.
Stuff gets published all over the place
and we don't know to necessarily look for it.
We're trying to improve that,
but we need to rely on the community
to tell us when the work they've done
is ready for publication,
ready to be published.
Again, if you have an embargo,
that's fine.
When the embargo ends, though,
you've got to let us know.
We have no idea whether it's under embargo
because we're not part of the embargo.
So you've got to tell us.
So again, as I said,
once we have that public reference
and we have enough information to know
it's a unique ID, it gets published.
And congratulations, you can put it on your resume.
Pretty straightforward.
It actually isn't.
It goes on in the background.
A lot of coordination.
The disclosure processes will vary.
If you are in this business,
if you're doing this regularly,
there are ways to shortcut this
where you can send us information more effectively,
more efficiently.
We can talk about that if you're interested in that.
But if you're just looking for one-offs here and there,
you just have to remember that we need to know
what you know.
We need to know when you're going public,
when you're publishing information.
Okay, we're running a little low on time.
Yeah, we're almost out.
So for,
we're running a little low on time.
So for,
when you come back to us to let us know
to publish what you have,
we kind of encourage you to supply us
with like a description of your research
because you guys know the source code
and you know the research better than we do.
And so we kind of have some things
that are necessary to be in it.
So if you go to our public list
and you'll see that in the description
you'll see that there has to be a product
the version problem type
is described in the description.
And then we also have
wanted to note that
we only publish information that's
that is already public in that
public reference that you give us.
And so any information, any additional information
you may have given us in the request phase
will not be published when you
request your publish
request us to publish the ID.
We only publish information that is reflected
in the reference.
So that's another thing to take note of.
And then we only want relevant information on it.
So we don't want any profanity,
no marketing in the descriptions.
Just things that are relevant
to the vulnerabilities
what we want to have published
in the public list.
No profanity in the description.
And then lastly it has to be in English.
When you send it to the primary CNA.
There are other organizations
such as JPCert
that are looking to be able to
translate for you guys
from whatever language they have to English
when they send it to us.
If you don't have a kind of style
this is what MITRE uses.
These are two templates.
We actually have a public presentation
you guys can actually look at
which will give you more information
on how we do things like
how do we describe versioning,
product types, vulnerability types.
So that's publicly available with examples
if you want to look into
providing this kind of style
when you submit for a publication request.
Just really quick.
As I mentioned we need help
with the updating of this information.
If you see something that needs updating
even if it's not your vulnerability
not something that you found
but you have information
you'd like to see it in there.
Certainly for example the US government
they look at CVE as a source
of what their risk is.
So if they look at our list and say
there's no other information
it's a problem.
They can't do their proper risk assessment
based on our information.
But if they see that there is a public reference
they can let us know
we can publish it
and not only do they benefit
because it works into their own system
the whole community benefits.
It just helps the program be a little more robust.
So you see something
you can update it.
If you see something
and it looks wrong
you can dispute it.
We have a dispute process.
CNA or not
you can dispute anything.
It just shows up typically as a dispute
in the list but it helps enrich
that information.
And before
we finish up
so
we don't care about attribution.
Like I just said
you can send us information whether or not
you discovered a vulnerability.
We don't include credit or attribution
as part of a CV entry.
We're not in that business.
You can send us a reference
and that reference can be a blog post
that says I found this vulnerability.
Great, we'll add it to the thing.
But we're not going to put it in the entry.
We're more interested in these vulnerabilities
getting disclosed
and the information getting out there
than we are about padding people's resumes.
That's not our focus.
It's a nice side benefit
but it's not our focus.
You typically aren't going to see
attribution in a CV entry
and that's why.
For CNAs we will be attributing
which CNA might have
submitted a CV entry
just so you know that
this Apache vulnerability
description was written by
Apache as opposed to written by
somebody else.
But that's as far as
we will go for attribution.
We don't care.
That said
we understand that's a use case.
It's part of what the community
gets out of CVE.
If you value CVE
if you think it is useful
if you think it helps make
your life as a vulnerability researcher
as a defender better
we need your help.
We're trying the best we can.
Throughput is a big problem.
We're doing much better.
We're actually on track to have
twice as many CVEs this year
that's probably around
what was it last year?
I think almost 20,000
we're on track for.
That's a lot.
And still not all the vulnerabilities
that are out there.
And not all the vulnerabilities that are out there
across all the different
verticals.
If you're really into automotive
vulnerabilities
just send us what you got.
We can start building this into
the vulnerability management disclosure processes
and hopefully this little part
will help jumpstart the culture
that needs to be out there of disclosing
responsibly or coordinatedly
or however you want to disclose
so that everybody is in a better shape afterwards.
If you're going to take a picture
take a picture here.
It's all the links that we've talked about.
The CNA rules
include the counting rules
if you want to see what the
gory details of counting look like.
So
this is a good slide to grab.
And we're out of time.
So I'm going to
Anthony and I will be out there
as soon as we clean up our laptops
and if you have any questions
please come out and talk to us.
Otherwise, thank you very much for your attention
and enjoy your time at DEF CON.
We have time for questions.
Feel free to come up to the mic
and ask away.
Come on, yeah, come on
to the mic.
No? Alright. Hi.
Hi. Is the DWF
are they considered a CNA now?
Yes, the DWF is a CNA.
Okay, so quick history on the DWF.
The DWF is the distributed
weakness filing. It is also
one letter off from CVE.
That's all them. I had nothing to do with that.
So anyway, what is the DWF?
The DWF is a CNA that covers
all open source software
that is not already covered
by somebody else.
CNAs all have scope.
They all have the thing that they cover.
So the DWF is sort of a blanket.
They cover everything.
Now, they're less than a year old
and they are in the process
of spinning up their operations.
It takes a lot to run this thing
even when you're relying on
the open source community to help you.
So when you have
an open source vulnerability
you can go to the DWF.
You can do a pull request. It is based
of GitHub. You can do a pull request.
You can add your information in there.
I think actually
first you have to request the CVID
through their web form. They have a separate
web form. They're working on
a lot of processes that I know
some people have had trouble getting CVIDs
from them.
You can contact us and we'll make sure
you get a CVID. Again, all of
open source is covered. The DWF
hopefully once they're up to speed operationally
they'll be covering all of that.
We can send people that way and they can get it through there.
Until then, and even after
then, you can always come to MITRE if you have
a CVID request and we will
help you fulfill it. The goal
was open source is big.
One way to federate this out, to scale
it out is to just get another entity that can
focus on it and use a lot of different
tools that we may not have access to.
They're working on it. They're trying.
Yay open source.
Yeah, go ahead.
Can you come up to
the mic?
I'll repeat it.
You can download the entire corpus.
It's on our website.
You can always do that.
Josh Bressers, who
works at Elastic, he recently
joined Elastic and he's
been playing with all sorts of data. He took the
full data set and he's doing some really cool stuff
with visualization,
looking at statistics and things like that.
If you look for him on Twitter,
Josh Bressers, talk to me afterwards.
I can hook you up.
He actually just posted a few things
about it recently.
He'll be posting to his blog about it.
He also runs the open source security podcast.
I don't know if you've heard of that.
That data set is available.
Speaking of that, we're hoping to have more
metadata available for people to
learn more about what we're seeing
as information is coming in.
Again, nothing private, but just
meta information based on
the type of vulnerabilities that are coming in,
how they're coming in, things like that.
We're going to post that to the website and have that
available in a way that's
useful, hopefully.
Keep note. Counting vulnerabilities
is a black art.
The number of
CVEs that a product has says
nothing about the security of that product.
The number of CVEs that you have
squashed says nothing about how good
you are at being a security person.
Be very careful when you're counting vulnerabilities.
We count one way, a different
vulnerability database counts different.
You need to remember that when you're
looking at numbers and statistics.
You can only really compare us to ourselves.
You can't compare us to other people.
If you've ever heard any
talks from Josh Corman with
I Am The Calvary, he has a really good visualization
of this.
He's talked a lot about it. He's been very critical of
CVE in a good way.
We like Josh because he's saying,
look, vulnerability management is a big deal.
CVE is trying real hard and they're not
getting it, and the rest of the community,
they're not getting it. Hey, Congress,
let's do some better stuff, especially about
medical device security.
There's a lot of good information there from
the I Am The Calvary folk, and again,
Josh Pressure is another good source.
We'll give you some more information too in the future.
Any other questions?
For one more time,
Dan and Anthony, everyone.