Corporate Legacy Systems in the Face of Today’s Cybersecurity Dilemma

Companies today are very aware of malware, and they accept that a wrong mistake in their cybersecurity preparations can spell an end to their businesses. There is a school of thought that will forever be embedded into the minds of many people in the business, that computer virus comes with its corresponding files that serve as its footprints. Antivirus products are set to scan hard drives and memory for malicious codes.

Unfortunately for many, a virus infection doesn’t always leave traces behind. An enemy that cannot be seen is very difficult to take down, let alone prevent future infections with. A minority of all malware created are fileless-types, such malware does not write files on the disk to operate, they can exist in memory for extended periods of time. As a typical anti-malware scans files for infection, they can never detect a fileless virus.

At the moment, companies desire to strike a reasonable balance between cyberdefense spending and good enough security infrastructure. If they underspend, a false sense of security environment can persist while overspending may cause a lot of money for a company, especially if it is just an SME (Small and Medium Enterprise). Designing security infrastructure is often an afterthought. But, with the regularity of security breaches impacting an array of industries, it’s now more of an imperative to build security into designs early on. The regular stream of hacking headlines should be evidence enough that design security can’t be overlooked.

A related and even more difficult dilemma exists for companies that continue to use software that has known security vulnerabilities, but which the manufacturer no longer supports with patches – for example, this is the case for Windows XP and Vista. To eliminate security risks, such companies may have little choice but to upgrade to new software, which involves both greater expense and greater implementation difficulties than the application of a patch.

In that case, there will be no patch to install. But the lack of a patch will not necessarily excuse the company from liability. The most likely scenario is this. A piece of malware is released that exploits “feature X” flaw that can be found in both a current software product and in that product’s no-longer supported earlier versions. A company using the earlier version falls prey to the malware because no patch has been released.

A somewhat harder question is how quickly patches should be implemented. In part that will depend on the size of the vulnerability and the urgency of the software developer’s recommendation that the patch be installed. But it will also depend on experience. In particular, the speed with which past vulnerabilities have been turned into worms, viruses, or other malware.

As a result, there is a growing tension between the need to patch increasingly rapidly and the patch deployment difficulties discussed above. These deployment issues may themselves raise security and operational issues; courts and policymakers will need to balance such competing considerations in deciding how quickly companies can reasonably be expected to apply security patches.