When your service needs to change due to business needs, infrastructure updates or regulatory requirements, the security posture of your system may be affected. You need to actively revisit the risks and impact of these changes so they can be made securely.
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:
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.
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.
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.
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:
Your security impact assessment should include a review of plans and documentation to understand:
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:
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.
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.
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.
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.
This activity is part of the ‘Maintain continuous assurance’ stage of Secure by Design, which also includes:
Read the Secure by Design activities
The Secure by Design approach will evolve to reflect the needs of government digital services. Your feedback will help us to improve it.
Last update: 31 January 2024
OFFICIAL