Config Management
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Transcription
00:00
>> Hi, and welcome to Module 2, Lesson 4.3.
00:00
In this lesson, we're going to talk about
00:00
configuration management.
00:00
We're going to cover standard images,
00:00
software repositories,
00:00
CIS scanning and change management.
00:00
Let's start with standard images.
00:00
A standard image is
00:00
just a baseline image of a piece of software,
00:00
specifically an operating system.
00:00
Let's say you have Windows 10
00:00
on 3,000 workstations in your environment.
00:00
A standard image is going to
00:00
>> just give you the ability to
00:00
>> install Windows 10 on a single system,
00:00
put all of the applications on
00:00
Windows 10 that your organization needs,
00:00
run vulnerability scans against it,
00:00
install all of the necessary patches and create a
00:00
fully hardened, fully vetted system.
00:00
Once you've done that, you can capture an image of
00:00
it in the virtual world it can just be a snapshot,
00:00
in the hardware world there's software you can
00:00
use to capture an image of that and save it centrally.
00:00
You can create baseline images
00:00
not just for operating systems,
00:00
but even within your organization,
00:00
maybe the marketing department has a different set of
00:00
applications running on their operating system
00:00
than the engineering department does.
00:00
You can have a marketing baseline image or
00:00
standard image and an engineering standard image.
00:00
Another name for standard image is
00:00
sometimes we call it the golden image.
00:00
But essentially what a standard image does is
00:00
it's just going to give you the ability to
00:00
have a one known good image that you can use to
00:00
deploy to assets in
00:00
your environment instead of rebuilding,
00:00
say Windows, every time you get a new employee having
00:00
to go through the whole process of
00:00
installing Windows every time from scratch.
00:00
A good practice with
00:00
standard images is once you've got this image,
00:00
once you've gone through all the trouble of
00:00
putting together this really nice,
00:00
hardened vetted image,
00:00
minimize the number of copies that you use.
00:00
Sometimes it's easy to distribute
00:00
>> copies on flash drives
00:00
>> to technicians who are going to be
00:00
actually doing installations
00:00
>> throughout the environment,
00:00
>> but every time you put a copy
00:00
of that on a flash drive and hand it out,
00:00
that's another copy that's out there that may not get
00:00
updated whenever you update
00:00
the golden image for the workstation.
00:00
Then now what you've got is you've got this
00:00
I've seen it just exponentially
00:00
propagate where you've got these
00:00
>> standard images on these
00:00
>> USB drives all over the place and they're
00:00
all different versions and some of them
00:00
haven't been patched in forever,
00:00
so it's good to minimize the
00:00
>> copies as much as possible.
00:00
>> You can do that by using network deployment for
00:00
standard images or you can use
00:00
things like pixie boot, for example.
00:00
If you create a standard image you
00:00
can save it in a centralized location,
00:00
and then when systems boot up,
00:00
you can hit some function keys and have them
00:00
boot from network and then you can
00:00
point to the network location where you're golden image
00:00
is and they can pull down
00:00
the image and install from there.
00:00
Instead of having these images on
00:00
USB sticks all over the place,
00:00
now you've got one centralized images
00:00
that you can control
00:00
and anything in the environment as
00:00
long as it's connected to the network,
00:00
can go out and grab it and install it.
00:00
It's always going to get the latest and greatest image,
00:00
you're not going to have still images
00:00
out there scattered all over the place.
00:00
Just like with the patches
00:00
when we talked about
00:00
patch management in the last lesson,
00:00
there's no different here.
00:00
You want to patch that standard image regularly,
00:00
just like you patch everything else in the environment.
00:00
A good rule of thumb is every time you go through,
00:00
if you're going to patch monthly in your environment,
00:00
all the systems in your environment just include
00:00
the standard image in that patching.
00:00
Have that standard image loaded on a system,
00:00
run all the patches against it
00:00
>> and then save it again and
00:00
>> then replace your standard image
00:00
with this new standard image.
00:00
That way you've always got
00:00
an up-to-date fully patched standard image
00:00
or golden image.
00:00
Now, something very closely related to
00:00
a standard image is a software repository.
00:00
All that software repository is a centralized location
00:00
where you keep software that
00:00
>> you use in your environment.
00:00
>> Let's say you use Adobe Flash and you
00:00
use Microsoft Word and you use AutoCad,
00:00
whatever those software packages
00:00
are that you use in your environment,
00:00
a software repository is
00:00
a mechanism for just grabbing all
00:00
of those software images
00:00
from all of the different vendors,
00:00
and keeping in one centralized location.
00:00
The idea behind a software repository
00:00
is even if you allow your end-users,
00:00
for example to go out and install
00:00
their own update, their own software,
00:00
install their own, say AutoCad,
00:00
because they have a license for it.
00:00
Instead of letting them point
00:00
directly to the AutoCad site,
00:00
you should have them point to
00:00
an internal software repository,
00:00
so as an IT administrator,
00:00
you go out and you get the piece of
00:00
software and you keep it in a centralized location
00:00
and then your users or your technicians
00:00
can install software from that location.
00:00
That ensures that the end-users or
00:00
technicians aren't just going out to
00:00
any website they can find where they can download
00:00
a copy of that software and installing that.
00:00
There's a lot of malware out there
00:00
masquerading around as legitimate software.
00:00
To software repository,
00:00
you keep it in a central location,
00:00
you want to put access controls around it.
00:00
If you don't allow
00:00
people to install software on their own then you
00:00
should lock it down and have read only access only from
00:00
your technicians or I'm
00:00
sorry re-write access only from your technicians.
00:00
If you do have your end-users that you
00:00
want to allow them to install their own software,
00:00
you can still maintain that software.
00:00
Make sure it's up-to-date in the repository,
00:00
give them read access to it,
00:00
but only leave write access to those handful of
00:00
individuals who you want to
00:00
actually update those software images.
00:00
Only a trusted few are allowed to actually replace
00:00
that centralized trusted piece of
00:00
software that gets rolled out to
00:00
>> the rest of the company.
00:00
>> If you use an agent on
00:00
the end point to deploy software like
00:00
a McAfee EPO has been used for a while or
00:00
whatever that agent is if you're using
00:00
an agent on the endpoint to deploy software,
00:00
you can point that agent to
00:00
the software repository instead of
00:00
having it go out and
00:00
grab stuff off the Internet directly.
00:00
Just like the golden image
00:00
you're going to want to patch this are not patched,
00:00
but you want to update this regularly.
00:00
You don't want to have a piece of
00:00
software in the software repository that's
00:00
eight revisions behind because it's naturally
00:00
going to be full of vulnerabilities.
00:00
You want to have the latest and
00:00
greatest or at least something close to
00:00
the latest and greatest software in
00:00
that software repository so as it gets deployed,
00:00
it's the latest and greatest.
00:00
I'm going to switch gears a little
00:00
>> bit to CIS benchmarks.
00:00
>> CIS stands for the Center for Internet Security.
00:00
Essentially CIS, we talked about this a little bit in
00:00
the beginning in Module 1,
00:00
when we talked about vulnerabilities.
00:00
With a vulnerability scanner,
00:00
you can have a scanner scan
00:00
the environment for vulnerabilities
00:00
but it can also scan for configuration vulnerabilities.
00:00
CIS is an organization that puts
00:00
together a list of best practices.
00:00
These are different pieces of software.
00:00
For Windows, here's the things you should do for
00:00
best practices as far as
00:00
configuration of the software itself,
00:00
for Apache, for Unix,
00:00
for all of the different packages they have
00:00
these benchmarks that serve as best practices.
00:00
Most vulnerability scanners can
00:00
scan not only for vulnerabilities,
00:00
but they can scan for these
00:00
>> configuration vulnerabilities
00:00
>> as well, these misconfigurations.
00:00
You can scan for that and you get
00:00
a report that looks similar to this that shows
00:00
you all of the different things that are
00:00
configured on that system that can be
00:00
configured differently to lower
00:00
the vulnerability and lower
00:00
>> the risk to the organization.
00:00
>> As you're doing your vulnerability scanning as part
00:00
of your vulnerability and patch management program,
00:00
you should include CIS benchmarks and CIS
00:00
scanning to make sure that your applications,
00:00
that your software on
00:00
your endpoints is configured properly.
00:00
The last topic here
00:00
in this section is going to be change management.
00:00
Now, change management is
00:00
simply just we talked a little bit
00:00
about how changes to
00:00
the software repository or changes to the golden image.
00:00
In this section, we're talking specifically
00:00
about changes to the production environment
00:00
or changes to the systems in your environment.
00:00
It's very important to have
00:00
a good change management process in place,
00:00
a good program in place.
00:00
The reason it relates to security is
00:00
because in the security world,
00:00
a lot of detecting malicious things in
00:00
the environment relies on
00:00
>> being able to identify normal.
00:00
>> If we create good change process
00:00
and we know what normal changes
00:00
look like in an environment we can
00:00
anticipate changes and predict changes,
00:00
we know what changes are happening in the environment.
00:00
If we see something outside of
00:00
that window or outside of that baseline,
00:00
we can flag it as suspicious
00:00
and that wouldn't start pulling on the thread.
00:00
In the security world,
00:00
there's a lot of noise.
00:00
Anytime we can reduce the noise,
00:00
we always want to do that.
00:00
Change management process gives
00:00
us an opportunity to do that
00:00
because if we understand what
00:00
those changes look like we can look for
00:00
anything outside of it as suspicious.
00:00
Some concepts in the change management world,
00:00
a lot of organizations have different environments.
00:00
Some organizations have a development,
00:00
a UAT and a production environment.
00:00
UAT stands for user access testing.
00:00
Development environment would be where
00:00
people can just tinker, engineers can tinker,
00:00
they want to try something they're not
00:00
quite sure what effect it's going to have,
00:00
what impact it's going to have but
00:00
the best way to figure it out is to just try it.
00:00
There's this environment that
00:00
they can play with and a lot of times there's
00:00
no change management control in
00:00
that environment is just a place to tinker.
00:00
Then there's UAT, which is user access testing,
00:00
or sometimes called pre-prod.
00:00
That's an environment that mimics production.
00:00
It looks like you're in production environment
00:00
and once you finish
00:00
tinkering in the development environment when you think
00:00
it's ready for production,
00:00
the first place you go is UAT or pre-prod.
00:00
Putting your changes into
00:00
that environment will tell you if there's
00:00
any issues with that change in
00:00
an environment that has the
00:00
same configuration as production,
00:00
maybe there was some you didn't
00:00
see in dev that you're going to see
00:00
in pre-prod and you can
00:00
catch it before it becomes a problem in production.
00:00
Then once you've worked out all the
00:00
bugs in that environment,
00:00
then you would install it into
00:00
the production environment.
00:00
A lot of organizations split it up this way just to
00:00
limit the number of outages
00:00
that occur in the environment,
00:00
they go through this process of changes.
00:00
But lately, that's all being collapsed
00:00
into one what they call DevOps environment.
00:00
That's basically where just the development
00:00
and the operations is the lines are being blurred.
00:00
The idea is to be able to develop
00:00
and release faster and faster.
00:00
Some organizations have maybe a software product
00:00
that they need to release
00:00
new versions all the time to stay competitive
00:00
and it's important that you can do it
00:00
quickly and if you have
00:00
these three different environments,
00:00
you have to go through all three of these.
00:00
It takes a little bit longer.
00:00
This process of DevOps has been
00:00
created where it's blurring the lines between that,
00:00
but you can still have change management processes
00:00
in a DevOps environment.
00:00
You can still have process that
00:00
regulates what changes can be made during
00:00
the development phase and
00:00
how things get pushed into production
00:00
and how they actually get
00:00
committed or code gets
00:00
committed and things of that nature.
00:00
It's important for any change management program
00:00
to have a dedicated change management team.
00:00
A group of people who are made up
00:00
of diverse backgrounds, or in other words,
00:00
they're from different parts of
00:00
the organization and they all
00:00
>> understand as a collective,
00:00
>> how a change in this part of
00:00
the organization is going to
00:00
>> impact something over here.
00:00
>> As engineers a lot of times we get down into
00:00
the weeds and we're working on our one little piece
00:00
of the pie and we may have a perfect solution
00:00
but what we don't see is that when we make this change,
00:00
there's a chain of events that happens at
00:00
impacts this other business function over here.
00:00
As the change management process
00:00
as you're creating the process,
00:00
it's important to have a team of
00:00
people with representation from different areas
00:00
of the organization so
00:00
that we can understand the full impact of a change.
00:00
This team of people can be responsible for approving.
00:00
Then finally the change, you should have
00:00
a good change management process itself.
00:00
There's a lot of different things that can be,
00:00
you can have peer review processes in place.
00:00
If it's a code shop you can say you have to have
00:00
at least one peer reviewer that looks at
00:00
that code or even as a network engineering shop,
00:00
one peer reviewer that
00:00
another network engineer that looks
00:00
at that change, you're going to make to that router
00:00
to make sure it doesn't cause an impact.
00:00
You can have those types of things,
00:00
you can even have things around
00:00
time windows and how you handle the change itself.
00:00
The change management team
00:00
should be responsible for scheduling the changes to
00:00
make sure that there aren't two or three changes going
00:00
on at the same time in the environment,
00:00
or one of them is in a big deal,
00:00
maybe there's a change on the production system but if
00:00
there's a change on the backup system at the same time,
00:00
well, now you have an outage
00:00
because you're working on both systems.
00:00
The change management team should be
00:00
responsible for scheduling those to make
00:00
sure that the overlap doesn't
00:00
>> cause issues and then maybe
00:00
>> there's some timeframe as well
00:00
you want to put in place if there's a change window,
00:00
you're supposed to get a change done in
00:00
an hour let's say,
00:00
and you are 45 minutes into the window and you've
00:00
run into issues and you're struggling to get it,
00:00
there should be some period in
00:00
there where there's a that's it.
00:00
That if you hit this number and you're not done,
00:00
you have to back the change
00:00
out and you'll have to start it over again
00:00
because you're going to run the risk of running
00:00
into another change where
00:00
you could impact something else.
00:00
There's lots of different things
00:00
>> you can do with process.
00:00
>> The idea is to have
00:00
some process and to make sure everyone understands what
00:00
that process is especially
00:00
in the security world so that the security analysts can
00:00
understand what types of changes
00:00
to expect as normal in the environment.
00:00
That's it for this session.
00:00
The next up we're going to switch gears,
00:00
we're going to move away from the endpoint layer,
00:00
we're going to start talking about
00:00
the application layer in Lesson 2.5.
Up Next
Instructed By
Similar Content
