As you're going through your different problems within your vulnerability aspect in your report, you'll
be going, okay, I've got these little bit of problems or I've got these major problems I need to prioritize.
And in most cases, you're probably going to have a list that's three miles wide.
And thinking to yourself, how in the world am I actually going to be able to get through all these
issues that are available on my network?
Uh, on the other hand, maybe I'm completely wrong and you've only got 2 or 3.
It's not going to be 2 or 3.
It's probably going to be three miles wide of the different aspects or problems, flaws Misconfigurations
vulnerabilities associated with your network environment.
You need to be able to prioritize those, but a lot of times the priority is going to change from day
to day, if not hour to hour, as new vulnerabilities erupt on your system.
This poses a major problem.
However, we need to develop what's called an action plan.
An action plan identifies specific vulnerabilities to go through and figure out what needs to happen
with those.
Now, usually a vulnerability action actually plan isn't something that we're going through and saying,
hey, this is a critical vulnerability that needs to be fixed right now, right?
This instance, we need to fix that.
Uh, more often than not, a vulnerability action plan is something where it's like, we've got all
these vulnerabilities that are low to medium or even high, but they're not critical.
How am I going to deal with those different vulnerabilities within my system?
And we create this action plan to go, okay, here's the vulnerability.
Here's what I need to address the vulnerability.
This is what I need to do in order to preempt that vulnerability or that remediation action, that preemptive
attack.
Maybe I need to order some supplies.
I need to order this piece of equipment.
I need to do this patch.
I need to write this script because we have all of our machines have these vulnerabilities.
And honestly, going manually through them one by one will take years.
But if I write a script, it's done in a couple of hours.
So that's our vulnerability action plan.
We literally are writing the vulnerability or the problem that we see, and then we're writing a plan
of action to fix or to resolve that vulnerability.
Whether it's ordering new equipment right now, or actually fixing on it or working on it on a later
date, we're identifying what we need to happen.
Senior stock analyst or senior analyst may go through and identify to a brand new employee or somebody
that's not used to our system and go, okay, I've identified these vulnerabilities.
Here's what the alarm is.
Here's what the the problem is.
Here's what I want you to do during the graveyard shift.
That's not uncommon to see that type of action plan, whether when in a formal environment like you
see here, or an informal environment where we're really just writing it on a piece of paper and saying,
here's the alert number, here's the problem, this is what's happening so that they can learn what's
going on.
And here's the fix for it I need you to implement.
That's a vulnerability action plan tied up into a nice little bow.
Configuration management is part of that vulnerability action plan.
More often than not where we have a configuration problem within our system.
There was a specific company listed not too long ago that I'm trying to remain nameless, that had some
use of default credentials across their routers.
And because of those default credentials, we saw a vulnerability introduced where a third party, i.e.
a malicious actor, was able to go into that router and then copy all the data that was moving through
it and gain full access to different data points.
This was a problem that was invalid.
Configuration.
Part of configuration management is to identify the misconfiguration or the configuration problem in
the first place.
We need to identify that that problem and then correct it.
But before we just go in there and start correcting things, we need to back up the system.
Now we're not usually talking about a firewall or well, yeah, we are actually with a firewall, but
more like a router.
We're not really talking about those, but maybe something that has a long list of commands.
We can save that configuration or back it up.
That way if we do something to screw something up, we can go back through and restore it and start
again.
It's not uncommon when we're working with something that's in production, i.e. a piece of equipment
that we're going to change the configuration, that we back it up first.
That's the standard policy for most companies.
And there's a reason for that.
If I go in and start messing with that configuration file, yes, it should take place and it should
work properly.
But technology rarely does exactly what we want to do.
And so standard operating procedure is to back up everything before we start messing with it.
So if I go into a firewall per se, I can configure or back up that configuration file onto a USB or
on to a different file on my laptop.
I then mess around with it, and then I implement the configuration changes that I want, and then upload
them all at once while saving the original backup file for restoration if it doesn't take the way it's
supposed to.
This is basic principles of configuration backup.
We also need, however accounting control.
Now most people when they think of accounting control they're thinking, oh, I need to identify different
numbers.
Or, you know, I need to identify the finances.
That's not what we're talking about here.
We're talking about accounting, control of who did what and when.
If I go into a router or a firewall and I make a change into that configuration file, I need to be
able to annotate my name.
I should have an ID associated with any changes that I committed against that piece of equipment, or
maybe in the notes section or somewhere else.
And we need to keep a count of those different files.
I know within a company I worked for, when we made any changes to the configuration file, specifically
within telecommunications, we would go through and we would make up backfile files.
We would change the configuration.
We would then save the new configuration, which we made sure that it worked as a different file name.
So not only do we have the original, but we had the newly created backup, and then we would leave
that USB attached to the equipment via a string.
Now that string was usually about five feet long so you can maneuver it.
It wasn't in the way, and it would just hang off the server rack without any problems whatsoever.
But we had accounting control.
We would also go into the cloud environment and upload that new configuration into the cloud, so that
if that USB became lost or it got disconnected or somebody didn't have access to it, or maybe they
used it on a new piece of equipment that was literally doing the same thing as this piece of equipment.
They could just upload that configuration file and save some time.
But we kept that and we made the accountability of it.
Annotating.
This was the person, the technician, the person with the technical knowledge that changed this latest
file.
That way if something went wrong, it wasn't to blame them, it was to correct them.
This goes into that culture aspect that we talked about earlier.
Very rarely do we want to blame somebody for the flaws or the problems that they did.
Now, I'm not saying don't tell them they made a mistake.
That's not what I'm saying.
But what I am saying is we're not going to shame people into making it to where they don't want to work
there anymore.
Security experts, especially technology experts, are hard to come by.
Building them up and training them is a valuable part of any type of enterprise environment, and having
that good culture of repair and recognition and that, yeah, you made a mistake, but this is how we
fix it.
Let's do this in the future.
That's part of our everyday job.
You can't expect everybody to be perfect.
And you're going to hear me harp on this as we go through these different slides.
The other thing that we need to understand is patching.
Patching comes into play when a piece of software or a configuration or whatever needs to be updated
to the latest edition.
We talked about patching and the different aspects of patching earlier in this course, but just as
a reminder, we need to test the patching software first, then we need to implement it.
We need to have a backup plan, and then we need to be able to actually go through and uh, implement
those patches and then retest to make sure that it worked out properly on a production server.
That's the natural life cycle of a patching.
And we're going to continue that process as we go through in our vulnerability management plan.
We spoke about compensating controls earlier in this course, but just as a refresher, when it comes
to configuration management and compensating controls, I may have a configuration that's vendor specific.
And they suggest we do it this way specific way for a reason.
However, sometimes we have a piece of equipment that needs to be configured against the vendor specifications
in order to function in our enterprise environment.
This could be because we have an unusual network architecture or an older system that doesn't like the
way that the vendor has it doing.
It could be it introduces a vulnerability because of the way it interacts.
There could be a plethora of reasons to why we configure something the way we do in order in our enterprise
environment to get it to work.
And so sometimes we need to provide compensating controls to reassure that security that we would have
had if we went into the first place, how the vendor wanted us to do it.
This is where compensating controls come into play in configuration, when we're talking about different
vulnerabilities or older equipment or legacy equipment, as it's interacting with our different aspects
of our network.
Finally, we need to do awareness education training, right?
We've talked about awareness education and training before throughout this course, but I want to reemphasize
this.
Uh, training, awareness and education is more than just our, uh, low hanging fruit, right?
Our different employees, that may not be in it.
We need to understand that our IT department, as well as our cybersecurity department, needs to be
kept up to date with the latest trainings, the latest of education when it comes into our enterprise
environment.
This is because you may have somebody that's been doing cybersecurity so long that they come in with
this mindset that they know everything.
I've been doing this for 20 years.
I don't need somebody coming in and telling me how to redo it.
Technology changes.
Different ways that we implement different technologies, changes the way we implement older technology
changes.
And so making your employees go through training to understand those changes is imperative, especially
in an environment where technology is constantly changing.
Anytime you've got somebody that says, I've been doing this for so long and I don't need training,
it's time for them to go.
I mean, I hate to be that kind of guy, but if you can't keep up to date with the newest technology,
you're really of no use to the company as a whole.
And since technology changes so often, having this mindset is just it's just toxic to the entire environment.
So getting them into training, making them understand the need for training, that's imperative.
Now that's our IT and cyber teams.
But what about the rest of our enterprise environment.
What about the janitors, the help desk employees, the managers, the directors, even the C-suite?
Believe it or not, C-suite is probably the worst one to get them to take training because they don't
feel like they need to know it because they're so busy.
It's not that they don't appreciate the training, it's just they have a lot on their plate, and then
they have the authority to get away with not doing the training.
And this often poses some issues.
So we need to impress upon them the need for that training.
So they're going through and understanding the different capabilities that could happen.
You can do this in a variety of ways, but let's get back to the majority of what's going on with the
training and awareness for our average employee.
We want to do formal training, i.e. you attend a class, we want to do informal training that could
be showing up at a desk where somebody had an impromptu problem.
Maybe they clicked on a phishing link and then just explaining to them what they did wrong as a cybersecurity
specialist, and then how to correct it in the future without placing blame.
And then the third type is those reoccurring trainings where we hang posters or we do different methodologies,
or even an email that says, don't forget, we don't click on phishing links.
that kind of training.
So we really need to utilize that training measures throughout our enterprise environment as often as
possible.
Getting formal training.
You're probably not going to get away with that more than once or twice a year.
But informal training we do any time.
And those little reminders, we can do those as much as twice a week.
I really encourage you not to do twice a week.
We really kind of want to stick around to the every other week whenever possible, because then the
emails start to get ignored and then it doesn't do anything for us.
We need to look at the changing business requirements as we move through in cybersecurity.
Again, going back to that same knowledge of, oh, I've been doing this for 20 years.
I don't need to do this same thing to that same part of I don't like change.
The problem is, is that business changes very regularly, almost as often as technology changes.
You have companies that go through and they can sell needles, or they can sell bolts or they can sell
whatever.
But the overarching process changes as technology increases.
We can automate a lot of different things as it comes through.
And those changing business requirements could come into play as changing business requirements comes
into play for technology, especially cyber security.
We need to be able to incorporate those different changes within our in our enterprise environment.
If something changes, we need to resist the challenge to say, no, no, we can't do that.
You got to remember that cybersecurity is there to help companies be secure as they make money.
As soon as you become a roadblock for that enterprise environment from making money, then you then
are the problem, not the solution.
And since cyber security doesn't actually make money in a business organization, we need to perpetuate
this idea that we're there to help, even though we're there to help it make it secure.
And so with that mindset is changing.
Business requirements come into play.
We need to adapt to those changing business requirements, either with technology changes, policy changes
or whatever changes are stipulated to ensure that not only are we doing those changes the way the business
wants to do it, we're also doing it in a safe and secure manner.
And that's where we come into play.