In this episode, we're going to discuss Cvss common vulnerability scoring system as well as threat
modeling.
We're going to decide or go into action with how threat modeling corresponds with the Cvss scoring and
prioritization.
When we go through these different episodes, I want you to pay close attention to the different threat
modeling frameworks that we're going to decide on.
And I also want to point out Cvss and how that can be utilized for your prioritization through different
vulnerability management that we discussed earlier.
The Common Vulnerability Scoring System, or Cvss, is currently utilizing version three.
Now.
This differs slightly from version two, as in we just put in the medium category, which wasn't used
to be there, but you just need to be aware that that's just the newer system that's being utilized.
When we talk about Cvss, it's broken in from zero through ten, with ten being the most critical and
zero being.
There's no threat whatsoever.
Very rarely are you going to see a no threat or a zero whenever we see a your vulnerability.
Matter of fact, I don't think I've seen one ever in my entire time as a cybersecurity expert.
At the critical level, you usually have root level access, which is easily accessible and requires
an immediate response.
We identify this as anything from 9.0 all the way to 10.0, and has different variations based on what
you're looking for.
The important part here for critical level is that root level access that is easily accessible.
If we take impact and we multiply it by EAS, then we get our Cvss score.
That's the easiest way to explain it.
So I have something that's very easy to access, i.e. a tool that's on a MSF venom, or maybe Metasploitable,
and that tool is able to use on a live system that gains root access.
That will give us a very high score, because it doesn't take a lot of technical knowledge or knowledge
of the system in order to exploit that problem.
This is where a majority of our prioritization is going to come into play.
They recommend an immediate response when it comes to something in the 9.0 to 10.0 atmosphere of a cvss
escort.
Now I want to point out that we also want to utilize a little bit of common sense in here.
If we just took the pure logic of the scoring system, then we really wouldn't need cybersecurity analysts.
You need to remember that you're an expert in your field.
If I've got something that is a window based vulnerability, but the vulnerability is only for a Linux
based system, then we have a false positive.
And you as a cybersecurity expert, need to be able to go in and annotate.
That is a false positive and doesn't need to be looked at.
You'll see little problems and idiosyncrasies as you become more and more experienced with the analyst
process, but while it's one of the big ones, next we have high.
Now, high means usually that we have escalated privileges with the vulnerability.
You have to have some technical knowledge and they recommend within four weeks that we fix this problem.
Now that's a big jump from an immediate response, i.e. something really bad is going to happen.
So we have to fix it now versus four weeks from now with an escalated privileges.
This usually doesn't provide us root access, but it does mean that they have some administrative control
and they have to use some technical skill to actually get into it.
However, you could have something with root level access that has some technical skill.
It's not an all or none atmosphere, so be aware of that when you're looking through Cvss scores.
Then we have a medium.
This provides us limited access or requires knowledge in order to exploit the problem.
This usually means that I've got something that has limited access.
They don't really have admin access, but maybe they can log in as the user and do some damage to the
machines or the network.
It also has some required knowledge requirements, meaning you're not going to get somebody that just
is fresh off the boat.
Never seen a computer before being able to access this.
Your script kiddies usually are going to be writing on those medium access, but again, it does come
in different flavors.
I could have limited access with easy accessible usually would denote a high, but maybe a very high
on the medium charts.
Then we have low.
Low is usually minimal business impact meaning that there yes there's a vulnerability, but if somebody
gets access to it, they're really not going to be able to affect systems.
Maybe they can read data and the data isn't sensitive.
So yeah, it's a problem, but it's not a big problem.
This also usually requires physical access, meaning that the user or the malicious actor has to physically
be able to access our machines, either through a port or through the keyboard itself.
This is where the Loa comes into play.
Now, in terms of exploitation, they can also have something that requires root access, but usually
require a physical access as well, and may score into the medium to high range depending on the different
level or access or ease of usability.
Once they give physical access, it's important to note that Cvss has.
Scoring system is an arbitrary system.
It really is in the eyes of the beholder and what they feel at the time.
When that comes into play, you may have somebody that views a vulnerability or a problem with a high
impact different than somebody else.
This is the problem.
And the best thing about a cvss score, which means that it's arbitrary.
You really have to take your grain of salt into it, and you have to use some common sense when negotiating
the cvss scoring system.
However, with that said as an analyst, you may be called into question if you see a high CVS score
that you didn't have a knee jerk reaction to.
Managers that don't truly understand cybersecurity always go to that number as a predetermined range
that they want to fix first.
This is also a problem.
It could also lead you to additional confines as well.
But be aware of that.
Your job as a cybersecurity analyst is to understand the technical perspectives of those scores, and
how they interplay with the systems that you have within your network, but also be able to speak as
a business analyst and go through and go, yes, it's a critical, but it's not that critical to a system.
And here's why.
Be prepared to write those reports on this slide.
You can understand how cvss metrics or scores come into play.
They're broken into three different groups.
We have our basic method group, our temporal metric group and our environmental metric group.
Now each group is responsible for a different aspect of the Cvss scoring process.
The basic group usually includes different things like the vector, the compatibility of the impact
where the integrity comes into play, how the user interaction comes into play.
This is pure and simple.
The basics of any type of vulnerability that you may see on a system.
Then we take the temporal metric group.
This is the exploit code maturity.
How long is the code been out?
Is it something that's in our Metasploit framework that somebody just can gain easily?
Access to temporal metrics are fundamentally just what kind of ease is the environment that I'm using
for, or the tool in which I'm utilizing to break into the system?
Again, if I have a highly complex tool that somebody has to write brand new code for, and the basic
metric group is the attack vector, where it's very easy to go through port SSH 22 to gain access into
the system.
We may have a higher or lower cvss score based on that algorithm.
Easy to get access to the system, but very high code.
Probably land us somewhere in the middle.
Finally we have the environmental metric group.
This is the confidentiality, integrity and availability and modified base metric.
When it comes into play, meaning that I could have a basic metric group plus a temporal metric group.
But I also need to include that environmental.
Environmental metric group, meaning that if it's impacting my integrity of my data, maybe the confidentiality
of my data, or the availability of my networks or systems, and at what level they're impacting those
different aspects as well.
If I've got something that is hard to to access with an ease of vector, meaning that the attack vector
could be on that port 22 we talked about.
But it takes a lot of good scripting and coding to actually pull this code off or this attack off,
and then it affects my, I don't know, availability by 1%.
That may land us on a low Cvss score if I flip that around and we said, well, it affects my availability
because it is a denial of service attack and they can knock the entire network off the ground, maybe
that moves that low up to a medium or even a high level.
Understanding these three basic, basic metric groups associated with Cvss scoring isn't really required
at an in-depth level, but you should have a high level understanding.
Understanding the basic, the temporal and the environmental and what those constitute on each level.
Threat modeling comes at different aspects of where our threat comes into play.
That means if I have a threat, I need to identify the capability, the attack vector and surface that
they're most likely to come on.
The likelihood of that attack coming into play and what impact it has.
Now, we kind of touched on this a little bit with our Cvss scoring metric, but you need to understand
it from a threat modeling aspect as well.
Capability of a threat.
How capable is the threat that we're coming into play?
Is it a script kiddie or an apt?
Those matter when we're looking at different threats and threat modeling.
What's the attack surface?
Is it a windows machine or a Linux machine?
Maybe it's a mac, maybe it's a firewall of a specific vendor that we don't even have in our network.
What vector are they utilizing and does it have to be physical, i.e. in person, or can it be over
a simple port like HTTP?
We need to understand the threat vector or the attack vector that this threat is most likely to utilize.
What's the likelihood of this threat taking place?
Is it as an easy threat?
I.e. if it's a script kiddie and there's a tool already out for there, and all they have to do is press
the enter button after punching enter IP address.
Probably a very high likelihood.
However, again, if we have to do high scripting and they have to program the tool themselves, probably
a very unlikely likelihood.
And then finally impact.
What's the impact of all of our network infrastructure.
Is it going to take down our entire system or is it barely going to be touched?
That impact really comes into play on different levels.
Are they able to utilize a tool with a high likelihood of easy attack vector?
Maybe the attack surface is our entire network, and the capability of the attacker is very high because
it's an easily, readily available tool that a script kiddie might use, then our impact is very low.
Well, that means to a high likelihood, but low impact.
When we talk about threat modeling, you need to understand from a cybersecurity analytical point of
view that threat modeling encompasses how busy or how in depth we need to be with our threat hunting.
Meaning that if I have a very complex virus that's going to go into our system, but it takes a lot
of fortitude, a lot of, uh, of technical knowledge that its impact is quite low and the likelihood
is quite low.
Then my Cvss score would also be quite low.
But we're looking at from a diverse perspective.
Without that cvss score, I need to make an intellectual decision on how much we go into that threat
as far as defensive structure comes into play.
When you're going about threat modeling, understand that as a cybersecurity analyst, you need to understand
your threats from an intrinsic level.
This is where understanding your network, your capabilities, your mitigations, and your impact to
your systems based on those different vulnerabilities or threats really comes into play.
This is what separates the experts from the novices.
Within threat modeling, we have two basic frameworks that you need to be familiar with.
The first one is stride.
This was developed by Microsoft several years ago and is still is used today.
And it stands for spoofing, tampering, information disclosure Denial of Service, and an elevation
of privileges.
This is fairly easy model to identify when it comes into threats, and we utilize this in such a way
that where if I see a threat, such as maybe an internal access to our systems via malware, I can go
through and say, oh, is it spoofing an IP address?
If it is, then that's something to be aware of.
What is it tampering with?
What is it interacting with?
How is it fooling around with that system?
That is something I need to be aware of.
You can literally go step by step and identify each portion of the stride model to impact how it would
utilize for threat modeling within your internal systems.
This is the pasta model.
Now this is the process for attack simulation and threat analysis.
It's a risk centric modeling framework that uses seven stages to encourage analysts to solicit input
from operations, governance, architecture, and of course, development.
This comes into play where we really want our network analysts or our security analysts to really understand
that, hey, I'm not alone in this field.
I can reach out to other experts and get their input as well.
If you're living in this little bubble within cybersecurity, you're probably going to lose track of
what's going on.
We can't be experts at everything, and this is where the pasta model really comes into play.
It really encourages you as an analyst to reach out and go, hey, I see this problem operations.
Have you seen this before?
What are you doing on your end?
What do you think?
What about governance?
What about the network architects and the architecture that comes into play?
How are they utilizing the different, uh, hardware within the network architecture to develop different
vulnerabilities associated with it?
And then finally, our application development, what are they doing on their side that could impact
cybersecurity?
When it comes to the pasta model, it really is all about touching bases with those different people
and those different departments to get a better picture of the cybersecurity as a whole.
Now that we've gone through the Cvss scoring and how it's implemented, I really wanted to take an opportunity
to go through and explain some of the questions that you might see on the Cisa exam, and how you need
to prepare yourself in order to answer those questions, For instance, under the first.org website
you can see a basic introduction.
And if we scroll down you can start to see how the metrics are calculated.
You can see the basic metric group, the temporal, the environmental.
And if we scroll down some more, you can see the different little abbreviations that they provide based
on each of those.
It's important that you actually read through and understand these abbreviations, because you might
have a question that literally uses those abbreviations, and you're required to pick the highest or
the most likely metric that you would tackle.
If you understand the abbreviations, it makes the question very easy.
If you don't understand it, it's like picking out a needle in a haystack.
You really don't know what you're looking at.
So as we're going through, if you scroll down a little bit more, you can see the attack vector.
And we have an N for network, an A for adjacent and L for local and a P for physical.
The attack complexity is either low or high L and H accordingly And then finally, the privilege requirements
are either N, L, or H according to what it's looking for.
Finally, user interaction it's either n or R.
So if you see a question that has a required user interaction but is considered high and you're meeting
up with that, and in comparison to say something that has a low or no user interaction with a high,
which one would be more likely for you to spend your time on?
Well, obviously having no user interaction compared to a required user action, we would go after the
no user interaction as our primary purpose, right?
And so it's really important for you to be able to look at these abbreviations and then accordingly
answer questions corresponding to them.
So again it's not as simple as just saying UI as in user interaction.
You'll literally see something that says UI colon.
And then n or R Or you might see something that says PR colon, and then it may have an N and L or an
H, and you need to be able to read that in order to answer the questions that may be posed on the Cysa
exam.
Same with confidentiality, integrity and availability.
So be aware that while I've only covered the very first portions of it in the basic metrics, you could
also see something for temporal or even environmental, and you need to know those little abbreviations
as you're going through the exam.
The other website that I wanted to show you is Nist.gov calculator, and it provides a great scenario
to kind of give it more of an easier way to look at it.
For me, I actually memorize things better when I can go through and play with it, and in this case,
I can look at the base score metrics and it pretty much provides it for me.
I can go attack the AV and then call it N, which is much, much like you would see on the basic, uh,
exam.
And so I can go through and I can play with these.
And then in the temporal metrics and environmental metrics, you could also see impact metrics and then
the impact sub score or confidentiality requirements or CR.
So as you're going through this I highly recommend that you go through this website.
Definitely play around with it.
Uh kind of see what they're asking for.
And the capabilities.
If you go in there blind, it wouldn't surprise me if you don't view it very well on those specific
exam questions.
Within this episode, we talked about Cvss scores and how they're utilized, what makes up the score,
and how those scores impact what we're trying to do.
As far as prioritization goes, we also talked about different thought modeling and how that threat
modeling imposes across us as an analyst.
And we discovered that both the stride as well as the pasta model and how those come into play with
us as a cybersecurity analyst for the Cisa exam, what you really need to take it from this is Cvss.
We really need to understand from a basic high level overview, a how those courses come into play and
where we need to utilize prioritization based on that threat modeling or based on that Cvss score.
When it comes to threat modeling, how do we impact the different threats that are impacting our different
networks and the different trends associated with it?
We need to understand how stride works, as well as the pasta model, and what separates those two models
and how we should interfere with them or interact with them.
As an analyst, you should expect to see questions on pasta, as in, hey, what are the different aspects
or departments that I might need to reach out to if I was utilizing the pasta model methodology?
You also need to look at the stride model and understand the different acronyms associated with it.
Spoofing.
So on all the way down to elevation of privileges, you need to understand cvss scoring and expect to
see again scenario based questions based on both of them.
You may see something where, hey, I've got this threat associated with my, uh, with my systems,
and it's talking about tampering with specific items.
Now, they won't use the word tampering.
They'll use a different word that means tampering.
And you're expected to know, hey, this corresponds with tampering of the T of the stride model.
Expect to see different scenario based questions on that and you should be good to go.