Part 6 - Change Management

Video Activity

This lesson focuses on change management. Change management is essential as it provides a stable environment. How change management is conducted depends on the industry and standards. When implementing change management; the following factors must be taken into account: 1. Procedural 2. Scheduling 3. Documentation 4. Awareness/training 5. Back out ...

Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

5 hours 54 minutes
Video Description

This lesson focuses on change management. Change management is essential as it provides a stable environment. How change management is conducted depends on the industry and standards. When implementing change management; the following factors must be taken into account: 1. Procedural 2. Scheduling 3. Documentation 4. Awareness/training 5. Back out plans/fall backs 6. Change management database 7. What/when/who 8. Vendor contact/support info

Video Transcription
okay, once again just to review the ideas of change management. I know I've said this throughout the change management, so very essential
because it provides for us a stability of environment.
For instance, we would be a wee, but it would be very easy to manage a network where every single system was identical
down to the devices and drivers down to the operating systems and applications.
Same left with skill for the user's same level of updates and patches, everything being identical.
Unfortunately, very few of us, if any work in that environment. There's always that variation from system to system, many of us working a very, very mixed environment where we have,
um, you know, Windows systems, we have Novell. Since we have linen systems, we have Apple systems. We have different protocols on the network. We have a 1,000,000 different vendors. Doing their own proprietary thing makes it very difficult
with change management. What we want is we want to create a stable of baseline as possible and control any changes to the baseline.
So with change management, nothing happens on the fly.
Oh, I've just read about a security vulnerability on this window. Seven system do I download that patch and push it out to 200 computers and production?
Oh, of course not, Right? I guess I could, But I would be unemployed very shortly thereafter, because there must be a process before we implement changes. Even patches. Patch Management's a part of change management.
But even if I find Oh, this would be a better way to implement or we're not using this protocol. Let's get rid of it. Or how about we go with this tool instead of another? We just don't do that in the network environment.
As a matter of fact, from a user perspective, we really walk down very tightly what a user can and can't do. I know in my environments I prefer not to allow users to install applications. As my friend, I prefer users not have met much configuration cape
ability at all. I like to really lock down my users,
and the reason is, if I don't prohibit them from installing applications,
then they'll install application
and not all of those applications or business appropriate. Not all those applications air clean and virus free and and suited for our environment.
You know there are a 1,000,000 problems that we bring onto our network when we allow users to bring in applications from home or tow, have that degree of control in their systems. So we want to keep our systems locked down, and we want to make sure that any changes from the baseline configuration are controlled and documented. They've got to be a
They've got to be tested before they would ever be rolled out. So that's what change management's all about. Different organizations have different methodologies for handling change management, different approaches. It really depends on your organization. It depends on what industry you're in. What's standards are, too what you're hearing. But the
bottom line
is, changes must be controlled.
So whether you have a change control board 30 people
or you have ah, staff of two people evaluating changes, there just has to be a process. Before we can allow changes happen.
Who changes should happen in the very structured way.
Um, the changes should be scheduled. The document. We would like to train our users before we make the change. You know, one of the worst things I had to do as a trainer,
I don't know if you remember when office went from 2003 Toe Office 2007 and basically office. Microsoft Office had consistently looked the same for years and years and years,
and then with Office 2007. They introduced the ribbon bar, and they took essentially everything people have been using for years. And they put it somewhere else and called it something different.
Most people did not view it as a positive change when Office 2007 1st came out. So one of the worst training jobs I had was I had to go to a location and Delaware, I believe,
and I had to train 300 or so staff members on office 2007
after it had been implemented in their organization for two weeks.
Basically what that meant. WAAS. I had people that had been poorly using Office 2007 for two weeks. They hated the software. They had all kinds of rumblings and complaints. Two weeks later, they were getting help with software.
It makes much more sense to train your people before throwing them to the won't want to make sure that we schedule in awareness or training for the changes
prior to change is happening.
Ah, part of change management would also do take back out plans and roll back plans just in case the change isn't a successful as we would hope it would be.
We also frequently have changed management databases that we used to document changes.
We have to make sure that we document,
um we've got to know what changes are made to our baseline configuration to our network
because at some point in time, if we're involved in disaster and we have to restore our organization to the state that it was before the disaster,
If we don't have good documentation, how in the world will we know that state is? How in the world will we know the access control lists that are configured on our routers? How will we know? Um, the the operating systems that are running certain
service is or what the minimum operating requirements are. What are
service level agreement for server A is the bottom line is when they're changes, we must document document, Doc
who, what, When? Where, How why? You know whatever's appropriate to document in the change management database needs to be documented.
Vendor, contact information, vendor support that gets documented as well. Especially there is a service level agreement. We need to make sure that we're able to contact the vendor that supports that certain several agreement. So change management requires control and documented in documentation of any changes to the
configuration on our network.
Hatch management is simply a part of change management. So we've gotta have some procedure for addressing patches and not all patches air created equal. You know, some are very critical patches that address significant security vulnerabilities. Others are less critical.
Um, others are
nonessential patches. So how we treat the different patches needs to be detailed. Need to have processes and procedures for that, and Patch management can be a huge, huge tour.
You know, if you're familiar with Microsoft's patch Tuesday, you know there are a lot of patches that get rolled out to make sure those patches air tested and documented,
uh, can can really require quite a great deal of effort
Up Next