Technical Change Management - CompTIA Security+ SY0-701 - 1.3

Summary

This video script delves into the change control process from a technician's perspective, highlighting the complexities of implementing changes in large-scale environments with multiple devices. It discusses managing allow and deny lists, the importance of adhering to documented scopes, and the potential need for modifying the change scope to achieve the primary goal. The script also touches on minimizing downtime during changes, handling legacy applications, managing dependencies, and the necessity of ongoing documentation and version control to keep systems up-to-date and maintainable.

Takeaways

• 🛠️ The change management process is crucial for implementing changes in large environments with numerous devices, where a simple update can become complex.
• 🔧 Technicians play a critical role in the change control process, performing the actual changes such as updating allow or deny lists to manage application security.
• 🚫 Technicians must adhere strictly to the change control document's scope when making updates, ensuring changes are limited to what is specified.
• 🔄 Change control may require additional updates or scope expansion to achieve the primary goal, which should be done within established policies.
• 📝 A well-documented change control process is essential for understanding procedures and making informed decisions when the scope of change needs adjustment.
• 🕒 Downtime is often associated with change control, and IT professionals typically schedule changes during non-production hours to minimize impact.
• 🔄 In 24/7 environments, change control might involve switching between primary and secondary systems to update without downtime, highlighting the importance of automation and monitoring.
• ⚠️ Communication about potential downtime is vital; stakeholders should be informed through emails or a centralized change control calendar.
• 🔄 Reboots may be necessary post-change to implement new configurations, which can be done at various levels, from the OS to individual services or applications.
• 🏛️ Legacy applications present unique challenges in change control due to their long-standing use and potential lack of developer support.
• 🔗 Managing dependencies is a significant aspect of change control, as updates to one service may necessitate changes to others, complicating the process.
• 📚 Ongoing documentation is necessary to keep network diagrams and configurations up-to-date, reflecting the dynamic nature of change control.
• 🔄 Version control is vital for tracking changes, managing different software versions, and reverting to previous versions if issues arise.

Q & A

What is the primary focus of the change control process?

The primary focus of the change control process is to determine what needs to change and to document the scope of the change, ensuring that technicians are limited to making only the changes specified in the change control document.

Why is it challenging to implement changes in an environment with a large number of devices?

Implementing changes in an environment with a large number of devices is challenging because what would be a simple update for a single device can turn into a very complex process due to the scale and potential interdependencies among devices.

What are allow lists and deny lists, and how are they commonly used in an IT environment?

Allow lists and deny lists are used to control which applications can run within an IT environment. An allow list specifies the applications that are permitted to run, while a deny list identifies applications that are not allowed, often due to security risks such as known vulnerabilities or malware propagation.

How does managing an allow list differ from managing a deny list?

Managing an allow list means that only the applications specifically named on the list can run, restricting everything else. In contrast, a deny list allows any application to run except for those specifically named on the list, providing more flexibility.

What is the significance of the change control board in the change management process?

The change control board is significant as it reviews and approves changes, ensuring that they are within the documented scope and that the changes are made during scheduled windows to minimize disruption.

Why is it important to have policies in place for making additional updates or expanding the scope of a change?

Policies for additional updates or scope expansion are important to ensure that technicians can make necessary modifications to complete the primary goal of a change, while still maintaining control and minimizing unintended consequences.

How can downtime be managed during the change control process?

Downtime can be managed by scheduling changes during non-production hours, using secondary systems to prevent downtime, or by communicating potential outages to all stakeholders through emails or a centralized change control calendar.

What is the role of rebooting in the change control process?

Rebooting is a part of the change control process that ensures new configurations are implemented and that the system can recover properly from a power outage. It can involve restarting the operating system, a service, or the physical device.

How does dealing with legacy applications complicate the change control process?

Legacy applications can complicate the change control process because they may no longer be supported, are often poorly documented, and may have unique dependencies or configurations that are not well understood within the organization.

Why is ongoing documentation important in the context of change control?

Ongoing documentation is crucial to keep the environment's documentation up to date, reflecting any changes made. This ensures that all stakeholders have the most current information about the network configuration, applications, and procedures.

What is the purpose of version control in managing changes to systems and applications?

Version control helps track changes made to systems and applications, allows for the management of different versions, and provides a way to revert to a previous version if necessary. It ensures transparency and accountability in the change management process.

Outlines

00:00

🛠️ Change Control Process for Technicians

