As you're going through your different problems
within your vulnerability aspect in your report,
you'll be going ok.
I've got these little bit of problems or I've got these major problems,
I need to prioritize.
Uh and in most cases,
you're probably going to have a list of three miles wide and thinking to yourself,
how in the world am I actually going to be able to
go through all these issues that are available on my network?
On the other hand, maybe I'm completely wrong and you've only got two or three,
it's not going to be two or three.
It's probably going to be three miles wide of the different aspects or problems,
flaws, misconfigurations,
vulnerabilities associated with your network environment.
You may need to be able to prioritize those,
but a lot of times priorities going to change from day to day,
if not hour to hour as new vulnerabilities erupt on your system,
uh 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 plan isn't something
that we're going through and saying,
hey, this is a critical vulnerability that needs to be facts right now, right?
This instance, we need to fix that
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. OK. 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 to get.
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 need to see and
then we're writing a plan of action to fix or to resolve that vulnerability,
whether it's ordering
equipment right now or actually fixing on it or working on it on a later date.
We're identifying what we need to happen. A
senior soc analysts or senior analyst may go through and identify to a
brand new employee or somebody that's not used to our system and go,
ok, I've identified these vulnerabilities.
Here's what the alarm is. Here's what 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 we're 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 the router.
And because of the
credentials,
we saw a vulnerability introduced where a third party ie a militia 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
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.
Ie a piece of equipment that we're going to change the configuration,
that we back it up.
First. That's a 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 onto 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, uh, you know,
I need to identify the finances.
It'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 the 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 change any changes to the configuration files,
specifically within telecommunications,
we would go through and we would make up back
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 have the newly created backup and then we would leave that USB attached
to the equipment via string and that string was usually about 5 ft long.
So you can maneuver it.
It wasn't in the way and it just hang
off the server rack without any problems whatsoever.
But we had a counting 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 the configuration file and save some time.
But we kept that and we can uh 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.
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 let's see 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 gonna hear me harp on this as we go through these different slides.
The other thing 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, 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 Roger Miller management plan,
we spoke about compass
controls earlier in this course, but just as a refresher,
when it comes to configuration management and compass
controls,
I may have a configuration that's vendor specific and they
suggest we do it this way specifically 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 an 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.
Uh 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 uh education training, right?
We've talked about awareness,
education and training before uh throughout this course.
But I want to re emphasize this uh training,
awareness and education is more than just our uh 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 greatest 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 tell me how to redo it.
Technology changes,
different ways 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.
Uh 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 environment, entire environment.
Uh 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 of their play
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.
IE 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 fishing 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.
Uh Getting formal training,
you're probably not going to get away with that more than once or twice a year.
But informal training, we can do any time and those little reminders,
we can do those as much as twice a week.
Uh 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.
Uh Again, going back to the same knowledge of, oh, I've been doing this for 20 years.
I don't need to do this. Same in the same part of I don't like change.
The problem is is that businesses changes very
regularly almost as often as technology changes,
you have companies that go through and they could sell needles
or they could sell bolts or they could sell whatever.
But the overarching process changes as technology increases,
we can automate a lot of different things that comes through.
And those changing business requirements could come into play
as changing business requirements comes into play for technology,
especially cybersecurity.
We need to be able to incorporate
those different changes within 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 cybersecurity does
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?
Uh We,
we're also doing it in a safe and secure manner and that's where we come into play.