News and events Own Your Online External Link Report an incident
News and events Own Your Online External Link
  1. Welcome to CERT NZ
  2. Information and advice
  3. Critical Controls
  4. Asset Lifecycle Management
  5. Identifying and managing legacy systems

Identifying and managing legacy systems

The first step to meeting this control is to know what legacy systems are in your environment. Removing legacy systems from your environment can be difficult, but the long-term gain is worth it.

Understand your environment

Identify all the components in your environment and the versions they are running.  Consider all the devices and software within your environment including:

  • servers
  • applications
  • network devices
  • office equipment, and
  • employee provided equipment (BYOD).

Full network scans can be a useful tool to ensure you have found all systems and know which versions they are currently running. Some systems may not be documented, or known to IT or information security teams. Performing full network scans can help uncover this 'shadow IT'

Once you have identified the components in your environment, you need to identify which components are parts of legacy systems. These will be:

  • components that are no longer supported by their vendors, or are at end-of-life
  • components that have not been patched by the organisation.

Compare the current versions in your environment to the ones that are currently in support or available from the vendor. If you are running outdated or unsupported versions, the system that that component belongs to is considered legacy.

Scanning your network for vulnerable and unsupported software is something that should be done on a regular basis. Incorporate this into one if your processes, such as:

  • vulnerability management
  • software lifecycle management process
  • device lifecycle management process.

Understand the risk and context

Consider these legacy systems in the context of their deployment. One seemingly minor issue can reduce the security posture of your entire environment, often through non-obvious means. For example, a single unimportant application running on a Windows Server 2003 server might be perceived as a low risk. That server in your domain may require your entire domain to support obsolete encryption protocols, which could be exploited even on non-legacy systems.

Consider these legacy systems in a business context. What information is held in these systems, and what business processes are supported by them? Consider the risk to your organisation if this information were leaked, or these processes disrupted, by interruption of the legacy systems. Could your organisation survive such an event?

Once you have a complete list of legacy systems, and you understand both their technical and business risk, you can plan on how and when you can replace them.

It may take some time to replace a legacy system, read our mitigation options on ways to mitigate the risks until you can replace them.

Mitigating legacy systems

Managing legacy systems

Restricting access to a legacy system is a way to prevent a security incident from occurring. Take additional steps to be able to better detect and action any incidents.

Below are things you should do anyway, but they’re especially important around legacy systems:

Baseline activity for the system and actively monitor

Determining a baseline for your system is useful when seeking to identify irregularity in the activity in a system. Investigate the underlying cause of any discovered irregularity as this could indicate a breach in the system.

Have a plan for breach/disruption

Identify the data and processes that would be affected by disruption or breach of the system, and how you would respond to this eventuality. The more difficult it is to respond to, the higher priority that system should be for replacement.

Have spares on hand

In many cases, legacy systems are running on unsupported hardware. In this case, how would you deal with a hardware failure? Having spares on hand before you need them can save a huge amount of stress, and reduce your time to recovery. It is not uncommon for hardware to be sourced from international locations, and replacement parts can take days, or even weeks, to arrive.

Extend support with the vendor

You may be able to negotiate extended support with the product vendor, though this is often only a temporary solution, and often costly. Note that this does not resolve the issue. In some cases, extended support will only supply updates for critical security vulnerabilities, and some security vulnerabilities are left unpatched. Even if all security vulnerabilities are patched, this option may increase in cost over time, and the vendor may eventually refuse to continue to provide support.

See also:

Mitigating legacy systems