Evaluating the security impact of changes

Changes may be small modifications to existing technology components or a significant overhaul of your service design. Regardless of the size of the change, it is still important to analyse and mitigate any newly introduced threats or vulnerabilities that may result from it.

Evaluating the security impact of changes will allow you to:

• manage the security risks of the service within your risk appetite from the start of your project and throughout the lifecycle
• reduce the risk of introducing weaknesses into the service that could cause potential data breaches, disruption, or open up routes for attackers into your whole organisation
• allow security to be an enabler rather than an obstruction to development
• keep your threat model and risk mitigations consistent with the latest service design

In delivery environments where service updates are made iteratively, security should play a standard role during the development, testing and assurance phases of a deployment process. Using the change request and approval processes already in place within your organisation, you should integrate the necessary security checks at the appropriate moments to create an efficient workflow that embeds security within project delivery.

Completing this activity will help you to achieve the outcomes included in the Secure by Design principle to make changes securely.

Who is involved

Project and delivery managers should work with technical architects and security professionals to ensure that the necessary security steps are included naturally within change management and service development workflows.

Development teams should be consulted to ensure they are aware of the security assessment processes and the potential impact it may have on their deployment activities and timescales.

In most modern delivery environments, where teams work in sprints and deploy changes frequently, it’s important to have security normalised within the change processes.

How to evaluate the security impact of changes

The purpose of security reviews as part of the change management process should be to ensure that the security posture of the service is not compromised and continues to meet the business objectives and user needs, rather than to create an obstacle to development.

Some systems may continuously evolve through small iterative updates, such as software patches. It’s important to allow these to take place so your system can remain secure and operational, while simultaneously ensuring they align with your security policies and compliance requirements.

Step 1: Understand the scope of the change

Changes to services occur for many reasons. This includes internal factors such as business or user needs, or as a consequence of external influences such as third-party software upgrades or updates to regulatory policies. Changes may also come about due to security requirements or in response to a security incident.

As soon as the need to change a service has been identified, your process should document the nature of the change by asking questions such as:

• Why is the change request being made?
• What areas of the service (including system components and data assets) will be affected?
• What is the proposed solution?

Step 2: Analyse the security impact of the change

Your security impact assessment should include a review of plans and documentation to understand:

• how the change may affect your threat landscape and attack surface
• how the change may affect your existing security posture and security controls
• how existing controls may need to be adapted or updated
• If any additional security controls are required
• what the security impact would be of not making the change
• how easy it would be to roll back the change if required
• if any updates are required to your threat model and risk assessment

You may not need to perform a full security review if it is evident from the scope that there are no cyber security implications to consider. Make a note of this decision and allow development to progress.

A thorough security assessment should be carried out when proposed changes impact areas where vulnerabilities are most commonly found. This includes, but is not limited to:

• installation of a new or upgraded operating system, middleware component, or application
• modifications to system ports, protocols, or services
• installation of a new or upgraded hardware platform
• modifications to how information (especially personal data) is processed, stored, or transmitted
• modifications to cryptographic modules or services
• modifications to security and privacy controls, such as identity and access management
• procedural changes that may open up opportunities for fraudsters to misuse the service

Step 3: Document the security considerations

You should record the security assessment results and proposed actions within the change management tools used by your delivery teams. This should also include a clear set of recommended actions to implement appropriate security controls relevant to the change.

Example change control scope

• What is the purpose of this change? To upgrade the Active Directory infrastructure to the latest version, improving security, performance, and introducing new features.
• What systems and components are affected? The entire Active Directory infrastructure, including domain controllers, DNS servers, authentication mechanisms, and user management tools.
• What is the proposed implementation plan? A thorough evaluation of the existing environment, testing the compatibility of applications with the new version, and conducting a phased upgrade with proper rollback procedures in case of issues.

Example change control security assessment

• What are the potential vulnerabilities and risks? The security assessment identified potential risks, such as security misconfigurations, compatibility issues with existing security solutions, and the need to ensure a smooth transition to the upgraded version without compromising security.
• What is the expected impact on existing security controls? The change requires reviewing and adjusting existing security controls, including password policies, access controls, group memberships, and permissions, to align with the updated Active Directory version and security best practices.
• How will this change affect compliance with security standards? The upgrade will be performed to meet the Centre for Internet Security (CIS) Critical Security Controls and Microsoft security guidelines, to maintain compliance with relevant internal security assurance framework and industry good practice guidance.
• What is the potential impact on data confidentiality? Data encryption, secure communication protocols, and proper access controls will be enforced to protect the confidentiality of sensitive data stored within the Active Directory, such as user attributes, group membership details, and access control settings.
• What is the potential impact on system availability? The upgrade will be planned and executed in a manner that minimises the impact on system availability, including scheduling the upgrade during off-peak hours, utilising redundant domain controllers, and conducting thorough testing before implementing the changes in the production environment.
• What is the potential impact on system and data integrity? The change process will include measures to ensure the integrity of the Active Directory, such as verifying the integrity of the Active Directory database, performing data backups, and conducting post-upgrade tests to validate the integrity of user accounts, group policies, and security configurations.

Step 4: Check security recommendations have been followed

Prior to any changes being released, you should check that delivery teams have worked through the solution to satisfactorily consider all the security elements that had been identified. This should be done in a separate non-production environment through code reviews, vulnerability scanning, or penetration testing, depending on the nature of the change and the severity of the security risks.

It’s possible to implement automated security testing (such a static or dynamic code analysis) throughout the development process to identify any vulnerabilities or weaknesses in the code as it is being written. This should be an additional check rather than a replacement for review by a security professional.

As the impact of some changes will not be fully evident until they have been deployed, update your regular security testing processes (manual and automated) to include the changes. If there are unexpected security consequences that result from the change, take the appropriate action to roll back the update to a previously secure version of the service, or begin a new change request with a solution to fix the issue.