legacy
The popular “if it ain’t broke, don’t fix it” principle has reigned supreme in the computing world since the year dot. However, it has become an unaffordable luxury. The proliferation of cyberattacks — including on scientific and medical organizations — presents both IT and infosec services with a real dilemma. To protect critical hardware against attacks, its software must be updated. After all, outdated software means easy-to-exploit vulnerabilities, primitive or non-existent encryption, and rudimentary access control — every cybercriminal’s dream. But updating this software often entails major outlays, plus risks playing havoc with business processes. Is it really that complicated, and, either way, how can the issue be solved?
The risks of updating
Many systems have been running smoothly for years — sometimes decades. They’re not updated because their business owners worry that updates may disrupt the systems irrecoverably. Such fears are not unfounded. The people who installed and initially set systems up may be long retired, and the documentation might be lost or never existed at all. Sometimes this manifests itself in extreme forms; for example, the U.S. Internal Revenue Service still uses 1970s computers and programs in the near-dead COBOL language. Maybe the hardware supplier was sold or taken over, closed the business, or went bust. That, too, is nothing unusual: this year ATM giant Diebold Nixdorf filed for bankruptcy.
In all such cases, there’s no tech support to call should an update go awry.
Moreover, long-serving hardware forms connections with other company systems, and these interconnections can be obscured and/or poorly documented. As a consequence, a system shutdown could cause cascading failures or malfunctions in other systems that are hard to anticipate and prevent. Recovering from such an incident could take days or weeks, and the downtime cost could be huge.
Restrictive upgrade costs
Even if the system isn’t too interconnected and is well documented, updating can still be out of the question due to the exorbitant costs involved. For example, the need to decommission a legacy operating system in an MRI machine may require the purchase of a new device. The cost (around half a million dollars) is very high in itself. But the problem isn’t limited to the price tag of the scanner. Its installation requires a crane, and maybe the dismantlement of part of the wall, and the walls of the room would have to be shielded with a Faraday cage. Thus, that’s no longer an IT upgrade but a major construction project. If the system is deeply entwined with legacy equipment and equally obsolete software, replacing the hardware would require recoding or buying new software, which can be another lengthy and expensive project.
Compensatory measures
Just as expensive vintage cars are kept in a garage, and valuable paintings in a special atmosphere-controlled container, so too do systems that are neither replaceable nor fully upgradeable require a special approach to maintenance. Every possible measure must be taken to reduce the attack surface. Below is a short list of possible compensatory measures to protect legacy IT systems:
Network segmentation. Segregating vulnerable legacy equipment into a separate network segment will help minimize the risk of cyberattacks. You should strive for a high degree of isolation — up to and including physical separation of the network and switching equipment. If this isn’t realistic, be sure to regularly check that firewalls and routers are configured to maintain proper isolation from the “normal” network. It’s also important to track commonplace violations of regulations by employees — such as accessing both an isolated and shared network through different network interfaces from one computer.
Encryption. For systems that exchange information with other computers using outdated protocols, it’s recommended to create VPN-tunnels based on the latest encryption and authentication algorithms. Data exchange outside the tunnel should be blocked.
Upgrades. Even if an upgrade to a modern system is out of the question, this doesn’t mean you can’t install any updates at all. A step-by-step upgrade to the latest available versions of core software and regular database updates for installed protection systems will be preferable to mothballing.
Micro-segmentation of processes. If a business process on a legacy system allows fragmentation, it’s a good idea to leave on it only those parts of the process that cannot possibly be transferred to newer equipment. Transferring even part of the workload to a modern upgradeable platform will make it easier to protect what’s left. For example, MRI images cannot be taken outside the scanner, but they can be uploaded to the clinic’s server, viewed and analyzed on newer computers.
Closed list of applications. The previous tip keeps the range of work carried out on legacy equipment to a minimum. Applications and processes that are part of such jobs can be added to the allowlist, and all others to the denylist. This will significantly lower the risk of running malware or just third-party software that impacts system stability. Such “default deny” scenario can be implemented using specialized security solutions, that are able to operate on systems with limited resources.
Virtualization. In cases of legacy software running on legacy hardware, the use of virtual machines may solve two problems: it allows at least to upgrade the hardware and to implement a number of compensatory measures (such as modern access control and encryption) at the virtualization system and the host system levels. This tip can work well even for some very old information processing systems.
Minimization of access and privileges. Access to legacy equipment (more specifically, to its computer hardware) should be granted to the minimum necessary number of employees with extremely limited privileges. If the system architecture does not allow the required configuration of rights and users, you can try to implement these restrictions at an earlier access stage (during login to the VPN or virtual machine, etc.), as well as restrict access through purely administrative measures (locks and security).
Of course, this will require careful evaluation of the applicability of each measure and the risks related to the smooth and secure operation of the technology being implemented.
Future-proofing
Applying compensatory measures to legacy equipment is by no means purely an infosec task. Infosec experts need to have a complete list of obsolete equipment in a company and to keep track of when its replacement is initiated for business reasons. This is a good time to upgrade in line with the latest security requirements.
More importantly, you need to ensure that systems being put in place today — which will someday themselves become obsolete — don’t inherit the same problems. For this, all infosec requirements need to be factored in when purchasing hardware and software: regular and easy updating of software components; documentation of bugs and vulnerabilities; and, ideally, a secure-by-design philosophy.
For software developed in-house or open-source forks (which are becoming more popular with companies), it’s vital to set stringent requirements for code documentation. In an ideal scenario, document production should become as much a part of the DevSecOps pipeline as autotests.
Tips