What are the Technical Implications of Change Management?

Learning Objectives

Understand the importance of change management processes and the impact to security.

• Technical implications:
  • Allow lists/deny lists
  • Restricted activities
  • Downtime
  • Service restart
  • Application restart
  • Legacy applications
  • Dependencies

Why are Technical Implications important?

As discussed in our post about Change Management, business processes mostly focus on the what, when and why of change management. This is crucial for ensuring that changes are correctly planned, understood and supported by the correct stakeholders and areas of the organisation.

However, the physical change still needs to be made, this is where the technical implications of change management are critical as it is focused on how the change will be made. The technical implications of a change in a large organisation can be much more complex and far reaching than the business implications, due to the technical complexity of large organisations.

Every change to a system, application, or network can introduce potential security risks or operational issues. To ensure a secure and stable change to the IT environment, the following technical implications must be considered:

Allow Lists / Deny Lists

You must identify if the change will require modifying Allow & Deny Lists. An essential part of securing systems during change management is controlling which applications, users, or IP addresses can interact with your systems. This is often done using allow & deny lists:

• Allow Lists (also known as whitelists): These are very restrictive as everything/everyone is denied by default. Only approved users, applications, or IP addresses that are added to the list are allowed to access a system or to perform certain actions. For example, an allow list may dictate that only certain administrative users that are physically logged in to a certain machine is allowed to change firewall configurations, every other user or device is denied from carrying out this action by default.
• Deny Lists (also known as blacklists): These are less restrictive as everything/everyone is allowed by default. Only certain users, applications, or IP addresses that have been added to the deny list will be denied from accessing specific systems or performing certain actions. For example, all IP addresses are allowed to access DustyBugger.com by default, however if I spot any of you carrying out a Denial Of Service attack I will ban your IP addresses!

Security Implications: During a system change, ensuring that your allow/deny lists are properly configured can prevent unauthorised or malicious activity. If a deny list isn’t updated when a change is applied, it could leave the system vulnerable to attacks.

Restricted Activities

Certain activities should be restricted or halted during the change process to maintain security and system integrity. Restricted activities can vary depending on the type of change but typically include:

• Restricting Unapproved Changes: Just because one change has been approved, it does not mean the technician carrying out the change should have permission to change anything else. Therefore it is important to make sure that the change is restricted to the scope that was originally requested in the approval process. This can be achieved by limiting their administrative capabilities using an allow or deny list.
• Halting File Transfers: Large data transfers may also need to be restricted during updates to avoid data loss/corruption.
• Restricting User Access: User access should also be restricted to certain critical systems during maintenance.

Security Implications: Restricting unapproved changes and user activities minimises the risk of security incidents or system instability while the change is being implemented.

Downtime

Downtime refers to periods when a system is unavailable due to maintenance or an applied change. Managing downtime effectively is crucial, especially for critical systems or organisations that operate 24/7:

• Planned Downtime: This is scheduled downtime during a maintenance window where users are informed in advance, and operations can prepare accordingly.
• Secondary Systems: In 24/7 operations where downtime cannot be tolerated, it is common to move operations over onto a second system until the necessary changes and updates have been applied to the primary system.
• Unplanned Downtime: Unanticipated issues or failures caused by changes can lead to unexpected downtime. This is why it’s important to plan for contingencies, such as a backout plan, and conduct rigorous testing before deploying changes.

Security Implications: Downtime needs to be carefully controlled because when some systems are offline, security measures may not be fully active. During downtime, unauthorised users may exploit this opportunity if access controls aren't properly enforced.

Service Restart

Many changes to systems, especially when it comes to patches or upgrades, require restarting critical services. While service restarts are a normal part of system changes, they can also introduce risks if:

• Delayed Restarts: If services are not restarted immediately after applying updates, this can leave systems temporarily vulnerable or unstable.
• Service Dependencies: If some systems/services depend on others to function, then restarting one service without coordinating with its dependencies could lead to cascading failures.

Security Implications: Ensuring that services are restarted promptly and in the correct order is vital to maintaining security. If certain services are not restarted properly, it could leave the system in an insecure or non functional state.

Application Restart

Similar to restarting services, some changes require restarting applications for updates to take effect. However, application restarts usually come with additional challenges:

• User Disruption: Restarting applications can disrupt user workflows, especially in real-time applications like databases or customer-facing systems.
• Loss of Session Data: If users are actively using an application when it restarts, they could lose data or experience errors.

Security Implications: This ties back into restricting activities and scheduling downtime to ensure that application restarts are properly coordinated and communicated to users. It's important to schedule planned downtime, restrict user activity or move onto secondary systems before restarting applications to avoid exposing any vulnerabilities or causing instability.

Legacy Applications

Many organisations still rely on older, legacy applications that are no longer updated or supported by the vendor. This means that making any changes to legacy applications or their dependencies can present challenges:

• Increased Vulnerabilities: Legacy applications no longer receive vendor patches or updates, which makes them especially vulnerable during a change process where supporting security measures may be inactive.
• Compatibility Issues: Legacy applications may not be compatible with newer systems. This can lead to operational failures or security risks that cannot be quickly fixed if a change fails and leaves the legacy application in a non-functional or vulnerable state.
• Outdated Knowledge: Legacy applications may require outdated knowledge to understand how it functions, this makes it difficult to know how any changes to the application or its dependencies will truly affect it. It also makes it difficult to find an expert with the required knowledge to maintain and make the changes for you.

Security Implications: Taking the time to understand and document any legacy applications in your organisation is crucial to make sure they can be maintained and secured correctly. With the correct documentation of how the legacy application is installed and what its dependencies are, it is possible to create mitigating controls that make up for its lack of security patches. However, organisations should continue to assess the risk of using outdated legacy applications versus the cost of replacing them.

Dependencies

One of the most complex aspects of change management is dealing with dependencies between systems, applications, and services. Many systems rely on multiple others to function, meaning a change in one system can have a ripple effect on others.

• Identifying Dependencies: Before making any change, it’s important to map out the system’s dependencies, including software components, services, and network connections.
• Version Conflicts: Changes to one system can lead to version conflicts in dependent systems, potentially causing them to stop functioning. It is important to make sure that all dependent systems are compatible with any new versions before upgrading a system. It is likely that you will have to update multiple dependencies before you can make any changes to your target system.

Security Implications: Failure to properly assess and manage dependencies during a change can cause security issues or system outages. For example, if an anti-virus service is dependent on a system you plan to change, the change could disrupt the service and expose vulnerabilities.

Key Takeaways

The technical implications of change management are just as important as the business processes surrounding it. Allow/deny lists and restricted activities control access to critical systems during changes, while planning for downtime, restarts, and the handling of legacy systems and dependencies ensures that changes do not disrupt operations or introduce vulnerabilities.

By carefully managing these technical implications, organisations can maintain a secure and stable IT environment while minimising the risks associated with system changes.