1.3 - Change Management and Business Processes Impacting Security Operations

Learning Objectives

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

• Business processes impacting security operation:
  • Approval process
  • Ownership
  • Stakeholders
  • Impact analysis
  • Test results
  • Backout plan
  • Maintenance window
  • Standard operating procedure

What is Change Management?

Change Management is the process used to approach, plan and implement changes made in an organisation. In the context of cyber-security this usually applies to changes in the IT environment such as updating software or reconfiguring hardware. However, it can also apply to any other changes that need to be made, such as managing the operational changes of employees. It is important to remember that all types of changes can carry a risk.

The primary goal of change management is to ensure that only authorised changes are allowed and that any changes do not negatively impact the organisation's security or their ability to continue operating as normal.

Why is Change Management Important?

When making a change to an application or system in a small, home-based environment, the scope of that change is usually limited to very few devices. Therefore the impact of any change is minimal. However, in large organisations changes can impact many systems, services, and devices, leading to potentially severe disruptions if something goes wrong.

Consider frequent changes like operating system and software updates. Every type of system, device and application you have installed across the organisation will require updates at different times and in different frequencies. Without a formal process in place, a missed update or incorrectly applied patch could lead to security vulnerabilities, data loss, or downtime.

A well-developed change management process ensures that these changes are applied in a timely, secure manner, minimising disruptions and maintaining security.

When to create a Change Management Process?

Change management processes are best set from the beginning instead of leaving it to be an afterthought as many organisations do. This is because it is easy to implement a change management process in a small organisation with minimal scope and develop it as the organisation grows larger.

If not, it can be an extremely difficult and time intensive task to create a change management process for every type of system, device and application in use across a large organisation that doesn't already have a formally documented process. It can also be hard to change the established processes and culture of your employees who are set in their ways and who do not wish to change.

Business Processes Impacting Security Operations

Changes to systems, applications, or processes don’t happen in a vacuum. It’s crucial to recognise how closely change management ties into broader business operations, particularly when it comes to security.

Business processes like approval workflows, ownership responsibilities, impact analysis, and stakeholder involvement are key drivers behind effective change management. When these processes aren’t aligned with security operations, organisations may face increased vulnerabilities, system downtime, or data breaches.

Let's explore how these business processes directly impact the security of an organisation and ensure that changes are made safely and efficiently:

1. Approval Process

Before any change is made, it must go through an approval process. This process ensures that the change is necessary and that all potential impacts have been considered.

• Request Forms: The first step involves submitting a request form detailing the specifics of the change, including why the change is necessary. This documentation is then reviewed by a committee or a Change Control Board (CCB).
• Determine Purpose and Scope: Understanding the purpose and scope of the change helps everyone involved know which systems will be affected, how they will be affected and also why they will be affected.
• Scheduling: Once approved, the change is scheduled for a time that minimises disruption, often during a maintenance window (discussed later).
• Impact Analysis: A crucial step is analysing the impact of the change on affected systems and stakeholders.
• Approval or Denial: After analysing the risks and impacts, the CCB either approves or denies the change.
• Post-Change Review: After the change is implemented, a review is carried out and end-users are consulted to ensure the change was successful and caused no issues.

A formal approval process ensures that everyone is informed, risks are minimised, and mistakes are avoided.

2. Ownership

Every change process needs an owner. The owner is responsible for overseeing the process, ensuring that it follows the correct procedure, and managing communication between all involved parties. However, the owner is not usually the one performing the change itself.

For example, if a finance department needs new accounting software implemented, the finance department would own the process, but the IT team would implement the technical change. The owner ensures testing is done, updates are provided to relevant parties, and the process is followed correctly.

3. Stakeholders

Stakeholders are those who are affected by the change. It’s important to involve them in the process because they will want to have input on how the change might impact their workflow. This can include individuals, departments, or even the entire organisation, depending on the scope of the change. Stakeholders might not be as obvious as you think, therefore research will need to be done to identify who is truly affected.

For example, implementing the new accounting software in the finance department may not only affect finance department but also the HR team that relies on payroll data, or even the executive leadership, such as the CFO or CEO, who oversees financial reporting and budget tracking. Identifying and involving all relevant stakeholders early—such as department heads, system users, and IT staff—ensures smoother implementation and fewer unexpected issues during and after deployment.

4. Impact Analysis

Impact analysis involves evaluating the potential risks and benefits of a change. This helps in understanding both the risks of applying the change and the risks of not making the change.

• Assessing Risks: When analysing the risk, determine if the change might cause issues like system failures, application errors, or data corruption.
• Consequences of Not Changing: Consider the risks of not making the change, such as leaving security vulnerabilities unpatched or allowing outdated applications to create operational inefficiencies. These can also be seen as the benefits for making the change.
• Risk Rating: Assign a risk rating (e.g., high, medium, low) to help prioritise the change based on the potential impact to the organisation.

5. Test Results

Given the risks involved in making changes, testing is crucial. Before deploying a change to a live environment, it should be tested in a sandbox environment. This is an isolated environment that allows teams to experiment with the change without affecting the actual production systems.

• Sandbox Testing: Test the change in a controlled, isolated environment to detect any issues early.
• Test and Confirm: Ensure the change works as expected and does not introduce new issues before moving it to production.
• Backout Plan Testing: The sandbox environment is also a great place to test your backout plan in case something goes wrong.

6. Backout Plan

Every change should come with a backout plan, which allows teams to revert the system to its previous state if the change causes problems. This is a contingency in case the change does not go as planned.

• Preparing for Reversion: If a problem occurs, teams should have a pre-defined process for rolling back the change (e.g. uninstalling a patch).
• Backups: Ensure that backups are available and up-to-date before implementing any changes so that systems can be restored if needed.
• Testing your Backout Plan: As mentioned earlier, you should always test your entire Backout Plan in a Sandbox environment to confirm it is successful in reverting your system into its previous state.

7. Maintenance Window

The maintenance window is the designated time when changes are applied, this is typically during 'off-hours' to minimise disruptions. Organisations often schedule these changes during evenings, weekends, or holidays to reduce their impact on daily operations.

This may not be possible for 24-hour operations therefore downtime is usually accepted as part of the process. However, to minimise the impact of any downtime any change is usually scheduled at the least busy time of day, such as very early morning. For seasonal industries like retail, it is crucial to plan changes carefully around busy seasons (e.g., holidays) to avoid high impact downtime and a large loss of revenue.

8. Standard Operating Procedure (SOP)

Given how important Change Management is, the entire process should be formally documented, in detail, as part of your organisation's Standard Operating Procedures (SOP). These documents should be available to all employees at all times and should be updated regularly. This change management SOP should, at a minimum, include:

• Clear steps for requesting, approving, and implementing changes.
• A structured process for updating the SOP as new changes are introduced.
• Detailed instructions on handling different types of changes (e.g., software upgrades, hardware installations).

Key Takeaways

Change management is critical to ensuring that changes made in an organisation are safe, well-planned, and do not negatively impact business operations. By implementing a formal change management process, organisations can reduce the risk of unanticipated disruptions and maintain a strong security posture.

This process is an essential part of maintaining a secure and resilient IT environment, particularly in larger organisations where changes are frequent and complex.