.svg)
One of the things I like to focus on is solving real problems for security teams rather than getting lost in industry jargon.
The core question we always ask is, “What problem are we solving?” By understanding the true needs of security teams, especially those in product security, security engineering, and application security who protect applications and handle incidents, we can better address the demands of defensive application security.
This blog post introduces a defender's version of Maslow’s hierarchy of needs for security outcomes. This framework prioritizes minimizing costs for engineering and security teams while maximizing the costs for attackers. By addressing these needs systematically, security teams can create robust, efficient, and effective defenses that support their organization’s broader goals.
Defender's Hierarchy of Needs
Let’s start with looking at security needs. This means a focus on solving real problems for security teams rather than getting lost in industry jargon or market positioning, in other words, “what problem are we solving?”
If we look at what really matters for blue teams—those folks in product security, security engineering, and application security who are on the front lines protecting a company’s applications and dealing with incidents when they happen, we can get a better handle on what is needed for defensive application security.
I’ve boiled these outcomes into a defender’s version of Maslow’s hierarchy of needs. The concept is the same - lower level needs come first, then only after the lower level need is met, does the next need become relevant.
The three needs I’d put forth are in the table below:
Do no harm to engineering
I recently met with a customer who turned on the WAF that was built into their cloud provider. The problem was, this WAF was built on modsecurity, which uses an obscure language (seclang) that nobody on their team was able to understand. Making matters worse, after they turned on their WAF, they caused an outage with their core business application that they weren’t able to quickly diagnose or explain because they couldn’t understand which rule was blocking requests, resulting in them being forced to shut down their WAF and facing an uphill political battle with engineering to turn one on again.
Security teams need to keep things smooth for the engineering team. If security led initiatives (like new tools, new processes, or new programs) cost too much, slow things down, or cause production issues - engineering organizations will quickly lose patience. This results in a slow erosion of security influence - ranging from symptoms like security vulnerabilities and findings being postponed or ignored in favor of other priorities, or security tooling getting turned down and ripped out in order to improve system performance and reliability.
Engineering costs aren’t just about financial costs, i.e. the annual license costs of a tool. They are holistic and include a variety of factors, including:
- Deployment Costs: The cost of instrumenting or installing a security tool or program. For example - updating network configurations, updating a helm chart, or granting IAM permissions.
- Performance Costs: Costs to system performance (latency, error rates), availability, and compute and storage costs (i.e. the costs of logging or agents).
- Velocity Costs: Engineering teams are busy and time is their most value asset. A sprint spent on installing a security tool can be a very expensive ask for a fully loaded engineering or SRE team.
Maximizing Attacker Costs
One security team I spoke with recently underwent an extended credential stuffing attack. The attacker would send thousands of stuffing attacks to an API endpoint in a short period. Eventually the customer’s WAF recognized the attack and put the attacker’s IP address in a penalty box. The problem was that thousands of attacks had already gone through. Once the attacker got blocked, they stopped their attack - but then resumed their attack once the penalty box had expired. In this instance, the attacker had figured out that this customer’s infrastructure would block them after a few minutes, how long the penalty box was, and how to cycle their attacks over and over again in order to achieve their goal.
Many security tools are based on a “lock the doors” approach. They are focused internally on your own application surface - making sure that they are configured correctly with the right security hygiene - such as complex passwords, MFA, and modern auth protocols.
While there many attackers that can be deterred just by having some basic defenses in place and who will just move on to a new target, there are many others who will stay focused on their goal and vary their approaches based on how your defenses respond. Given enough time and effort, an attacker is going to be able to compromise almost any defense. The key to an effective defense is to increase the cost for the attacker so that it becomes less appealing for them to do so, especially at a time when attacker costs are continually decreasing due to the advances in automation and AI technology.
Security teams need to make it more expensive for attackers to plan and execute attacks. The best way to do this to focus on the jobs that their jobs to be done:
- Recon Costs: finding vulnerabilities, misconfigurations, and mapping your attack surface, and your existing defenses and how they respond
- Attack Script Generation: generating realistic looking attack payloads that look like your normal business logic yet can compromise your underlying systems
- Defense Evasion: evading simple detection, such as using VPNs, rotating IP addresses, rotating user agent strings, and so forth.
- Attack Infrastructure Actually planning and running attacks across distributed infrastructure over time, such as low and slow extended attacks.
Minimizing Security Team Costs
In the past few years, I’ve spoken with dozens of security teams that are using a name brand API security tool. However, I haven’t met a single customer that has actually turned on any of these tools in blocking mode.
Why? because they are too afraid of the false positives and noise that the tool creates. Turning a tool into blocking mode introduces a whole new host of operational requirements to a security tool, such as being able to reliably explain what requests were blocked and why in real time because.
The root driver of these requirements is the lower level need of a security team - keeping engineering happy. To keep engineering happy, security teams have to be able to explain why a request was blocked, show why a production issue wasn’t caused by a security tool, provide transparent metrics about tool performance directly in the observability tools that engineering already uses, and many more.
Next, security teams need to keep their own internal costs in check. Like engineering costs, these costs aren’t solely driven by vendor license fees. They also need to include costs associated with total costs of ownership - including initial setup and configuration, ongoing maintenance and tuning, and also ongoing testing. Typical costs for security teams include:
- Alert Investigation: investigation of alerts, reproducing them, and finding the root cause. Anomaly based systems can’t do any of this reliably which is one of the core problems with existing solutions.
- Rule creation and management: being able to understand how an application is being attacked and coming up with rules to defend it
- Testing - being able to test a new security policy to see if it works to stop attackers, and also whether it impacts the performance of an application
The reason that many security tools struggle is that they focus on minimizing costs for the security team, but forget the more critical security team need which is on minimizing costs for engineering.
Effective security needs to be real-time, precise, and reliable. Blocking the wrong things can hurt the business, so accuracy is crucial. By prioritizing these needs, security teams can build strong defenses, optimize resources, and work better with engineering teams. This approach not only protects the organization but also ensures that everyone involved can do their jobs effectively and efficiently.