In this episode, we're going to go back into risk management and discuss how that intersects with vulnerability
management.
Vulnerability management, along with risk management is kind of the caveat of what you really do as
a cybersecurity analyst.
You're constantly moving back and judging, hey, how risky is this versus the vulnerabilities that
coincide with the different systems that you usually use?
Risk and vulnerability management really make up the core of every cybersecurity analyst.
And we're going to discover that today.
If you remember from our previous lectures, risk management really corresponds into five main points.
Identification of the risk assessment of how dangerous that risk really is.
Prioritization of how difficult or how contagious or how impactful that risk is in order to be fixed
within your own organization i.e., should this risk or this problem face up a higher priority to be
fixed versus a lower priority?
What the mitigation factors are.
Can I mitigate that risk to do a lower priority or have less impact on our company?
And finally, a review of the different risks that are associated with it.
We're not going to go solely into risk management today, but I wanted to touch back on to it of previous
lectures.
So you get a good sense of where we're coming from.
Risk equals threats multiplied by vulnerabilities, meaning that if I have zero vulnerabilities, but
I have a lot of threats, there is no risk.
Meaning I may have threats, but again, if there's nothing for them to actually impact or nothing for
them to exploit, then I really don't have any risk.
On the flip side, although much rarer if I have a vulnerability, but there are no threats, then again,
I have no risk.
There's little windows vulnerabilities that we discovered from windows XP way back in the day.
We knew that the vulnerability existed, but at the time, the technology to exploit those vulnerabilities
was near zero, meaning there really were no threats that could take advantage of those vulnerabilities,
meaning there was no risk.
We saw that in those lower windows systems.
However, if I took a windows XP machine today and I have those same vulnerabilities, we have more
than enough technology to exploit those vulnerabilities.
Meaning there is a high risk if you're using windows XP.
This comes into play with understanding risk at its most fundamental level.
Threats times vulnerabilities equals risk, and I've seen other acronyms or further algorithms that
come in.
And they say threats plus vulnerabilities equals risk.
But that's not really the case.
It really is that multiplication that comes into play.
Because if I have threats, but I have zero vulnerabilities with the addition factor, then I still
have a risk and that's just not the case.
I must have both threats and vulnerabilities in order to have risk.
Vulnerability management really starts with the different aspects of understanding your network as a
whole.
I must understand my network and to do that I must have an inventory of every machine, whether it's
a windows box or an IPS, IDs, a router, even a switch.
Heck, even if I have a hub in my system, that's part of my intrinsic networking infrastructure and
I need to be aware of that.
Having a good inventory of your systems really provides you a detailed understanding of all the different
vulnerabilities that could, in fact, be on your network.
When I worked with a telecommunications company one time, we had all this equipment rolled out, and
a lot of times we didn't know what we actually had in our systems.
So we had these very complex switches and microwave radios.
We had some great telecommunications equipment, but we had other inventory that we had no idea was
there.
It just worked.
And unless the technician that was on site went there and actually physically put eyes on it, we had
no idea that machinery was there.
This is a very sad and poor way in order to understand your vulnerabilities associated with your different
networks.
Now the argument was always made, oh well, you have to actually know how to use the equipment.
You have to know what the equipment was, because some of this equipment in telecom was literally 30
or 40 years old.
So most people would look at it and have no idea what they were looking at.
But that's not real security, that's obscurity through obscurity.
And if we're doing security through obscurity, that's not real security.
It's just make believe.
So you must have that inventory.
You must understand everything that's in your network and have a detailed list of it.
You should have serial numbers, makes, models and what the machine actually does, or how it interacts
with the rest of your network.
To do that, we do a lot of scanning.
Now, scanning is usually done in one, sometimes two different ways.
There's Openvas and there's Nessus.
Openvas really provides us that open source way of scanning our different networks and understanding
the different vulnerabilities that are associated with it.
And Nessus is more of the commercial grade aspect of doing the same thing.
Here you can see a screenshot of Openvas, where it's provided detailed information of what's on our
system or what's on our network.
On this screenshot, you can see the different criticalities that are associated with the different
vulnerabilities that it found.
This is a plain and simple vulnerability management at its core level.
And your systems, your infrastructure should be scanned in this way every day.
Within this we can identify prioritization.
When going through the prioritization, you can see that it goes through and it provides us those most
critical levels at the very top, with maybe the lower levels at the bottom.
Within this you can see different aspects of the different vulnerabilities associated with each machine
or each IP address within our different network.
This provides us not only an inventory of every IP address associated with our network, but also different
vulnerabilities that could be linked to those specific IP addresses.
When we talk about priority.
You need to understand where it comes into play with your specific network.
Meaning, if I have a vulnerability that it's a Linux vulnerability on a windows machine, that's obviously
a false positive, meaning that the positivity of the vulnerability doesn't actually exist.
We have to go through and concentrate on the false negatives, the false positives, even the true positives
and true negatives and truly understand what's going on with our network.
This is almost a full time job by itself, and should be carefully looked at on a case by case basis,
based on the different IP addresses and structures within your internal network.
Prioritization really comes into play with understanding what really takes priority in our own network.
You can have a very complex, highly critical system vulnerability associated with your network.
And the system may be telling you, hey, knee jerk reaction, let's give it a very high priority.
However, you may know through experience and understanding of your systems and network that that vulnerability
really doesn't need a such a high critical level.
It can actually be dropped down a couple of places, and the prioritization could be resubmitted based
on that new algorithm that you utilized.
This is part of prioritization where we put logic versus common sense plus intuition.
This really comes into play with understanding your own network.
And that makes your prioritization based on logic versus intuition or gut feeling.
You know, the system of networks.
If I just wanted somebody to look at it and give me a knee jerk reaction every time and say, hey,
this needs a critical input because the machine said so.
I don't need human beings for that.
I just need a machine that runs a script to do that.
Your job as an analyst is to understand those little idiosyncrasies that communications or AI and machine
learning will never get.
This is why human beings will always rate higher than machines.
When it comes to true cyber security, patch management really makes up one of those core fundamentals
that we associate with our network scanning and our core vulnerabilities.
Within a management scheme, you should be patching your windows machines almost on a weekly basis whenever
Microsoft comes out with a new patch.
However, it's not as simple as that, and we discussed in further episodes.
Patch management really comes into play with understanding the patches that are coming into our different
networks, how they correspond with our core operating systems, and how they correspond with our existing
software.
And then we run it through a sandbox environment.
Before we push that patch forward, patch management goes into a very detailed, uh, change management
program that we need to be aware of.
But you need to also understand that that patch management is very much a part of vulnerability management.
We also need to understand configuration management.
Configuration management comes into play with if I've got a new piece of equipment am I configuring
it properly?
Did I remove the dead set username and password that came with it?
Those default username and passwords there hack.
And we know that because there have been some major telecom and cellular providers that have installed
new routers, they forgot to change those default username and passwords, and they've suffered data
breaches because of it.
Three in less than two years, if memory serves correctly, we also need to monitor our networks and
understand where everything is coming to play.
That's where a Siem comes in, and it really kind of gives us a aspect of our network as a whole and
how it crawls and analyzes women IP address to another one piece of equipment over another, and gives
us that really holistic view of our entire network.
If we can't fix something, we need to mitigate it.
We can mitigate through different hardware and software ramifications.
We can go through and say, hey, if this vulnerability is there and I can't patch it, I can't fix
it, how can I mitigate it?
Mitigation should be at the top of our list when it comes to different vulnerabilities that we can't
have a direct fix for.
And finally, documentation.
We want to document everything.
If you're an OCD person that loves documenting everything that you touch, this is probably the best
job for you.
We literally have to document as much as we possibly can.
I want you to imagine yourself in a small office with lots of equipment, a lot of heck going on, and
you've got just things going on left, right and sideways.
You've got multiple machines, multiple monitors, not enough manpower.
You really are trying to put out fires one after another.
And part of that is documentation, because with proper documentation, I can figure out what another
technician did, even if they were gone for six months or a year or even yesterday.
This is the problem that we see a lot as a cybersecurity analyst is a lack of documentation, meaning
they don't write down everything they did.
They don't document, hey, the IP address that I associated with this, I did this.
If I did this, then I need to document it.
Documentation really is one of the most profound things that you can do as a cybersecurity analyst.
And as you go higher and higher in your career field, you need to document more and more.
We need to document in detail.
Now, I could beat this horse dead until it was dead 100 times, but documentation, documentation,
documentation is one of those things that you need to do as a cybersecurity analyst.
Throughout this episode, we talked about risk management very briefly, but we also talked more importantly
about how it intersects with vulnerability management.
Vulnerability management is really at the core of what a cybersecurity analyst does.
We find vulnerabilities and we attempt to fix them.
If we can't fix them, we mitigate them.
If we can't mitigate them, then we've got some problems.
This is where your job as a cybersecurity analyst really comes into play, where the meat meets the
keyboard.
And I don't mean that figuratively.
You are really going to be pounding that keyboard a lot in your job as a cybersecurity analyst for Cisa.
What do you really need to know?
You need to understand everything that we discussed about vulnerability management.
You need to understand if I've got different vulnerability levels, why do I have those vulnerability
levels?
Where do they come into play?
How can I fix those?
How do I take those ramifications versus impact versus threat versus risk and put them into one model
if you need to?
I would rewatch this video several times if you don't clearly understand it.
When it comes to vulnerability management, Cisa takes it very seriously.
This video was somewhat short, and that's all it really needed to be.
But you need to understand the core concepts of vulnerability management when it comes to your exam,
you should expect to see questions about the Cvss score and how that intersects, maybe even a prioritization
list for a different drag and drop scenario.
Expect scenario based questions talking about the different vulnerabilities and what you could do based
on something that may happen in your network.
For instance, it wouldn't be out of the question to see something where, oh well, you can't patch
the machine because you're using old legacy software.
How would you or what would be the most appropriate action for you as a cybersecurity analyst to solve
this problem?
Obviously, we want to mitigate it as much as possible.
Don't expect to see a lot of technical questions that come into play.
You're not going to see questions like, oh, well, you know, it's legacy software.
So you need to add an IDs and a firewall and a router.
But do expect to see questions that are high level talking about what factors you should go into.
Should I mitigate it?
Should I maybe do risk transference?
What could you do as a cybersecurity analyst to solve that specific problem at a high level?