Part 10 - Change Management

Video Activity

This lesson covers program policies, standards and guidelines. This unit covers the following policies: • Organizational Security Policy (this is also called Program Policy) • Issue and System Specific Policy Participants also learn about standards which are mandatory and in place to support policy while at the same time providing more specifics. S...

Join over 3 million cybersecurity professionals advancing their career
Sign up with

Already have an account? Sign In »

2 hours 38 minutes
Video Description

This lesson covers program policies, standards and guidelines. This unit covers the following policies: • Organizational Security Policy (this is also called Program Policy) • Issue and System Specific Policy Participants also learn about standards which are mandatory and in place to support policy while at the same time providing more specifics. Standards reinforce policy and provide direction; they can be internal or external. Procedures are also mandatory and provide step by step directives on how to accomplish an end result. Minimum security baselines provide the minimal acceptable security for a baseline or process.

Video Transcription
Okay, once again just to review the ideas of change management. I know I've said this throughout 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 level of 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 work in 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.
Um, as my friend, I prefer users not have meant much configuration capability. It 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 applications 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 approved. 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.
Changes should happen in the very structured way the changes should be scheduled 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 detail back out plans and roll back plans just in case the change isn't a successful as we would hope it would be.
Uh, 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 a 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
wth e operating systems that are running certain service is or what the minimum operating requirements are what our service level agreement for server A is? The bottom line is, when they're changes, we must document document
who, what, when, where, how, why, you know whatever's appropriate to document in that 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 level agreement.
So change management requires control and documented in documentation of any changes to the baseline configuration on our network.
Patch management is simply a part of change management. So we've gotta have some procedure for dressing patches and not all patches air created equal. 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 could be a huge, huge chore. 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
can really require quite a great deal of effort.
Up Next
Security Operations

They are responsible for knowing where a network's possible vulnerabilities are and providing mitigation strategies to combat them. An effective Cyber Security Operations Manager will have experience in a technical security role including ...

Instructed By