This paragraph discusses the change control process from a technician's perspective, emphasizing the complexity of implementing changes in large-scale environments. It highlights the importance of managing allow and deny lists to control application usage and prevent security risks. The paragraph also explains the constraints imposed by change control boards and the necessity of adhering to documented scopes while allowing for some flexibility in certain situations. The concept of change windows and the preference for making changes during non-production hours to minimize downtime are also covered, along with strategies for managing changes in 24/7 operations, such as using primary and secondary systems to prevent downtime.

05:01

🔄 System Reboots and Legacy Application Management

The second paragraph delves into the specifics of rebooting systems as part of the change control process, which can involve restarting the operating system, a service, or an application. It touches on the importance of understanding how systems recover from power outages and the challenges of managing legacy applications that may no longer be supported. The paragraph also addresses the complexities introduced by application dependencies and the need for ongoing documentation to keep network diagrams and configurations up to date. It underscores the importance of having a detailed understanding of systems to support them effectively and the role of documentation in managing change control.

10:02

📊 Version Control and Documentation in Change Management

The final paragraph focuses on the role of version control in tracking changes made during the change control process. It discusses the benefits of having built-in version control within applications or operating systems and the alternative of using third-party management systems to monitor and manage changes. The paragraph highlights the need to keep track of different versions of code, software, or configurations and the ability to revert to previous versions if necessary. It also emphasizes the importance of detailed documentation to maintain an accurate record of the system's state over time.

Keywords

💡Change Management

Change management is a systematic process for introducing changes into an organization's infrastructure, processes, or environment in a controlled and predictable manner. In the video, it is the overarching theme, emphasizing the need for a structured approach when implementing changes, especially in complex IT environments with numerous devices.

💡Technical Staff

Technical staff refers to the individuals with the necessary expertise to implement changes within a technical environment. The script discusses their role in executing change processes, such as updating software or modifying configuration files, which is crucial for maintaining system integrity and security.

💡Change Control Process

The change control process is a formalized procedure for evaluating, approving, and monitoring changes to a system. It is central to the video's narrative, highlighting the importance of having a clear and documented process to manage changes, ensuring they are made safely and within predefined parameters.

💡Allow List

An allow list, as mentioned in the script, is a security measure that specifies which applications or entities are permitted to function within an IT environment. It is part of the change control process, where technicians must decide which applications to include, thereby controlling what is allowed to run on workstations.

💡Deny List

A deny list is the counterpart to an allow list, identifying applications or entities that are explicitly prohibited from running. The script uses the concept of a deny list to illustrate how technicians can prevent the execution of known malicious software by adding it to the list, enhancing system security.

💡Vulnerabilities

Vulnerabilities are weaknesses in software or systems that can be exploited by attackers. The video discusses the role of technicians in identifying and addressing vulnerabilities, such as by updating deny lists to prevent the operation of applications with known security flaws.

💡Malware

Malware refers to malicious software designed to infiltrate, damage, or perform unauthorized actions on a computer system. The script mentions the importance of preventing malware infection by utilizing deny lists to block known malicious applications from executing within the IT environment.

💡Change Control Board

A change control board is a group responsible for reviewing, approving, or rejecting changes to a system as part of the change control process. The script describes how this board sets a specific scope for changes and schedules windows for their implementation, ensuring that changes are made in a controlled and predictable manner.

💡Downtime

Downtime in the context of the video refers to periods when a system or service is not available due to maintenance or updates. It is a critical consideration in the change control process, as IT professionals often schedule changes during non-production hours to minimize the impact on users.

💡Version Control

Version control is a system used to track and manage changes to documents or code. The script highlights the importance of version control in change management, allowing technicians to keep detailed records of changes, revert to previous versions if necessary, and maintain an up-to-date understanding of the system's configuration.

💡Dependencies

Dependencies in the script refer to the relationships between different applications or services where the installation or operation of one may require changes to another. This concept is important in change control as it adds complexity to the process, requiring technicians to consider and manage the interrelated nature of system components.

💡Legacy Applications

Legacy applications are older software systems that continue to be used, often because they are deeply integrated into an organization's operations. The video discusses the challenges of managing changes to these applications, which may no longer be supported by developers, and the importance of documenting them to ensure ongoing support.

💡Reboot

Rebooting, as mentioned in the script, is the process of restarting a computer system or service, which may be necessary after implementing certain changes. It is a common step in the change control process to ensure that new configurations or updates are properly loaded and functioning.

