Before the Incident: Good Cyber Hygiene and Vulnerability Management
5 hours 19 minutes
Well, congratulations. You've made it to module three with me.
Module three. We're going to talk about protecting an organization from a cyber incident.
The outline shows where we're at. We've done one and two were on three now. And how about halfway through? So we are going to get into some detailed information now is part of the I. R. Plan in life cycle
with less than 3.1 we'll talk about before the incident and what good cyber hygiene looks like and good vulnerability management.
The objectives for this lesson will be to discuss the importance of maintaining updated documentation and diagrams for IR teams, understand how to properly maintain backups, configuration files and other critical data needed during a restoration and recovery activity.
Understand how to take a risk based approach to vulnerability management.
Identify common traits of a mature vulnerability management program and will review the concept of high value assets and how they apply to vulnerability management.
Effective cyber defense requires organization period. We have to be organized and have good information available to the Cyber Incident Response Team.
Incident responders need access to critical information, and we've talked about some of this, but Now we'll talk about it a little bit more in depth.
First, updated network diagrams. That's just a must have. If you don't have those,
make sure to try and get I T or whoever is responsible for your infrastructure to draw them, even if it involves a lot of cloud. Resource is, you still need to understand where your assets are at
ports and protocols documented. You don't know what's malicious if you don't know what's normal. So having the ports and protocols on your network
identified and documented and nowhere communication should be flowing is really important.
What are the baseline and gold images? Maybe you don't have these. If not, you should look at them. But do you have a standard baseline images that's deployed two desktops or servers, for example, and if so, you should have access to those for a number of reasons, some of them will go through and then also configuration files.
Do you have a standard config that you push out to all of your routers and switches and infrastructure devices?
And if so, you want copies of those as well, and I'll talk about through the backup process, why you want this. But for now, these are the four things at a minimum you really want to have access to from an IR perspective,
when you have
configurations and backups that I just mentioned on the last slide.
This is why it's so important to know where they're at.
If you've got let's say, configurations for your routers, your switches, your firewalls, other infrastructure devices,
you want to make sure that it's a known good state. I have been on incidents before where a router was compromised and the router was actually collecting and harvesting. Credentials of the admin is logging into the router, and it was also sending traffic to a foreign I p address.
how do you restore that router? If you don't have a known good configuration? Do you just reset it and then have to go back? You have to scrap all the lines of code to try and find what's malicious and what's not. It could be a real mess, but that's why it's so important to
start with a clean image, build the things that you need to build for your implementation and then take a snapshot, download or export that CONFIG file
and save it in a secure location that other people don't have access to accept. Those that have a need to know,
have it encrypted
and also have it hashed. So using a digital fingerprint like an MD five or a Shaw, one hash of that file is also great and have those hash values stored in a separate location. And the reason for that is, is if the Attackers get into your network and they compromise your backup files
and that hash value has changed.
If they're really smart and they know that you have hash values, they could even go in and change the hash values. So you still think that you are deploying a clean image? What I did in my past was I had a vault of all of our CONFIG files for the different types of infrastructure devices we had deployed.
And then I actually had a printed list of the MD five hash values of all of those config files.
So if we had to do a restore, I could get a known good config file,
run a hash on it, make sure that hash matched the printed copy I had. If it did, I knew that no one had altered or messed with that config file, and we could push it out to the Enterprise.
Those are the types of things I'm talking about here. It's a really good idea. Of course
you want to build upon. So every, however frequently, maybe every quarter, you restore the known good. You make sure that you've got all of the changes to that known good implemented. And then you take another snapshot. You don't just want a snapshot randomly because you could be unintentionally
grabbing a compromised CONFIG file that you don't know yet is compromise. That's why you always want to start with that known good baseline.
The same is true for gold images for server implementations or desktops.
When we look at vulnerability management, we want to make sure we take a risk based approach to handling this. You can see on the slide here. I've got the vulnerabilities that are out there. We've already talked about vulnerabilities before the threats that are present.
What is your exposure as an organization? And then, really, where all of those three things come together is the risk. So,
for instance, you aren't
exposed to a vulnerability if it isn't present in your enterprise, if there's vulnerabilities out there for Server 22,000 and eight, which, of course, there are. But all of your servers, Air 2016. Then maybe you don't need to worry about that 2008 vulnerability. You have no exposure to it,
or there's vulnerabilities present that have no exploits, so it's really not a threat. No threat actor can take advantage of it.
So you have to consider all of the's things when you look at what's the true risk to your organization.
When we look further at this concept
on the slide here, you see all the disclosed vulnerabilities that air present for desktops and servers and applications, and you. I'm sure you've seen these before. But then, what are the vulnerabilities in your environment? What are the systems and applications that you are actually vulnerable from a vulnerability standpoint of, And then
of those vulnerabilities, which ones can be exploited? There's a lot of identified vulnerabilities that don't have exploits available for them
again. We want to really focus in
on what we should be worried about, and that's that overlap of the vulnerabilities you have and of those vulnerabilities Which ones can be exploited? That's where we want to focus our time and effort. And if you layer on threat intelligence, if you remember at a similar chart
that also helps identify what are you most at risk for? Within this, you can see how this quickly distills down what you should be focused on from an organization.
IR teams also need riel time access to vulnerabilities in the environment. How many low vulnerabilities are there? How many? Hi, how maney medium. What's critical? Because if you can have this kind of intelligence, it also helps your incident, response, triage and prioritization of incidents.
Because you know what you should really be worried about
and this isn't again. You don't just open wide vulnerability scan of all the devices on your network and you say we've got 30,000 vulnerabilities. How many of those are actually exploitable that we need to worry about today?
That's the number that you want to be looking at. Well, this image should look familiar to you. This is another picture duplicate slide of when I spoke to you earlier about high value assets. And before when I talked to you about high value assets. I was talking about I t asset Management, making sure that you identify
of all the assets in your environment these were the ones that are most critical to us, and we're going to consider them HV A's. Now we're talking about vulnerability management, and having that list of high value assets is going to be really important and allows you to drill down into from the previous slides. Here's all the vulnerabilities.
Here's all the vulnerabilities in my enterprise
of those. These are the only vulnerabilities that actually have exploits available to them. And then within that subset, let's look at high value assets first, so of the vulnerabilities with exploits. Now let's target high value assets that have exploitable vulnerabilities.
That is where we're going to focus our efforts both from a patch management standpoint
and an incident response standpoint to make sure that we know what our critical assets are that have vulnerabilities that can be exploited, that we need to be paying attention to
how mature vulnerability management helps. Incident response is a couple ways. It gives us visibility into the vulnerabilities. Of course, that's good to know. Also, the scoring system like Stevie SS can help. And having a written policy can be really important and how the organization deals with vulnerabilities.
If you layer on risk and high value assets, it can help target those remediation activities.
Also, looking at patch management and automation can be hugely helpful for incident response. Having metrics associated with it s performance in Patch management can be helpful in something we see in mature organisations. And then there's also third party applications to remember. So you might have a great
way to measure vulnerabilities on your Microsoft systems and your Lennox systems.
But what about all those third party tools and applications that people have installed? How are you checking to see are the current on versions or they're known exploits out there for VL See Media player for wire shark For all these other third party tools adobe
that you might have in your environment? Are you scanning for those? Are you patching those and how do you know what is out there? So that's another thing just to keep in mind.
All right, quiz question for this lesson. What are the examples of critical documentation that certain should have access to
a network diagrams
be baseline images or gold images, seaports and protocol, information or D All of the above?
Well, D All the above is the correct answer. Search should have access to everything there. One thing I didn't mention before but can be helpful is if you have known baseline images for your desktops and your servers.
One of the things that forensic people can do is create a hash value of all of those known good files and exclude those when they do an analysis. So it takes hundreds of thousands of files off the table for them. The even look at and then they convey I've into user created files and modified files.
It's a great way to reduce the complexity and time and forensic examinations.
Another quiz question. What are the three components that make up cyber risk when discussing vulnerability, management,
risk exposure and CVS s scores for a
be threats, vulnerabilities and exposures or see intelligence Sim and I DS?
The answer here is be threats, vulnerabilities and exposures are the three parts that make up,
uh, risk for vulnerability management discussions.
So in summary in this lesson, we talked about the importance of maintaining updated documentation and diagrams for IR teams. How to take a risk based approach to vulnerability management. How to properly maintain backups, configuration files and gold images for recovering restoration.
Common traits of a mature vulnerability management program in the concept of high value assets and how they apply to vulnerability management.