Whether because of nostalgia, a desire to save costs, ignorance, concerns of business interruption or sheer laziness, there have been countless stories in the press demonstrating that companies and individuals continue to use outdated versions of various critical software programs, including those that connect to the internet.
In computing terminology, the word “legacy" is used to describe outdated or obsolete technology and equipment still being used by an individual or organization. This is particularly true of software. Despite the increasing prevalence of data breaches (think Equifax) arising from the use of unpatched and/or unsupported software with exploitable vulnerabilities, many companies struggle to see the need to replace/upgrade to newer systems. Whether because of nostalgia, a desire to save costs, ignorance, concerns of business interruption or sheer laziness, there have been countless stories in the press demonstrating that companies and individuals continue to use outdated versions of various critical software programs, including those that connect to the internet.
A case in point involves the persistent use of obsolete versions of Windows software. In 2017, studies estimated that seven per cent of computers around the world still use Windows XP. Astoundingly, the United States Department of Defense publicly admitted (during its upgrade to Windows 10) that many of its computers were running older Windows versions, some even powered by Windows 95 or 98 even though Windows 95 operational support was sunset in 2000. No wonder that, in response to various WannaCrypt malware attacks that occurred in May 2017, Microsoft felt obliged to provide a security update to protect Windows platforms that were no longer receiving mainstream support, including Windows XP, Windows 8 and Windows Server 2003. Microsoft had ended support for Windows XP in April, 2014 and Windows Server 2003 in July, 2015, but there were still more than 100 million legacy Windows systems still in use around the world at the time of the attack (the last major update for Windows XP was released in 2008).
Latest News
What will it take to make organizations wake up and deal with these risks? The following is a non-exhaustive list of considerations regarding legacy software that may help organizations better understand the issues and ultimately lead to better mitigation strategies.
Understand current exposure through IT audits
Many data/security breaches arise because organizations are oblivious to the fact that they are actually using legacy software. In order to better understand the scope of potential exposure, entities should engage in a due diligence exercise to audit and catalogue their existing software holdings. This allows organizations to better understand the business processes they control/support as well as the company and third-party information they process/store. As part of this exercise, the organization should determine how its critical software was procured, the nature of the software (off the shelf, open source, proprietary or custom created by a hired developer); trace the history of its deployment (internal vs. external facing, networked vs. stand-alone, accessible by third parties or not connected to the internet) and ascertain the status of past and present support and maintenance efforts.
Review existing vendor agreements
As part of the risk analysis, organizations must also find and review the relevant vendor contracts that pertain to the legacy software. Is the organization obliged to stop using the software following termination or expiration of the agreement? If the organization can continue to use the legacy software, then review the impact of termination or expiration on the legacy software. For example, do representations or warranties regarding the legacy software survive? Do indemnities regarding intellectual property survive? Consider the key terms relating to the use of the legacy software that survive and those that do not survive and any circumstances that could affect such a survival (as in termination for material breach, non-payment).
Other related questions include: Does the vendor agreement address mandatory product support times? Does the vendor agreement contain a wind-down period for legacy software support? Does the vendor agreement allow the company to hire third parties to maintain and support the legacy software following termination or expiration? Are there any geographic or other limitations on such hires? Does the vendor agreement contain any prohibitions against hiring the employees or contractors of the vendor itself to maintain and support the legacy software following termination or expiration of the vendor agreement? If it does, for how long? Are these prohibitions actually legally enforceable in the licensee’s jurisdiction?
Does the vendor agreement contain an escrow section that allows an organization to obtain the source code or documentation of the legacy software and maintain the legacy software if the vendor ceases to offer maintenance and support for the legacy software or otherwise? If yes, review the scope of the source code escrow grant. For example, is the scope of the escrow grant limited to the company’s own employees or can the company use third-party contractors to maintain the legacy software? Can the entity create derivative works and improvements of the legacy software? Can the company sell or commercialize the legacy software? Identify any other limitations on the scope of the escrow grant (such as limitations on the number of legacy software users, geographic limitations, limitations on scalability, other licence-grant limitations such as on premise vs. cloud, etc.) Is the actual legacy software being put into escrow current? Does the legacy software in escrow also contain adequate technical documentation to support the use of the legacy software as it is presently being used by the licensee?
Security issues
Myriad security issues abound for companies that use legacy software. For example, it’s often impossible to patch or upgrade older versions of software, which may lack adequate security protocols and features (such as intruder detection ability, the ability to monitor users, etc). Such software has increased exploitable vulnerability to malware and viruses and hackers, not only because of bugs and vulnerabilities that go unpatched but also because hackers are increasingly looking to exploit these flaws because they present such juicy targets. Legacy software (especially programs that were created on a custom basis or by internal employees) is extremely vulnerable should knowledgeable employees depart or contractors that work on the project retire. Consider the general impact the legacy software could have on the company, including on an organization’s ability to apply for and maintain cybersecurity/cyber-liability insurance and other insurance and higher insurance premiums more generally.
Legal/compliance issues
What legal/compliance issues arise as a result of a company’s continuing use of legacy software? There is definitely increased potential privacy and security vulnerability, given the ongoing pattern of data breaches involving legacy software and systems. This, in turn, raises issues of increased directors’ and officers’ liability and executive liability. Also, organizations face greater risk of regulatory investigations, scrutiny and possible censure from various Canadian federal and provincial privacy regulators (and globally, from such organizations as the U.S. Federal Trade Commission and other authorities, especially in Europe given the impending implementation of the GDPR) if a company continues to use vulnerable legacy software and unauthorized personal information/personal data disclosures occurred because of a failure to meet minimum security safeguards. Legacy software may also impose greater risks on public companies, given recent guidance that requires them to disclose such cyber-liability risks.
For example, on Jan. 19, 2017, the British Columbia Securities Commission, the Ontario Securities Commission and the Autorité des marchés financiers) published CSA Multilateral Staff Notice 51-347 – Disclosure of cyber security risks and incidents that provide disclosure expectations for reporting issuers (“CSA Staff Notice”).
(For the American perspective, see the interpretive release issued on Feb. 21 by the U.S. Securities and Exchange Commission on Commission Statement and Guidance on Public Company Cybersecurity Disclosures available at https://www.sec.gov/rules/interp/2018/33-10459.pdf).
Business issues
The ongoing use of legacy software by an entity may have significant business impacts that should be considered in depth by the organization. Operationally, one must ask whether the legacy software connects to a service provided by the vendor that is also being discontinued and weigh the criticality of these systems to the business and its stakeholders. Also, organizations should consider whether the use of older, unsupported software will allow it to meet its own stakeholder/clients’ needs, in everything from internal response times, ability to meet customer-imposed service levels and, of course, critical security requirements especially if such software is being used in the financial services or health-care industries.
Perhaps most chillingly, the CSA Staff Notice referenced above reported that issuers concluded that disruptions due to cybersecurity incidents could adversely affect their business, results of operation and financial condition. Many of the following frequently identified potential impacts of a cybersecurity incident will apply to data breaches arising from unpatched legacy software, including: the compromise of confidential customer or employee information; unauthorized access to proprietary or sensitive information/destruction or corruption of data; lost revenues due to a disruption of activities, incurring of remediation costs; litigation, fines and liability for failure to comply with privacy and information security laws; reputational harm affecting customer and investor confidence; diminished competitive advantage and negative impacts on future opportunities; operational delays, such as production downtimes or plant and utility outages; inability to manage the supply chain; inability to process customer transactions or otherwise service customers; disruptions to inventory management; and loss of data from research and development activities; and devaluation of intellectual property. It’s not a pretty picture, to be sure.
Prospective software procurement
Thinking proactively, any organization that procures new software should at the same time consider end-of-life issues, however difficult in the glow of the acquisition. For example, buyers should investigate whether the prospective vendor has an end-of-life or end-of-sale policy and, if so, does it dovetail with the buyer’s requirements? As policies will vary considerably from vendor to vendor, the buyer should make detailed inquiries regarding the specifics and track record of the proposed vendor. For example, how much advance notice does the vendor provide regarding termination of maintenance/support? Does the vendor offer additional end-of-life/end-of-sale support for additional fees? If so, for how long? If no formal policy exists, how has the prospective vendor dealt with end-of-life or end-of-sale software for other clients? It’s worth having these discussions with other users of the software or inquire among client user groups to avoid any unexpected surprises. Consider whether the prospective vendor also seems to have a sufficiently deep pool of developers and adequate, scalable bench strength or whether the company’s entire development team rests on the shoulders of one or two people who may go on extended vacations or otherwise leave the vendor some day and paralyze its support capability.
While much of this article paints a dire picture of legacy software, organizations would do well to remember that the risks of using out-of-date software remain high. It is also likely that any organization using vast amounts of legacy software will also be using outdated hardware, all of which may be impacting company productivity. While the thought of engaging in lengthy software procurement and the implementation process may be daunting, it’s fair to say that the risks of continuing to use obsolete software far outweigh the difficulties of upgrading or replacing existing software that has reached the end of its life.
Lastly (and to end on a more positive note), rather than actually running archaic versions of legacy software, fans of vintage software can take solace in a recent February report from Yale regarding the ability to access and use such systems via emulation technology. Thanks to considerable grants from The Andrew W. Mellon Foundation and the Alfred P. Sloan Foundation, digital preservationists are building a shareable “emulation as a service” infrastructure to resurrect thousands of obsolete software programs and ensure that the information produced on them will be kept intact and made easily available for future access, study and use. YaleNews recently reported that it is expected that the project will enable access to at least 3,000 applications, including operating systems, scientific software, office and email applications, design and engineering software and software for creative pursuits such as video editing or music composition. It is expected that the project will be completed in June 2020.