Highlights

Introduction to the change management process and its implementation by technical staff.

The complexity of making changes in environments with a large number of devices.

The role of technicians in the change control process and performing actual changes.

Explanation of allow and deny lists used for application control in IT environments.

The importance of adding malicious applications to deny lists for security.

Differences between allow and deny lists in terms of application restrictions.

The change control board's role in defining the scope of changes.

Limitations on technicians to only make changes listed in the change control document.

The possibility of making additional updates within the change control process if necessary.

The significance of having a well-documented change control process for scope changes.

The association of change control with potential downtime and its management.

Strategies for making changes during non-production hours to minimize impact.

Approaches to change control in 24/7 environments using primary and secondary systems.

The importance of monitoring changes and the ability to revert to previous configurations.

Communicating potential downtime to users through emails or a centralized calendar.

The process of rebooting systems as part of change control and its implications.

Challenges of making changes to legacy applications and the value of documentation.

Becoming an expert in legacy systems through documentation and understanding.

The impact of dependencies on the change control process and managing them.

The necessity of ongoing documentation in change management to keep information current.

The use of version control in managing different versions of code and configurations.

The benefits of built-in or third-party version control systems for tracking changes.

Transcripts

In our previous video, we talked about the change management

process.

But of course, eventually, the actual change

will need to be implemented into your environment.

And that usually relies on the technical staff

to be able to make these changes.

When you're making changes to one or two devices at home,

it's a relatively straightforward process.

But when you're working in an environment with tens,

hundreds, or even thousands of devices,

what would be a very simple update for a single device

can turn into a very complex process.

So in this video, let's talk about the change control

process from the perspective of the technician.

The change control process itself

is one that is concerned with what needs to change.

But of course, the technician is the one

who will be actually performing these changes.

For example, a technician may be asked

to make a change to an allow list or a deny list.

These are lists that are commonly

used to allow or prevent certain applications from working

in your environment.

This is because certain applications

can be considered dangerous.

These applications might have known vulnerabilities

or perhaps they're well-known applications

for carrying malware and infecting other systems.

It would make sense, then, for a technician

to add those malicious applications to a deny list

or perhaps include only the applications that they'd

like to run to an allow list.

If you're managing an allow list,

this means that only the applications you've named

will be able to run on people's workstations.

Everything is restricted except the things

that you add to the allow list.

A deny list is a little bit more flexible,

in that you could run any application you'd like,

except for the applications that have been specifically named

on the deny list.

For example, it's common to think

of antivirus and anti-malware as being a very large deny list.

Everything can run on your system

except specific types of code that are

identified by the anti-malware.

When a change is submitted to a change control board,

there's a very specific documented scope

for making this change.

And as part of this change control,

you're limited to only making changes

to what is specifically listed in the change control document.

For example, a change control board

may schedule a two-hour window for you

to be able to upgrade a series of printer drivers.

But that doesn't mean, during that same two-hour period,

that you can make other changes to other applications

just because the window happens to be available.

However, this doesn't mean that you're

limited to only what is listed in the change control

documents.

There may be times where you have to make additional updates

or expand the scope to be able to complete the primary goal

of that particular change.

For example, you may find that the process of upgrading

those printer drivers requires a modification to a configuration

file on everyone's system.

And although that wasn't specifically written

as part of the scope of this change,

this change can only take place if you make that modification.

And if this is a relatively simple modification,

there may be policies in place that

allow you to make the decision to modify that

file so that you can complete the overall change control

process.

This is why it's important to have a well-documented change

control process so that everyone understands the procedures that

should occur if you need to change the scope of the change

control.

When most people hear the term change control,

they automatically think about downtime.

And although this doesn't necessarily

mean that there will be downtime during the change,

we very often set aside a certain range to tell people

that there might be some unavailability

during this particular window.

This is one of the reasons as an IT professional

we tend to make these changes during non-production hours.

So the overnight hours or times when people are not

working on a particular application

would be a perfect time to make any type of significant change

to the application.

If you work for an organization that is up and running 24/7,

then you may find it very difficult

to find a change control window where downtime is tolerated.

In those environments, it's probably

more common to have a system where

you could switch to a secondary system,

update the primary system, and then switch over seamlessly

to prevent any type of downtime.

This move between a primary and secondary system

is probably one that's relatively automated

so that it can make that change as quickly as possible.

This also allows you to monitor the change.

