Change Management - CompTIA Security+ SY0-701 - 1.3

Summary

The video script emphasizes the importance of a formal change control process in corporate environments to manage updates and modifications to systems securely and efficiently. It outlines the process from identifying stakeholders, assessing risks, to implementing changes with proper testing and rollback plans. Highlighting the impact of changes on various departments, it underscores the need for careful planning and documentation to ensure system uptime and organizational security.

Takeaways

• 🏢 In a corporate environment, a single change can affect hundreds or thousands of systems, necessitating a formal process for managing changes.
• 🛠️ Regular updates to software and systems are crucial for maintaining security, but they require a structured approach to implementation.
• 📋 A formal change control process involves filling out a change request form to ensure all necessary information is provided and considered.
• 🔍 The change control board assesses the scope and impact of the proposed change, as well as the associated risks, before making a decision.
• 🕒 Scheduling is an essential part of the process, determining when the change will be implemented to minimize disruption.
• 🤔 Stakeholders, who may be affected by the change, should be identified and considered, as their input can influence the change process.
• 🔄 The importance of having rollback procedures in case a change leads to problems cannot be overstated for maintaining system stability.
• 🔒 Security is a key driver for updates, and a lack of formal change control can lead to vulnerabilities within the organization.
• 📝 Documentation is vital for the change control process, ensuring that all changes are tracked, understood, and can be audited if necessary.
• 🔍 Sandbox testing environments allow for safe testing of changes without affecting production systems, reducing the risk of implementation.
• 🛡️ A comprehensive backup strategy is essential to revert to in case a change causes issues, ensuring data integrity and system recovery.

Q & A

Why is it crucial to have a formal process for making changes in a corporate environment?

A formal process is crucial because a single change in a corporate environment can affect hundreds or thousands of systems, and it ensures that changes are implemented properly without causing disruptions or security issues.

What are the potential consequences of not following a formal change process in an organization?

Not following a formal change process can lead to inconsistencies in application operations, potential system failures, security vulnerabilities, and overall decreased system availability and uptime.

Why is it important to stay on top of system updates even if they occur frequently?

System updates are important for maintaining security and functionality. An outdated system is more likely to be vulnerable to attacks and may not function optimally.

What is the purpose of a change control process form?

A change control process form is used to document the necessary information about a proposed change, including the reason for the change, its scope, and the systems it will affect, ensuring that all stakeholders are informed and can make informed decisions.

What role does the change control board play in the change management process?

The change control board is responsible for analyzing the risks associated with a change, making decisions on whether to allow the change, and ensuring that all necessary information is considered before making a decision.

How does the change control process ensure that changes are implemented without causing problems?

The process includes steps such as documenting the change, analyzing risks, scheduling the change, and testing the change after implementation to confirm that it works properly without issues.

What is the significance of identifying stakeholders in the change control process?

Identifying stakeholders is important because they are the individuals or departments that will be impacted by the change. Their input and control over the timing and nature of the change can prevent negative impacts on the organization.

Why is it necessary to test changes in a sandbox environment before implementing them in production?

Testing in a sandbox environment allows for the safe evaluation of changes without affecting production systems. It helps identify potential issues, test contingency plans, and ensure that updates work properly before they are rolled out to all users.

What is a backout plan and why is it important in the change control process?

A backout plan is a documented series of steps to revert a system to its original state if a change causes issues. It is important because it provides a safety net to recover from any negative effects of a change and minimize downtime.

How does the timing of implementing changes affect the organization and why is it a consideration in the change control process?

The timing of changes can significantly affect the organization by impacting user productivity and system availability. It is a consideration to ensure that changes are implemented during off-peak hours or maintenance windows to minimize disruption.

Why is it recommended to have a full and complete backup of a system before making any changes?

Having a full backup ensures that if a change leads to problems or data corruption, the system can be restored to its previous state quickly. It provides a fallback option in case the change or the backout plan fails.

Outlines

00:00

🛠️ Importance of Change Control in IT Management

This paragraph emphasizes the significance of a formal change control process in corporate environments where a single change can affect numerous systems. It highlights the need for a structured approach to ensure that updates to software, applications, or network infrastructure are implemented without causing disruptions. The paragraph outlines the potential risks of unregulated changes, such as security vulnerabilities and system inconsistencies, and the necessity of a change control process to maintain system uptime and availability. It also introduces the concept of a change control form, which is a key component of the process, requiring documentation of the change's purpose, scope, and impact, followed by a risk analysis and decision-making by a change control board.

