Retiring service components securely

Legacy and dormant systems can pose significant security risks so it is important your service operates with only the components that are necessary for it to run effectively.

Securely retiring components such as applications, platforms, cloud resources and infrastructure will allow you to:

• ensure sensitive information is wiped or destroyed
• reduce the risk of data breaches and unauthorised access
• remove redundant infrastructure that could be hijacked by adversaries for malicious purposes
• remove data in accordance with relevant legal and regulatory requirements
• reduce (or remove) your service’s attack surface and strengthen your organisation’s security posture

This may take place as the applications and platforms evolve during the lifecycle of your service, on expiration of a supplier agreement, following a pilot programme, or when the entire service needs to be retired.

Completing this activity will help you to achieve the outcomes included in the Secure by Design principles to adopt a risk-driven approach, minimise the attack surface and make changes securely.

Who is involved

This activity should be carried out by business analysts and technical teams (DevOps) responsible for the maintenance of the service with support from security professionals. You should consult with security professionals when planning the retirement of complex components to ensure the implications and risks have been fully considered.

Your project’s Senior Responsible Owner (SRO), service owner and product managers should be kept up to date of the progress and outcome of retirement activities so they can make informed business decisions. Your organisation’s Chief Information Security Officer (CISO) and Chief Digital and Information Officer (CDIO) may need to be involved if the roles responsible within your project are being wound down as part of the retirement process.

How to retire service components securely

You should create a standard process for retiring system components to avoid overlooking or neglecting any aspects that could lead to vulnerabilities, data compromise or compliance issues. Your organisation’s information security teams may already have policies and procedures related to the disposal of assets that you can use as the basis of your plans.

When retiring your data, components or system, ensure you are documenting every step, including logging any serial numbers. This will help during any future troubleshooting or auditing activity.

Step 1: Refer to your asset list

You should maintain an active inventory that documents your service assets, which will include information on their purpose, asset owners, and the type of information they hold.

This will provide you with details on the importance of each asset and how it is integrated into the system, helping you to establish the consequences of retiring components in relation to the impact on the rest of your system.

Following the effective retirement of any components, your asset list should be updated to reflect the change.

Step 2: Collaborate with asset owners

Those accountable for the assets scheduled for retirement should be included in the plans to remove parts of the service so they can understand their cyber security responsibilities. This should also extend to asset owners of any connected parts of the service so they can be aware of any potential impact on their operations.

Work with stakeholders to establish the milestones related to the retirement and any relevant compliance requirements related to data that need to be assessed.

Step 3: Conduct a retirement risk assessment

When performing a security risk assessment on your service you will have analysed the threats and vulnerabilities related to your service when it is active. A retirement risk assessment follows a similar process, but with the assessment done on the basis that certain components, or the entire service, are no longer operational.

The assessment should be based around questions such as:

• How sensitive is the data held within assets?
• Does data need to be retained, migrated or securely deleted?
• Does the retirement process create any temporary risks that need to be mitigated?
• What other assets, dependent services or systems are impacted by the retirement?
• Will retirement lead to increased risk to other areas of the service?
• What underlying assets or infrastructure may be left vulnerable?

Step 4: Create necessary backups

There might be regulatory or contractual obligations to create a backup of your system or the assets within it before retirement can take place. For example, there may be a requirement to comply with your organisation’s data retention policy, or a need to store data at The National Archives.

All data backups should be treated with the same security as when they were an active part of your service. They should be encrypted and protected from unauthorised access or modification.

Conduct the appropriate tests to ensure that information can be successfully restored. If a situation arises where the data needs to be accessed, the backup needs to be reliable and complete.

Step 5: Remove the data

Based on your risk assessment, take the appropriate actions to remove the data by sanitising any systems where it is held, including local devices and within cloud storage.

File deletion or hardware formatting is often not a secure method of destroying data as it can leave remnants that can be harvested by attackers. For sensitive data you may need to consider the physical destruction of storage devices using methods such as degaussing or shredding.

If you use a third party to destroy your data or devices, obtain the necessary certification to confirm they have carried out the task as intended and share it with stakeholders within your project and wider organisation.

Step 6: Complete the retirement

Compile a formal close-out report that summarises the actions taken to retire the components or service. This should include any residual risks and any associated security recommendations.

This should be shared with your project’s SRO, CDIO and CISO, and contain enough information to give them confidence that components have been fully and safely decommissioned. Any residual security risks should be recorded in the risk register and monitored until sufficiently mitigated.