A recent rash of cyberattacks against Magento 1 web commerce sites underscores the criticality of having a strategy in place for securing technology that has reached end of life or is no longer supported by its vendor.
Adobe announced in September 2018 that support for Magento 1 would come to end in June 2020, giving organizations adequate time to port over to Magento 2 or make other arrangements to protect their ecommerce sites. But that warning did not stop a trove of companies from sticking with Magento 1: around 100,000 entities still use the dated platform.
“I call it the tsunami of the past,” said Setu Kulkarni, vice president of strategy and business development at WhiteHat Security. “The software, or the software service (i.e. the API) may reach the end of its life because the organization is no longer investing in it. But that does not mean that no customer is using it.”
Reluctance to move
That’s not to say that there aren’t good reasons for clinging to technology that have reached EOL or EOS.
“Companies often continue using an application past EOL when the upgrade costs and business interruption are perceived as being greater than the risks of utilizing the EOL product,” said Mark Moses, director of client engagement at nVisium. Also a challenge, he added: niche solutions that have been heavily modified or required dozens of interfaces to be built. That would have to be replicated with the required upgrade.
“When those costs are high, the myopic solution is to keep the EOL point solution as-is,” Moses said.
Indeed, the interconnectedness of systems and software can prompt some companies to demur when it comes to moving away from technology that has reached EOL or EOS.
“Every software component is a part of a complex software supply chain that supports an end customer’s business,” said Kulkarni. “So, while an [independent software vendor] may decide to EOL a software or API and in doing so give reasonable motive, still the ramifications of that decision are multi-fold for the end customer who has to re-tool their software supply chain.”
Manufacturing, electricity companies, and other critical infrastructure organizations will often continue to use tech well past EOL or EOS because they rely on operational technology for expensive assets that can far outlive the software that runs on them. Similarly, health care organizations may have EOL software associated with medical devices, such as a very costly MRI machine that has three more years of functional life, but runs Windows XP.
“OT often runs very outdated EOL products, but they are built to have longevity, long after the software has reached EOL,” said Heath Renfrow, director and virtual chief information security officer at the Crypsis Group. “OT equipment is likely not going to be replaced every time the software reaches EOL; it may seem to make little sense from a business perspective.”
And, ultimately, that’s what it often boils down to – a business decision that suits an organization’s risk appetite, Renfrow continued: Do you make the very considerable investment in a new MRI machine, or do you continue to use your current model, which has met EOL from a software perspective but otherwise is fully functional? “There are financial pros and cons on many of these decisions, and for organizations that are cash-strapped, it can be difficult to weigh the costs and benefits.”
There are other considerations as well. If, for example, the end of life product is more mature than new and less tested products, or if all known vulnerabilities have already been patched, or if the organization has suitable mitigation knowledge, “then it could be said that the end of life product is more of a ‘sure thing’ than say, a newer product, where new vulnerabilities are likely to be revealed on a regular basis going forward,” said Kedgley.
Weighing the risk
Regardless of the rationale, ignoring those end of life (EOL) or end of service (EOS) warnings can leave users with no recourse.
“Primarily, there’s a problem with being left behind with no security patches,” Kedgley said. “Vulnerabilities that get discovered after end of life will never be fixed, with every hacker knowing where the soft targets are.”
New Net has “well-resourced banking clients” who still use RHEL 5 and AIX for key apps, as well as retailers who rely on EpoS on Windows 7 and XP.
Renfrow also pointed to the “very long list of software flaws discovered in products every single day,” which do not vanish once support ends. The difference is that developers won’t necessarily provide patches. WannaCry, which exposed the use of EOL Microsoft software around the globe, was what Renfrow calls an exception: “Microsoft went above and beyond and provided a patch for those versions of software that were EOL. That is a rare example of EOL software getting support.”
Organizations also sacrifice technological capabilities by refusing to move. John Yun, vice president of marketing at AppOmni compares an organization’s challenge to prepare for end-of-life “to that of preparing to adopt new features and capabilities.
New tech comes with “new and better security capabilities, without which the organization could not take a leading position on security,” he said. “Not leveraging new features and capabilities can have dire consequences.”
While companies may be ambivalent about their EOL tech, cybercriminals are not. As technology reaches end of life or support, bad actors often already are poised to attack. Tenable Staff Research Engineer Satnam Narang noted last June that cybercriminals who “have routinely targeted Magento sites as part of Magecart attacks, where they inject malicious code into the sites in order to steal payment card information from victims’ customers” were “likely chomping at the bit to exploit any undisclosed vulnerabilities in Magento 1.”
Nearly two months after Narang spoke those words, Sansec researchers discovered an automated Magecart campaign against 2,000 Magento stores that compromised the private information of thousands of customers and could be the largest attack of its kind since 2015.
The point? Cybercriminals are paying attention to EOL and EOS incidents, so companies should also – and that means crafting a plan to go forward.
One strategy to securing web-based applications or APIs is to assess them dynamically in production and use security controls to mitigate security risks on an ongoing basis, said Kulkarni, calling it an approach that does not require significant development investment.
Justin Kezer, managing consultant at nVisium, said companies should track all their assets with their dependencies. “That’s the starting point to be able to plan for what needs to be replaced or updated and when,” he said. “Companies need to be proactive with their SDLC, which includes the EOL.”
Ideally, they should “plan should be to migrate to the latest platforms that are always the most secure and best supported,” said Kedgley. If that is not an option, though, “then they can look at what an auditor calls ‘compensating controls… that serve to plug the gaps in the end of life system.” For example, configuration hardening can minimize the attack surface and breach detection software can at least provide alerts if systems have been compromised.
Having a sound software and hardware lifecycle project management system is critical “to avoiding EOL issues,” said Renfrow. “EOL announcements are normally provided way in advance, providing organizations time to budget and plan for the transition.”
IT and cybersecurity, Renfrow said “must operate like any other business unit in the company, preparing forward-looking budgets and project management plans for such events.” If the budget falls short, then organizations “must measure the risks associated with remaining with an EOL solution and present those risks to senior executives so they can determine whether the risks are acceptable.”
And if leaders feel the risks are unacceptable? “Dedicate more budget to attending to EOL assets,” Renfrow said.