- Welcome to Lesson 16: Explain Various Activities
Associated with Vulnerability Management.
Now, in this lesson, 16.1,
we're gonna start with talking about
vulnerability identification.
We'll review what a vulnerability is,
and we're gonna then really look closely at
what are all the ways that we can identify vulnerabilities,
which is certainly the starting point
in vulnerability management.
And just as a review, a vulnerability is a weakness
in a system, hardware, software, process, person,
building, infrastructure, right, that can be exploited.
It's a weakness that can be exploited.
Now, another term that's gonna come up
as we're talking about our vulnerabilities is exposure.
The term exposure means a system
or software configuration issue or lack of a control
that could contribute to a successful exploit or compromise,
and one more refresher about our zero-day vulnerabilities.
A zero-day vulnerability refers to a vulnerability
that is actively being exploited by attackers
before the vendor has an opportunity
to develop or release a patch or fix for it.
Now, the term zero-day really is used just to indicate
that there was no notice or advanced warning given
to the software vendor or the public about the vulnerability
before it began to be exploited.
Now, our attackers we know go right after these, right?
The attackers aim to exploit the vulnerability
before it becomes widely known and patched,
maximizing their opportunity to compromise systems,
but as soon as we know about a zero-day vulnerability,
we need to take action,
and that action will be determining
what the impact might be to our organization, right,
if that vulnerability was exploited
and what additional controls we can put in place
until such time that a fix is available.
How are new vulnerabilities discovered?
Well, organizations are, you know,
continually doing research on their own code,
but many organizations also offer
what's known as a bug bounty problem.
No. (laughing)
Many organizations also offer
what is known as a bug bounty program.
It's also known as a VRP,
which is a vulnerability rewards program,
and that's an incentive program that compensates individuals
for identifying and reporting vulnerabilities, aka bugs.
Now, there are two types of bug bounty programs.
There are open bug bounties and closed bug bounties.
Open bug bounty programs are offered
by hundreds of companies,
including Google and Microsoft and Facebook.
A closed bug bounty program is by invitation only.
Now, if a vulnerability is discovered
in third-party software or hardware
by you or by someone in your organization
or by someone who you hired to come in
and do a vulnerability assessment or a pen test,
best practices dictate notifying the vendor directly.
So you've reached out to the vendor.
You've said, "We found this vulnerability,"
or this issue, this exposure,
and hopefully they respond and say,
"Great. We're on it and we'll keep you updated."
And maybe they'll even give you a little reward or,
you know, at least an acknowledgement,
but if you don't hear from them, so if you have no response,
or you have an inadequate response is forthcoming,
here in the US, vulnerabilities can be sent
to U.S. CERT Coordination Center,
and CERT/CC will then forward the report to the vendor,
and this is from their policy.
They say, "Vulnerabilities reported to CERT/CC
will be disclosed to the public
45 days after the initial report
regardless of the existence or availability of patches
or workarounds from affected vendors."
Then they go on to say,
"Extenuating circumstances," kind of dot, dot, dot,
"may result in either earlier or later disclosure,"
and you can read more about the policy
by just going to the link that you see on your screen.
Now, we really should let everybody know,
right, about vulnerabilities.
It shouldn't be a secret, but, you know,
sometimes it's a little disconcerting for an organization
to release information about a vulnerability
because they don't wanna take the reputation hit,
but our good organizations, our ethical organizations know
that this is really the right thing to do.
So ethical disclosure, which we've talked about earlier,
is the practice of publishing information related
to a vulnerability or finding,
and the purpose is to inform others of potential risks
so they can make informed decisions
and take appropriate action.
Now, full disclosure about a vulnerability
is making all details public without regard
to the additional harm that may be caused to others,
including exploits by adversaries.
At first blush, it's like,
"Oh, no, we should never do full disclosure,"
but there may be valid reasons for full disclosure.
The second is responsible disclosure,
and responsible disclosure is making
just enough information known so that informed decisions
can be made without releasing details
that could be useful to an adversary,
but, you know, the discussion that comes up a lot
about responsible disclosure is,
who's really making that decision,
you know, about what should be disclosed
and are they truly disclosing the right thing?
So there's a lot of conversation in our industry
about full disclosure versus responsible disclosure.
Now, where can you go to find out about vulnerabilities?
Well, there's this fantastic program
known as the CVE Program.
The CVE Program is an international, community-driven effort
to catalog hardware and software vulnerabilities
for public access.
Now, a CVE, Common Vulnerabilities and Exposure,
is a standardized identifier
for a given vulnerability or exposure.
Now, the CVE records are maintained
in the CVE Program catalog, and as of May 2023,
there were 202,679 records.
Now, the use of a CVE ensures that two or more parties
can confidently refer to a CVE identifier
when discussing or sharing information
about a unique vulnerability,
and they know they're talking about the same thing.
So where do you go to get this information?
You're gonna go out to cve.org.
Now, it used to be mitre.cve.org.
They've recently brought it over to a new website,
so cve.org.
If you have not been there before,
you definitely, definitely wanna go there.
That's where you can get information
about all current and past CVEs,
but they also have some other great publications
and a full tutorial,
both in video form and in written form,
to really understand, you know, how the CVE Program works,
how to understand CVE documentation,
and just how to make best use of the information.
So when you're looking at a CVE at cve.org,
one of the things you're gonna notice
is that there's a score,
and that score is noted as a CVSS score.
CVSS stands for Common Vulnerability Scoring System.
Now, the Common Vulnerability Scoring System
is an open framework for communicating the characteristics
and the severity of hardware and software vulnerabilities.
There are five ratings:
none, low, medium, high, and critical.
The two common uses of CVSS are calculating the severity
of vulnerabilities discovered on your own system
and as a factor in the prioritization
of your vulnerability remediation activities.
Now, the National Vulnerability Database, NVD,
provides the CVSS scores
for almost all known vulnerabilities,
and you can learn more about
the National Vulnerability Database at,
well, one of our favorite places, NIST,
National Institute of Standards and Technology,
by going to nvd.nist.gov,
and this is what a CVSS description
is gonna look like, right?
You'll go out there, you'll see the CVE,
and then you can note where it says severity.
Right over here, you can see severity,
and then it's going to give you
the various severity ratings,
as well as information about characteristics.
So this is going out to nvd.nist.gov,
but you can link directly to this from cve.org.
So when you bring up a CVE,
there'll be a hyperlink that will take you
right to the NVD, the National Vulnerability Database,
to give you the scoring information.
Now, once you're there, I want you to look around
because the NVD is also a really,
really great source of information.
One of the things they have is this dashboard,
the NVD dashboard that tells you about
CVEs received and processed and status count
and scoring distribution and just so many other things
that really you're gonna find really interesting,
truly interesting, and of course,
just like there was in the cve.org site,
there's a great tutorial.
So go there. You know, just look around.
Get familiar with it, and definitely take the tutorial
so you become more familiar with how to use
the National Vulnerability Database.
And that, my friends, brings us to a three-second challenge.
Five challenge questions, three seconds each.
Let's do it.
Hardware or software weakness
that can potentially be exploited.
This is an easy one. One, two, three.
That's a vulnerability.
When there's no notice or advance warning
about a vulnerability before it begins to be exploited.
What do we call that type of vulnerability?
One, two, three. It's very dangerous type.
That's gonna be our zero-day.
Number 3, a standardized identifier
for a given vulnerability or exposure.
One, two, three.
That's gonna be the CVE.
Number 4, scoring system used to communicate
the severity of vulnerabilities.
One, two, three,
and that's gonna be the CVSS, and lastly, number 5,
an incentive program that compensates individuals
for identifying and reporting vulnerabilities.
One, two, three, and that's gonna be a bug bounty.
That brings us to a Security-in-Action
about a vulnerability discovery.
During a routine penetration test,
a serious vulnerability was discovered in the COTS,
that stands for commercial-off-the-shelf, application.
You researched the issue,
and you found no related CVE or CVSS entry.
You reached out to the vendor multiple times
by phone and by email to report it,
but they haven't responded at all or even acknowledged,
right, in any form that there's an issue.
So my question to you is, what do you do?
Should you do nothing? Should you do something?
What are you gonna do? Put me on pause.
Think about it, how you might take action
or who you might report this to.
Well, if no response
or an inadequate response is forthcoming,
vulnerabilities can be sent
to the U.S. CERT Coordination Center.
CERT/CC will forward the report to the vendor.
Now, if CERT/CC doesn't get an adequate response,
they will publish a notification.
Now, if you belong to an ISAC,
that's an information sharing group,
or any other industry group,
you may wanna share the information on a confidential basis.
So perhaps you're part of
a banking group or a hospital group,
and this vulnerability was in your banking software
or in your hospital software.
You may wanna share it on a confidential basis,
again, inside that group.
And in the meantime, right, management needs to determine
if there are adequate compensating controls,
and if not, is this vulnerability so severe
that we should discontinue using the software?
Because you found this vulnerability,
obviously there's no patch for it
because they haven't even acknowledged that it exists.
So now you have to say, what other controls,
what compensating controls do we also have to put in place,
right, because of this vulnerability
or is it just so significant
that maybe we really have to think about
not using this software?
Those decisions, those conversations, Security-in-Action.
There's your word cloud.
Make sure that you know all of these terms,
you can speak to them, and I would suggest,
before you move on, go out to cve.org
and go out to the National Vulnerability Database.
Take a look around.
It's a good time to do it, right now so you don't forget,
and then when you're ready, head on over to the next lesson.
I'll be waiting for you right there.