05:01

🔗 Understanding the Broad Impact of IT Changes

The second paragraph delves into the far-reaching implications of IT changes, using the example of an upgrade to shipping label software that could affect multiple departments, including accounting, product delivery, and revenue recognition, even catching the attention of top executives. It underscores the importance of recognizing and assessing the risks associated with changes, which can range from ineffective fixes to system failures or data corruption. The paragraph also discusses the importance of testing changes in a sandbox environment to ensure they do not disrupt production systems and the necessity of having a backout plan to revert to the original state if needed. The emphasis is on the potential for changes to have a significant impact on an organization's operations and bottom line, and the need for careful planning and risk management.

10:02

⏳ Timing and Seasonality in Change Management

The final paragraph addresses the timing and strategic planning involved in implementing IT changes, especially in environments that operate 24/7. It points out that certain times of the year, such as the busy holiday season for retail companies, may require a freeze on system changes to maintain stability. The paragraph also touches on the importance of updating the change control process to improve efficiency and align with company needs. It concludes by stressing that change management is a critical aspect of security policies and procedures, affecting every individual in the organization, and that the process should be well-documented and accessible to all employees, with no changes made without proper approval.

Keywords

💡Change Management

Change management refers to the structured approach an organization uses to make and manage changes to its systems, processes, or procedures. It is central to the video's theme, emphasizing the importance of a formal process to ensure that changes do not disrupt operations or reduce security. The script discusses the necessity of change management in a corporate environment where a single change can affect numerous systems.

💡Corporate Environment

A corporate environment is a setting where business activities are conducted, often involving large organizations with multiple systems and employees. The video script uses this term to highlight the complexity of making changes in such environments, as opposed to a single home computer, where the impact of a change is limited.

💡Formal Process

A formal process is a set of established procedures that must be followed to complete a task or make a change. The script stresses the importance of adhering to a formal process when making changes in a corporate environment to prevent potential issues and ensure that updates are implemented correctly.

💡Software Updates

Software updates are modifications or improvements to software applications that are released by the developers. The script mentions Microsoft's monthly updates as an example of the constant need for organizations to stay on top of these updates to maintain system security and functionality.

💡Security

Security in the context of the video refers to the protection of a system or network from potential threats or vulnerabilities. The script underscores that a system not updated is less secure, which is why having a formal change process is crucial for maintaining a secure environment.

💡Change Control Process

A change control process is a formalized procedure for evaluating, approving, and implementing changes to a system. The script describes this process in detail, including the steps involved, from filling out a change control form to testing the change after implementation, to ensure that changes are managed effectively.

💡Stakeholders

Stakeholders are individuals or groups who have an interest or are affected by the decisions or activities of an organization. The video script discusses the importance of identifying stakeholders in the change control process, as they may be impacted by the proposed changes and may have input on the timing and nature of those changes.

💡Risk Analysis

Risk analysis is the process of evaluating the potential risks associated with a proposed change or action. The script mentions that the change control board must analyze the risks associated with a change, such as the impact on business operations or the potential for introducing new problems.

💡Sandbox Testing

Sandbox testing is a method of testing software changes in a controlled environment that isolates them from the production environment. The script describes using a sandbox to test changes without affecting the live systems, allowing for safe experimentation and validation of updates.

💡Backout Plan

A backout plan is a documented set of steps to revert a system to its previous state in case a change causes issues. The video script highlights the importance of having a backout plan to ensure that if a change fails, the system can be restored to its original configuration without data loss or extended downtime.

💡Maintenance Hours

Maintenance hours refer to the scheduled periods during which system maintenance or updates are performed, typically when the impact on users is minimal. The script suggests that changes are often implemented during off-hours to avoid disrupting the normal operations of the organization.

Highlights

In corporate environments, a single change can affect hundreds or thousands of systems, unlike home use where the scope is limited to a single computer.

Formal processes are essential for making changes in a corporate setting to ensure proper functionality and security.

Microsoft releases updates monthly, and organizations may have hundreds or thousands of applications requiring constant updates.

Outdated systems are less secure, emphasizing the importance of staying on top of updates through a change management process.

A lack of formal change control can lead to inconsistencies and issues with application functionality in a corporate environment.

Change control processes may dictate the frequency, type, and even rollback procedures for changes to maintain system uptime and availability.

A formal change control process ensures that all stakeholders are informed and that changes are made without confusion or errors.

The change control process typically involves filling out a form, documenting the reason for change, and identifying its scope.

