COMMENTARY

We’re all getting older. In IT, we’re faced with issues around software obsolescence and keeping up with patches and updates. But there’s another set of dates we also need to track for all of our software assets: end of life and end of support. End of life lets our teams know when an application will no longer receive functionality updates, but these products can still receive critical security patches. End of support means that no matter what issues arise, there will be no more updates. For threat actors, these applications could be prime targets for years to come.

There are exceptions to this rule, for example: Microsoft has released an update to Windows XP around Remote Desktop Services in 2019, five years after support officially ended in April 2014This prevented attacks similar to the WannaCry ransomware that emerged in 2017. However, we cannot rely on these updates to come.

To manage risk effectively, we need to plan ahead around end-of-life software. In the coming year, more than 35,000 applications will go to end-of-life status. Internally developed applications can experience the same problem if they depend 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 hole in older versions. Installations should have been updated, but as developers moved on to other projects, implementing an update for Apache Log4j was overlooked or missed. Areas such as database servers and web servers are particularly challenging, as these systems typically support revenue-generating applications and therefore have a hard time getting support for migration.

Chief information security officers (CISOs) are aware of these applications, but struggle to get support for changes that are purely for security reasons. There can be other challenges as well. Some applications no longer have official vendor support because their parent company went out of business years ago. Other applications may be tied to specific operating systems or hardware that can’t be replaced without spending millions of dollars on a full replacement. Combine this with the old adage “if it ain’t broke, don’t fix it,” and you can see why security teams can struggle to fix these software assets.

Anticipating the problem

Too often, the need to migrate is seen as too small compared to the revenue streams that come from the service. One CISO I spoke with said that his company knew it needed to migrate, but couldn’t justify the cost of the move if it wouldn’t improve its services or generate revenue from that expenditure. To combat this, it’s important to start planning early for end-of-life software. Keeping track of all your assets and identifying those that still have a year left on the clock before they die can help with this, as it can give you more time to prepare for an eventual migration discussion. Arguing risk early can go hand in hand with discussing the business case for migration or updates with the application owner or developer responsible for the service.

As more and more applications are coming to the cloudThis migration phase can be an excellent opportunity to remove older software components that are no longer supported. Instead of straight lift-and-shift migrations, taking the time to refactor or rearchitect a particular feature can reduce risk. It should also be an opportunity to improve performance and reduce costs, which provides a business advantage.

For other applications, looking at the reasons why that migration can’t happen 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 justify a migration or update now, you can at least highlight the risk involved and track that level of risk over time. Business leaders are then alerted that they can’t keep putting off the problem — this is especially relevant given the The Securities and Exchange Commission’s (SEC) Action to Hold CEOs, CFOs and CISOs Personally Accountable for decisions around risk. This can justify the cost of migrating faster if everyone knows what is at stake, and it includes them personally.

For those assets that are simply too capital intensive to warrant a large-scale move, for example one health care Security leader pointed out that replacing a Windows XP machine wasn’t possible because it was the only system that could communicate with the hospital’s medical imaging machine — risk mitigation is the next best thing, and it can require very specific network segmentation and design to prevent direct access. Also, nothing lasts forever — when assets are replaced, the replacements can factor long-term security and risk mitigation into every decision.

Looking ahead, managing long-term risks around end-of-life software or assets should go hand in hand with planning for migrations. The results should demonstrate business value, so there is a business case for making the changes. Starting earlier and working with business application owners can deliver results on both counts.