COMMENTARY
We all get older. In IT, we face problems around aging software and keeping up with patches and updates. But there is another set of dates we should equally be tracking for all our software assets: the end of life and the end of support. End of life lets our teams know when an application will no longer receive functionality updates, but these products may still get critical security patches. End of support means that there will be no more updates at all, whatever problems come up. For threat actors, these applications can be significant targets for years to come.
There are exceptions to this — for example, Microsoft released an update to Windows XP around Remote Desktop Services in 2019, fully five years after support officially ended in April 2014. This prevented any attacks similar to the WannaCry ransomware that appeared in 2017. Yet we can’t rely on these updates coming through.Â
To manage risk effectively, we should plan ahead around end-of-life software. In the next year, more than 35,000 applications will move to end-of-life status. Internally developed applications can face the same problem if they rely on specific software components. Apache Log4j is a good example of this — this software component was used for its logging functionality within many applications, but it had a serious security flaw in older versions. Installations should have been updated, but as developers moved on to other projects, deploying an update to Apache Log4j would get overlooked or missed. Areas like database servers and Web servers are particularly challenging, as these systems typically support applications that generate revenue and therefore have difficulty getting backing for migration.Â
Chief information security officers (CISOs) know about these applications, but they find it hard to get support for change purely around security reasons. There may be other challenges too. Some applications will not have official vendor support any longer, as their owner company may have gone bust years ago. Other applications may be tied to specific operating systems or hardware that cannot be replaced without spending out hugely on a complete replacement that would run into the millions of dollars. Couple this with the old adage “if it’s not broken, don’t try to fix it,” and you can see why security teams can face problems in getting fixes made to these software assets.
Getting Ahead of the Problem
Too often, the need to migrate is seen as too small compared with any revenue flows coming through from the service — one CISO I spoke to said that their business knew it had to migrate, but could not justify the cost of moving when it would not improve services or deliver revenue with that spend. To counter this, it is important to start early around planning for end-of-life software. Tracking all your assets and spotting those that are on a one-year countdown to extinction can help in this, as it can allow more time to prepare for any migration discussion. Making the argument early around risk can go hand in hand with discussing the business case for migration or updates with the application owner or developer responsible for the service.
With more applications getting moved to the cloud, this migration phase can be an excellent opportunity to get rid of older software components that are no longer supported. Rather than straight lift-and-shift migrations, taking the time to refactor or re-engineer a particular feature can reduce risk. It should also be an opportunity to improve performance and reduce costs, delivering a business benefit.
For other applications, looking at the reasons why that migration can’t take place can be an exercise in understanding internal politics and stakeholders. To cut through this, share risk information in a simple format that everyone can understand. Even if you can’t get a migration or update justified now, you can at least flag the risk involved and keep track of that risk level over time. Company leaders are then on notice that they cannot keep kicking the can down the road — this is particularly relevant given the Securities and Exchange Commission’s (SEC’s) moves to make CEOs, CFOs, and CISOs personally accountable for decisions around risk. This may justify the costs to migrate faster when everyone knows what is at stake, and it includes them personally.
For those assets that are just too capital intensive to justify a wholesale move — for example, one healthcare security leader flagged that replacing a Windows XP machine was not possible because it was the only system that could speak to the hospital’s medical imaging machine — mitigating risk is the next best thing, and it may require very specific network segmentation and design to prevent direct access. Nothing lasts forever, either — as assets are replaced, the replacements can include long-term security and risk mitigation in any decision.
Looking ahead, managing long-term risk around end-of-life software or assets has to go hand in hand with planning migrations. The results have to demonstrate business value, so that there is a business case for making the changes. Starting earlier and getting collaborative with business application owners can deliver on both counts.