A scheduling process is part of change control to determine the exact date and time for implementing the change.

The change control board analyzes the risks associated with a change, balancing the need for the change against potential problems.

Post-change, users may be asked to test systems to confirm updates were applied without issues.

The change control process usually begins with the application or data owner who manages but does not control the process.

Stakeholders, those impacted by the change, should have input and some control over the timing of the change.

Identifying stakeholders is crucial as some changes can affect a large number of people or even a single individual within an organization.

The potential impact of a change can be far-reaching, affecting various departments and even the company's bottom line.

Risk assessment is a key part of the change control process, with risks assigned a value and considered for both making and not making the change.

Sandbox testing environments allow for extensive testing of changes without affecting production systems.

Backout plans are essential for reverting systems to their original state if a change implementation fails.

Having a full backup of a system before making changes is crucial for recovery in case of issues.

Finding the right time to implement changes can be challenging, especially in environments that operate 24/7.

Change management is a critical part of security policies and procedures, affecting every person in an organization.

The change control process should be well-documented and accessible to anyone in the company for review.

Transcripts

When you're making a change to an application or an operating

system that you use at home, the scope of that change

is usually based on a single computer.

But in a corporate environment or a large organization,

one single change could affect hundreds or even

thousands of different systems.

If you're upgrading software or modifying an application

or making a change to a router or a firewall,

you'll need to go through a formal process

to make sure that that change is going to work properly.

These types of changes occur constantly.

We know that Microsoft has updates for their operating

systems every month.

And you might have hundreds or even thousands of applications

that you use.

And those might have constant updates to those as well.

This is something that is incredibly important

to stay on top of because a system that is not updated

is one that is probably less secure.

This is why it's important to have

a formal process for making changes in your environment.

If suddenly everyone was able to make any change they'd

like whenever they would like, you

could run into problems with applications working properly

or inconsistencies in the way that applications

are able to use the operating system.

These processes may dictate how often

you're able to make changes, the type of changes that

can be made, and might even cover things like rollback

procedures just in case you run into a problem

when that change is updated.

Many organizations already have a change control process.

And this makes it very easy to implement and control

any type of change to your environment.

But if your organization doesn't have a formal change control

process, you may find it very difficult

to implement or make changes to this corporate culture.

We have these formal change control

processes so that we can maintain

the uptime and availability of our systems.

We know that everyone is informed.

So there's no confusion about the changes being made.

And we want to be sure that no mistakes are made when people

make changes to these systems.

Here's a summary of a typical change control process.

This might be a little bit different in your environment.

But it tends to follow a similar path regardless

of where you might be.

The first part of the process is to fill out a formal change

control process form.

This is something that everyone has

to do so that all of the standard information

is provided to the central committee that

makes these decisions.

You would document in this form the reason

that you're making this change so that everybody understands

why this change is occurring.

You would then identify the scope of that change.

It might be a single system or a number of different systems.

And whoever's making the decision

to either allow or disallow this change

needs to understand what this scope would really be.

There would be a scheduling process

so we would know exactly when the date and time

for this change would be.

And then we would know what systems

would be affected by this change and the impact of that change.

To be able to make a decision on whether this change should

occur or not occur, the change control board

generally needs to analyze the risk associated

with the change.

For example, this might be a significant change.

And it might be at a time of the year

when the company is very busy.

So the change control committee would

need to balance the risk of not making

the change versus implementing the change

and having a problem.

At this point, the change control board

should have all of the information

they need to make a decision on whether the change is allowed

or not allowed.

And once the change is made, you may

want to have users try their systems

and confirm that the change was updated

without any type of problems.

The change control process usually

starts with the owner of the application

or the data wanting to make a change

to that application or data.

The owner of the application or the data

don't generally control the change control process.

And they're not usually the ones making the actual change

to that application or to that data.

Instead, the owners are the ones managing the process.

The owner is kept informed as the change control

process occurs.

And once the change is complete, the owner

is responsible for testing their systems

and verifying that everything is working properly.

For example, your organization may have a department

for shipping and receiving.

And there may be information that they've

received that says their address label

printers need to be upgraded.

In this example, the shipping and receiving department

is the owner of this process.

And they're going to hand that off to their IT team

to handle the actual change to the printing software.

Another consideration for the change control process

are the stakeholders.

These are the individuals or departments

that will be impacted by the change that you're proposing.

They will probably want to have input on the process

and have some type of control over when

this particular change occurs.

Identifying the stakeholders may not be as obvious

as you might think.

There are some changes that can affect a large number of people

