Flash was one of the great 1990’s technology, bringing rich content to the (largely) text based Web at the time, but evolved in an era before widespread security risks and is no longer fit for purpose.  Adobe announced its end of life two years ago this month, and yet there are sites that either use it by default, or require it to function at all.  Windows 7 is much closer to end of life, but many companies won’t be migrated in time. Those are just two examples where technical debt will become a security risk, yet we never seem to learn.

If you’ve read my articles, you know I have a business focus.  I get business cycles, budgets, and risk tradeoffs.  In some cases, delayed migration might be the right answer – the classic is a Windows XP system that runs a multi-million dollar piece of industrial equipment. That’s fine to a point, but it requires compensating controls, which may work in isolated instances, but they don’t scale.  For ones like Flash, the only real option is replacement.  We know our adversaries stockpile vulnerabilities in systems with announced end of life to deploy once patches are past.  When that happens companies are going to be faced with either going dark, emergency replacements, or accepting significant risk and liability for what, at that point, will border on negligence.

Looking forward, companies need to move towards life-cycle budgeting for new technology acquisitions. That involves assessing the real lifespan of a particular platform, and planning ahead when the original system is acquired.  That will drive better decisions during the development and acquisition process, to avoid vendor, and version, lock-in that tie solutions to dead-end platforms.  We also need to do the same thing for existing systems: take inventory and do a realistic assessment of the lifespan of the assets.  Call it ‘viability scanning’ to go along with ‘vulnerability scanning’.

This analysis is a convergence of enterprise architecture, IT governance, program management, and cybersecurity.  On the technology side, it needs to include end of life dates, vendor history, vendor viability, product viability and openness.  On the skills side it includes the ability to hire quality staff to maintain, enhance and if necessary, port the application going forward.  On the business side, it needs to be baked into the overall business plan and multi-year budget cycle.  Technical debt always costs more at the end of the loan than the beginning – just ask the victim of any recent breach where the patches had already been released.

Equally important is the vendor side of the equation.  Vendors need to announce end of life dates, rather than letting people assume from past behavior.  Better yet, they need to have a policy forannouncing those dates – a promise against short-notice end of life surprises.  For example, on the good side is Microsoft, who has both pieces in place – no one’s surprised when they drop support.  The counter-example is Apple, who has neither – we never really know when an OS version is no longer supported…at best we’re left to guess.

In the end though, it’s up to the business owners to make the decision.  Technical debt only gets worse, and I’ve yet to see an organization that does well with deficit spending.