Technical Change Management - CompTIA Security+ SY0-701 - 1.3
Summary
TLDRThis 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
🛠️ 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.
🔄 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.
📊 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.
Mindmap
Keywords
💡Change Management
💡Technical Staff
💡Change Control Process
💡Allow List
💡Deny List
💡Vulnerabilities
💡Malware
💡Change Control Board
💡Downtime
💡Version Control
💡Dependencies
💡Legacy Applications
💡Reboot
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.
Ver más vídeos relacionados
![](https://i.ytimg.com/vi/48wRbMdHFVI/hq720.jpg)
Change Management - CompTIA Security+ SY0-701 - 1.3
![](https://i.ytimg.com/vi/94TPgSVgeJE/hq720.jpg)
O roadmap do Control
![](https://i.ytimg.com/vi/eNYNv156YlY/hq720.jpg)
Engenharia de Software - Aula 16 - Gerenciamento de configurações (Parte 1)
![](https://i.ytimg.com/vi/u61J0xR_XPU/hq720.jpg?sqp=-oaymwEmCIAKENAF8quKqQMa8AEB-AH-CYAC0AWKAgwIABABGGUgZShlMA8=&rs=AOn4CLAfO74Ozi7vncxUDCI3-jb1JsOSkQ)
Encryption Technologies - CompTIA Security+ SY0-701 - 1.4
![](https://i.ytimg.com/vi/p4DVNKKvrOs/hq720.jpg)
MacVoices #23194: Joe Kissell Takes Control of Your Digital Legacy (1)
![](https://i.ytimg.com/vi/tiHKefWOyrY/hq720.jpg)
Microservices with Databases can be challenging...
5.0 / 5 (0 votes)