within the organization, or perhaps the change

is only affecting one single individual.

The IT team may need to research and identify

any of the stakeholders who might

be affected by this change.

Let's take our previous example of upgrading software that's

being used for shipping labels.

And you might think that this would only affect the shipping

and receiving department.

But of course, the shipping labels

are also used by accounting to create reports

of what has been shipped.

There might be product delivery frames affected by this change,

especially if you're shipping directly to your customers.

This would, in turn, also affect revenue recognition

because it would affect how quickly you're

able to get product into the hands of your customers.

And this would certainly have the visibility of the CEO.

This is a good example of how something

that appears to be a very simple change to some printing

software could ultimately have a dramatic effect

to the bottom line of the company.

Every change has a different potential impact

on the organization.

So you need to recognize what risks may be involved when

making any particular change.

This might be a risk value that you assign

a high, medium, or low risk.

But these risks could also be very far-reaching.

There may be a case where you install a fix,

but it doesn't actually fix anything.

That certainly has a particular risk associated with it,

or maybe you install the fix and you end up

breaking something else.

This is not entirely unheard of when patching systems.

There might be a failure of an operating system

just because you installed this particular update

or there might be corruption of data, which

means you would need backups.

And all of these would certainly have different levels of risk.

You also have to consider what risks might be involved

if you don't make the change.

For example, there might be a security vulnerability

and if you don't patch this application,

that vulnerability will be available to any attacker that

may be coming across our network.

This may cause an application to be unavailable

if you don't patch the application

or you might have other services that are no longer operating

because you didn't make a change to a secondary service.

Given these risks, you may decide

that you want to do a lot of testing

before implementing this change into a production environment.

And for that, we may use something

like a sandbox testing environment, where

you can perform as many tests as you'd

like and have no effect on your production systems.

This is effectively a technological safe space

where you can make mistakes, you can try different techniques,

and then you can perform extensive testing

after the fact to confirm that the update really did work

properly.

Inside of the sandbox, we can load a duplicate environment

to our production systems.

And then we can try the upgrade, apply a patch, make the change,

and see what effect that has to a system that

is identical to what your users are using in production.

This is also a good time to test your contingency plan.

You can implement the change.

And even if the change was operational in your test

environment, you may want to test your backout procedures

just to make sure that if something does go wrong

in production, you have a documented series of steps that

brings everything back to the way it

was before you made the change.

There are many documented cases through the years

where someone thought that a change was very minor,

they make that change into an environment

without even thinking that they would

need to be able to revert back to a previous config,

and that change ends up bringing down their entire network.

This is why you need a backout plan.

You should have a way to revert back

to the original configuration or something that

would be very similar to what you

started with before the change took place.

In some cases, this is a very simple process.

You simply uninstall the patch that you

installed and confirm that the original files are back

in place.

But some changes are very difficult to revert.

So you may need to have different techniques and ideas

about how you can bring those systems back

to their original form if something does go wrong.

This is why we often say that before you

make any change to a system--

that you have a full and complete backup of that system.

That way, if you do make the change and run into a problem

and then you try your backout plan and have a problem,

you can always go back to your backup.

You may find that the process for approval of the change

is the easy part.

The difficult part is finding time to implement the change.

This is something that has to be planned and considered

before making any significant change to production.

For example, you may not want to make change

during the workday, when everybody is on their systems

and performing their work.

Instead, you may want to have off hours or maintenance hours

where you can make changes without having

significant impact to users.

This is why you often see the IT folks coming in

on weekends and holidays and very early in the morning

just so they can make change without any type of disruption

to the network.

This can be especially challenging

if you work in an environment that is 24 hours a day

and seven days a week, where you have

very little time available to make

any changes in those systems.

You might also need to consider what time of the year

you're making these changes.

Take, for example, a company that is very retail-based

and their busiest times of the year are between Thanksgiving

and New Year's.

In those environments, it's not uncommon for all

of their systems to be completely

frozen during that time frame.

And no changes would be allowed whatsoever.

Only after the new year are you now

able to reintroduce some type of change control

and begin the process of updating your systems.

Hopefully, you can see now that change management

is a critical part of your policies and procedures

for security.

And it affects every single person in your organization.

In almost every environment, this change control process

is well documented, and anyone in the company

can read through the documentation

on their intranet.

This should be part of your standard operating procedures.

And no one should be able to make changes on your network

without receiving this approval.

And of course, your change control process

is going to be updated over time to make it more efficient

and fit the best with the requirements of the company.