More is less: stop adding to your security tool technical debt

When security teams hear about a new type of cyber attack, they often rush to add new tools to defend against the latest threat, thinking, “The more we throw against the bad guys, the better.” Although well meaning, this results in a pile up of legacy web application firewalls (WAFs) left over from prior years.

When I come across these customer scenarios, I’m reminded of a term that legendary programmer Ward Cunningham coined in the 1990s that we all no-doubt know now: technical debt, a popular metaphor in software development circles to refer to the extra work and expense that accumulate due to poor design decisions.

The fact is that many of these legacy WAFs don’t produce meaningful security value and involve extra costs due to their need for ongoing maintenance. At the same time, new generations of security stakeholders make investments in different tools as they come and go, thus adding to that pile of technical debt.

It’s time to get out of technical debt. And while modernizing this unruly legacy patchwork of products might not be an overall fix, you can at least stop adding to it today. 

Why is more often less? 

As attacks proliferate and become more sophisticated, adding new WAFs to repel each new threat actually makes it harder for defenders to get an accurate overall read on their security situation. Instead, they receive partial views because most legacy WAFs force customers to work inside of their individual consoles or comb through log files. 

Plus, as security vendors bolt on new capabilities via acquisitions without integrating them, each tool — such as an appliance or cloud-based WAF — will have different interfaces that must be learned just to confirm if an attack actually occurred. This further fragments a security team’s view across their application footprint and complexity destroys any chance of gaining full context.

Organizations clearly need uniform protection regardless of where their apps or APIs reside. But they increasingly are left to grapple with generational differences that exist inside their infrastructure — such as when their infrastructures got built or whether their portfolios reside on-prem, in the cloud, or in a Kubernetes pod. 

It’s crucial to know whether malicious web requests are trying to access your server instances and what they’re trying to do. The same goes for understanding where the originating requests emanate from. These layers of tools hamper finding easy answers to: What else might attackers try? Are they trying to enumerate directory names? Are they targeting the authentication flow or the shopping flow?

Defenders should have quick access to an easy-to-understand, unified view of production security data to know what’s happening across all those different layers. That same information should be available in the tools they already use, from SIEM tools like Splunk to DevOps tools like Slack, PagerDuty, and Jira. Instead, they’re left wasting valuable time scrambling to pull together telemetry that ought to be at their fingertips in the first place.

A future-proof WAF

I'm not arguing on behalf of more WAFs. I'm arguing for a better WAF, that does more jobs to get rid of all the technical debt that’s piled up over the years.

Most security teams are not going to be eager to rip and replace their entire infrastructure on the basis of a marketing pledge. Yet we’re at a technology crossroads where antiquated WAFs actually constitute a net negative due to the amount of maintenance they require, not to mention their predilection for blocking legitimate traffic and causing false positives.   

As the industry increasingly moves toward a more distributed edge compute infrastructure approach, any solution should be easy to deploy and integrate with other security tooling that the customer has already invested in. That means security instrumentation that is easy to install and manage yet won’t break any apps with piles of false positives. 

Current CIOs and stakeholders need to ask themselves whether they really need a new WAF for every attack vector or if there is a better way. They can reduce cost and tech debt by putting a modern app and API protection solution in place that reduces significant maintenance costs and is also future-ready to meet new threats.

Teams need solutions that deliver the promised value without causing new operational headaches. The future always remains in flux, so that requires a security architecture flexible enough to protect applications and APIs anywhere – whether in a data center, in the cloud, on the edge, in a container, or somewhere else yet to be invented.