- Now in this lesson 3.2,
we're gonna focus in on change management.
In 3.1 we talked about configuration management,
and how we could only change configuration
through the change control process.
So let's take a look at the change control process
and change management in this lesson.
Now, the objective of change management
is to drastically minimize the risk and impact that a change
can have on a business operation.
Now the change control process
establishes standard procedures for managing change requests
in a secure, in a timely, and in an efficient manner.
So change management applies a formal process
to accomplish change.
And there are a number of areas or components
that we need to really think about
and take into consideration when we think about
any change that needs to take place.
Prioritization, impact analysis, testing the change,
rollback strategies, accountability, documentation.
automation and implementation.
There may be multiple changes that are being proposed.
It could be in a configuration management baseline,
or it could just be in a process,
lots of it could be in code,
lots of different changes could happen in your organization.
But they're not all equal, right?
And so part of a change control committee,
or a change control that groups responsibility,
is to say, okay, let's prioritize these changes,
because we have finite resources to really evaluate them.
So we're going to do prioritization,
of course, in alignment with business needs.
We're going to do impact analysis.
So whenever a change is proposed,
we wanna evaluate the risks and the benefits.
We may wanna do some testing.
Regression testing is testing that's done
whenever there's been a change made in code or software,
just to make sure the system works okay still,
but also any other systems that it has to
interoperate work with also works.
So we want regression and interoperability testing
if there's a change being made or proposed.
We want rollback strategies.
So what if we've done all our testing and our analysis,
and we say, okay, yeah, we're ready to roll.
And then we actually implement it,
and it turns out like, uh-oh, something really went wrong.
We didn't expect this,
it didn't happen the way we thought it would,
it's not always going to.
So we wanna have rollback strategies, right?
That's recovery to a previous state.
Another way to think about it is a backout plan.
We wanna have accountability, right?
Changes should be authorized.
Now they'll be authorized at different levels
of an organization depending upon what the change is,
and also depending on what the level of risk
that might be introduced.
We always wanna document any changes we made,
including diagrams and procedures.
If we are using automation,
we wanna make sure that those baseline
configuration scripts and code are updated.
And then when we go to implement a change,
we wanna make sure that the scheduling considers,
a maintenance windows,
perhaps already scheduled maintenance windows
or acceptable downtime.
And if it's an emergency change,
really looking at when can this be done?
Hopefully at a time when there's the least amount of impact.
Now the ITIL, let's see,
Information Technology Infrastructure Library,
actually defines four different types of changes.
A standard change, a normal change, a major change,
and an emergency change.
A standard change is one that occurs frequency.
It's generally gonna be low risk,
and or it has pre-established procedures
with documented tasks for completion.
So for example,
we're gonna be talking about patch management.
Patch management has a set of procedures.
Now patch management does introduce a change.
But for most organizations,
because patch management is its own program,
and it has its own steps and its own procedures,
and its own, yes, no, stop, go,
it's considered a standard change
and doesn't have to go through
this additional change management process.
A normal change is one that's not standard,
but it's not an emergency.
And that can be approved
by a change control board or committee.
A major change is one that may have significant
financial implications and, or
introduce a high level of risk.
Now that kind of change generally requires
multiple levels of management approval.
And then an emergency change
is one that must be assessed and implemented
without prior authorization,
it hasn't gone through this process
as quickly as possible to resolve a major incident.
But we wanna have a lot of guard rails
around emergency changes,
and they should be few and far between.
So let's look at a normal change control workflow.
A change request is received,
the change might be tested for feasibility,
is this even gonna work, does this make sense?
We'll identify some rollback options.
We'll document changes, we'll finalize authorization,
we'll determine the appropriate change window,
and then we'll implement.
We'll wanna verify
that whatever change we did is working correctly.
We'll wanna update configuration management baseline
if this is something that has a, it's a configuration item,
and it has a configuration management baseline.
And then we're gonna wanna close and archive the request.
We don't wanna throw the request away,
we don't wanna throw all the documentation away.
'Cause we always wanna be able to have this version
and record of, okay, why did we make that change?
Who approved it?
Why did we do it?
What was the impact?
So we wanna close that request,
but we wanna make sure that we archive it.
So this is a great time to introduce you to KPIs,
because we can look at KPIs in terms of change management,
and we can look at KPIs in terms of
lots of different processes.
But this is a good one to look at with.
A KPI is a key performance indicator.
KPIs are a management tool,
they are business metrics used to measure performance
in relation to strategic goals and objectives.
And so I wanted to give you some examples of KPIs
that are directly tied to the change control
and change management process.
Successful changes, backlog of changes, emergency changes.
So a KPI for successful changes
might be the number of changes
that have been completed successfully,
compared to the total number of completed changes.
The higher the percentage, probably the better.
Just the number of changes completed on their own
doesn't really tell me very much.
But if you tell me how many we've completed,
compared to how many have been requested in the queue,
that gives me an idea
of how effective and efficient we're being.
The next is a backlog of changes.
And that's the number of changes that are not yet completed.
Now, in this case, this is an absolute number,
but what we're looking for here is trends.
So it's an absolute number, and what it's gonna be
really depends on the size of an organization,
the larger the organization is,
the more backlog of changes you might have.
But the key is it shouldn't grow over time.
If it keeps growing,
we've got other issues that we need to be looking at.
Are we not staffed correctly?
Do we have bad configurations that are causing problems?
Are we growing too fast?
And then lastly, emergency changes for a KPI,
this would be the number of completed emergency changes.
Again, an absolute number,
which would depend on the size of the organization,
but it should not trend upward.
So how many emergency changes do we have?
We never wanna see those skyrocketing or trending upward.
So three good examples of KPIs, Key Performance Indicators
that we can use in the change management area.
And that my friends, brings us to a three-second challenge.
You know how to do this.
Five challenge questions, three seconds each.
I know you can do this,
and I bet you're gonna get these all right.
Are you ready? Let's go.
This ITIL term describes changes that are required
in the normal course of business,
and have established policies and procedures.
One, two, three.
That's gonna be a standard change.
And I wasn't trying to trip you up
by using the word normal in there.
So don't sometimes think you need to read too much
into a question when you get it.
I really wasn't trying to either give you a hint
or trip you up.
So again, the answer is standard change.
This change management KPI tracks the number of changes
that are not yet completed.
One, two, three.
That would be a backlog.
Number three,
this configuration management element should be updated
if the change occurs to all current and future systems.
One, two, three.
Think back to our last lesson.
That's a baseline configuration.
Number four, this type of testing ensures
an application still functions as expected
after any code change updates or improvements.
I give you a hint, it starts with the letter R.
One, two, three.
This is regression testing.
And lastly, number five,
this strategy may be employed if there's a problem
with the change implementation.
So uh-oh, something's gone wrong, what do I do?
One, two, three.
That's gonna be our rollback strategy or our backup plan.
All right, that brings us to a security-in-action,
so you can apply your knowledge.
Our case study is about change management.
The IT department is balking
at having to follow change management procedures.
They contend that they know what they're doing,
and if something goes wrong, they'll take care of it.
So they're a little outta joint, right?
It's like they're saying, hey,
we don't need these change management procedures.
We know what we're doing,
and if it turns out there's a problem,
we'll fix it, we're always the one to fix it.
Well, you have been given that unenviable task
explaining to them why following the process is important.
So why the change management process is important.
So my question to you is, what are your key talking points?
What are you gonna tell them?
Great time to put me on pause and write down some notes.
Well, here might be your key talking points,
that a consistent change management program
is really a value add for both the organization
and the individual.
The process is gonna assure that
changes are aligned with business strategies,
and that responses are prioritized,
so we don't have business unit managers
yelling at us all the time.
Testing rollback strategies and change windows
are gonna reduce potential disruption and downtime.
And we all know how stressful and costly
and just absolutely awful,
whenever we've caused any kind of disruption or downtime,
how awful it is.
And I would really stress that overall change management
really does contribute to a less stressful
and a more productive environment.
It's not about not trusting their judgment,
it's not about them not being able to do their job.
Matter of fact, what we're really trying to do
is lift a burden from them by really putting this into
a standardized process that you know,
that they don't always have to be making decisions,
they don't always have to be being reactive,
and being have their phones ringing off the hook
by different business units,
it is now a very organized process.
And I think all in all,
it will make a much better working condition for them.
And being able to explain it and convince them,
that my friends is security-in-action.
There's your word cloud, you know what to do.
And when you're ready,
we're gonna have another quiz deep drive,
specifically for lesson three.
So I'll see you there.