And if you notice that there are problems,

you can switch back to the secondary system,

which at this point, you haven't made any changes to.

This makes it very easy to fall back

to a previous configuration by simply pointing

all of your users to either the primary

or the secondary system.

And of course, if there could be downtime,

you need to be sure that everyone

is aware of any potential outages that

may occur during that window.

It's common to send out emails informing everyone

of this particular downtime.

Or you could have a centralized change control calendar

where people can proactively view

what may be happening at any particular time of the day.

If you've been part of implementing

one of these change controls, one

of the things that you probably had

to do just before bringing everything back online

is to reboot the system.

This may be required by the change.

You may have a new configuration that will only be implemented

if you restart the system.

This may require rebooting the operating system itself

or, if you're in front of the physical device,

you may be able to physically power it down and power it

back on again.

Or this may only require you stopping and restarting

a service that's running in that operating system.

This also helps you understand if this system is going

to be able to recover properly if there

happens to be a power outage.

But if you're rebooting the system as part of your change

control, you'll know exactly how that system will react if it

happens to need a power cycle.

If the documentation says that we only

need to stop and restart a service,

this can usually be done relatively quickly.

We can do this from the Windows Services; from Task Manager

inside of Windows; or if it's Linux,

we may be able to restart a daemon that's already

running in the background.

And if we're updating an executable that's on a system,

we may require our users to log out of that application,

completely close down and exit the app,

and then restart it with the updated application.

One challenging aspect of this change control process

is when you're making a change that could affect a legacy

application.

Legacy applications have usually been

running for a very long time, and there are no current plans

to change out this particular app.

To add additional complexity, it's

very common for these legacy applications

to no longer be supported by the developer-- assuming,

of course, that the developer is even still in business.

These are usually the systems with a sign that

says, don't make any changes to this system

because no one in the organization

understands the application or how to support

any aspect of this system.

However, you may find that this application is not as complex

as you may have first thought, and by documenting

the application and how it's installed onto the system,

you can bring it into the normal support

cycle for your organization.

This doesn't necessarily mean that the support for this app

becomes seamless because there may be some idiosyncrasies that

are specific to this older application running on an older

operating system.

You'll find that after documenting these systems

and understanding how they work just a little bit better,

you'll become the expert in this system

and everyone in your organization

will be able to now support that system a little bit better.

If you've ever had to manage a large scale operating

system that is providing services

for hundreds or thousands of people,

then you know that making a simple upgrade

can sometimes be complicated because of dependencies.

With dependencies, you have to first make a change

to one application or service before you're

able to install or update another application or service.

Or it may be that the service that you've installed

won't work until a secondary service is also

installed on that system.

This certainly complicates the change control process.

We thought we were updating and changing one application,

and now we have to update a number of different services

just to provide the original update.

And in some cases, the dependencies

may not even be on the same system.

For example, to be able to install

a new version of your firewall management software,

it may also require your firewalls

to be running at a new version of code.

So you would first have to update all of your firewalls,

and then you would need to update the firewall management

software.

With change control, it's certainly true

that the only constant is change.

You might have change control processes

occurring in your data center every week

or perhaps even every day.

And every change has something that has now been

modified to what it was before.

This means that any documentation you have

of your environment could very quickly be out of date

without some type of ongoing documentation process.

That's why we commonly see documentation being required

with the change management process

itself so that you are always creating the most updated

set of documentation for your network.

This might include updating diagrams or charts that

have a network configuration.

You might have to modify IP addresses

or different configurations or you

may have to list a new series of processes or procedures

for managing a brand-new application that

has been upgraded in your production network.

And if you're dealing with change control,

then you're probably also dealing

with different versions of code, software, or configurations

that need to be applied to these systems.

In these situations, it's very useful

to have some way to keep track of all

of these different versions that have been installed.

And this also might give you a way

to revert to a previous version if you run into problems.

Many times, we provide this functionality

through version control.

This allows us to keep detailed documentation on things

like changes to router configurations,

patches inside of the Windows operating system,

changes to registries when you're updating an application,

and anything else where you can track what happens

between point A and point B.

You may find that the applications or operating

systems that you're using already

have some type of version control built in,

and there might be a very easy way within that application

or operating system to click a button, make a change,

and suddenly you're running a different version.

If your application or operating system

doesn't integrate any type of version control,

you might want to install a third party version control

management system so that you can manage all of your systems

and know exactly when changes are made

and what those changes are doing.