When technology overstays its welcome

Legacy systems and decisions have traditionally been a soft target, denigrated as a root cause of inefficiency or as a roadblock to progress.
 
Five years ago, an Australian survey found one-third of IT departments had a hard time acting on business demands because their current systems were either too inflexible or they spent too much time maintaining legacy systems.
 
In the years since, not a whole lot of progress has been made.
 
I say this because it is technically challenging to banish legacy applications or systems altogether. 
 
The 'legacy' title is progressively bestowed on past or superseded versions of an application or system. Every substantial update or new version creates (or leaves behind) another generation of 'legacy'. Barring a major change in the way many applications are architected, legacy versions will be with us for some time to come.
 
In addition to legacy technology, organisations are also increasingly battling technical debt or 'tech debt' - extra work and expense that accumulates due to poor or rushed implementation decisions.

Like with legacy, McKinsey still declares tech debt to be a resource drain. The consultancy says as much as 20% of the budget for new products ends up being "diverted to resolving issues related to tech debt" and that levels of tech debt have "risen perceptibly over the past three years".
 
The reasons for this are complex, but a separate study suggests the rush to get code into production faster, a lack of standardisation in the development languages and frameworks used, and developer turnover are all root causes of tech debt's growth.
 
The origins of WAF
 
It's easy to see parallels between legacy systems and tech debt. Software developers have had a hand in creating both. Equally, developers have key roles in addressing legacy systems and tech debt and mitigating their impact.

In the web application world, past development practices surrounding the relative security of the code being produced saddled many organisations with tech debt.
 
While there is now much more focus given to creating secure applications by design, coded within the boundaries of specific secure code guardrails, this was not always the case. 
 
Vulnerabilities were often picked up only once code was already in production and quickly overwhelmed organisations with their frequency of discovery. Static and dynamic analysis tools dumped huge quantities of bugs onto development teams that had no possible way to fix so many code issues at once.
 
As a stopgap measure to address this problem, web application firewalls (WAFs) were brought in to filter out rampant SQLi, command execution and XSS attacks that exploited these vulnerabilities and threatened to consume all development and security teams' available resources.
 
A drop-in web application security filter seemed like a good idea. Sure, it sometimes led to blocking legitimate traffic, but it provided at least some level of protection at the application layer. 
 
The idea behind WAF was that the application bugs and security flaws would be triaged for now and then eventually fixed in the code when time allowed.
 
More 'legacy' to deal with
 
Currently, the pressure to move faster with agile methods is creating a faster cycle of version control and a longer line of legacy versions that progressively become unsupported and retired. Keeping pace with that cadence of change can be challenging for businesses.

The older generation of WAFs directed at the problem never worked particularly well, to begin with, often mistakenly identifying legitimate traffic as 'attack' traffic directed at the web app and blocking it. Many false positives come from legacy WAFs' reliance on regular expression pattern matching rules.
 
One way these legacy WAFs try to cut down on false positives and avoid breaking valid traffic is through a "learning mode." 
 
Learning mode learns what normal traffic looks like and what malicious traffic looks like and protects accordingly. But this takes time and is not well suited to the way applications are now augmented.
 
But when you move from waterfall to agile, deployment speed gets faster and faster. The application code changes weekly, daily or even hourly. If you deploy using anything close to a modern cadence, putting the legacy WAF in learning mode on every code change means you are always in learning mode. 
 
Essentially, any kind of learning mode, when applied to modern application development techniques, can't keep up with the pace of production. Like the answer to many 'legacy' challenges, much of the problem with legacy WAFs can be resolved with an upgrade. In this case, moving to a next-generation WAF designed to protect modern applications and provide application-aware defensive coverage to code will be optimal.