When it comes to protecting running applications, traditional defenses that sit on the perimeter lack effective visibility and context to keep pace with attacks. Simply guessing as to the validity of a threat is not enough. This blog spells out five key application security (AppSec) benefits that perimeter web application firewalls (WAFs) can never deliver.
Perimeter Defense Is Too Far Away—and Incurs Significant OpEx
In recent years, network protection has moved closer and closer to the application, from network firewalls to intrusion detection, and from prevention systems to the WAF. The problem is that these protections are not actually close to the application but rather remain on the perimeter, separated from the assets and systems they are intended to protect. Indeed, the proximity of protection to an application, the stability of the protected application, and the security tools used strongly correlate to the required amount of operational effort, operation cost, and overall protection accuracy. More effort and cost are required with less protection potential the further away from the application you go.
The derived outcome of the above is that the closer security tools are placed to application runtime, the better the protection. But things are upside-down when it comes to perimeter defenses, which reside nowhere close to the runtime and incur significantly more operating cost (OpEx). As more and more threats emerge, traditional “outsider” perimeter defenses such as WAFs are unable to keep pace with the rapidly expanding attack surface and rising sophistication of attacks. “Sticking it out” with an outdated traditional AppSec approach just leaves companies open to operational fatigue and the risk of application breach from unknown and zero-day attacks.
Instead of relying on perimeter defenses such as WAFs to protect their applications in runtime, organizations need to embrace self-protecting applications with attack defenses embedded deep inside actual application runtimes. This new, state-of-the-art AppSec approach is more effective than perimeter defenses at detecting and blocking attacks, simply because of where the actual protection is located (inside the actual application runtime).
Going State-of-the-Art: The Five Key Benefits That WAFs and Perimeter Defense Can Never Deliver
Many organizations today depend on WAFs to deliver effective application protection. At the same time, just as many are frustrated that so many damaging attacks are bypassing their WAFs and compromising business-critical applications. For example, one in four data breaches today is the result of attacks exploiting web application vulnerabilities, according to the Verizon Data Breach Investigations Report. This is not a new phenomenon. Traditional perimeter protection (WAFs) has never worked well: The average number of exposures present in an application today is the same as it was two decades ago at 26.7 serious vulnerabilities.
Simply put, when it comes to effective AppSec, the strategy of relying on older traditional perimeter defenses such as WAFs leaves organizations hampered by operational noise and at higher risk of application-based attacks.
Application runtime observability from the inside
Threat detection that operates separately and in front of applications (at the perimeter) lacks the necessary context and visibility to prevent attacks happening inside application runtimes. Without application runtime observability and context, security teams have no choice but to guess from the perimeter at how safe a given input might be. Unfortunately, guessing in AppSec results in many false positives, false negatives, and alert fatigue, and ultimately increased application risk. Misplaced reliance on perimeter security is the primary reason vulnerability numbers remain where they were at two decades ago and why web applications are a top exploit.
In response, security teams need to provide DevOps with remediation clarity and orchestration to make software fixes accurate and actionable. The need to do so is certainly there: Nearly three-quarters of DevOps teams report being inadequately prepared to deal with application security requirements. Accurate mitigation and precise code-level remediation guidance from inside the application runtime is simply impossible with a perimeter defense located outside the application.
Making it even more difficult to protect applications in runtime is the explosion in application programming interfaces (APIs). The perimeter defense guessing game becomes even more difficult. Gartner predicts that API abuse will become the most common attack vector seen by security teams by 2022. In another study, Gartner indicates that as much as 90% of web-enabled applications will have more surface area for attack in the form of exposed APIs rather than the user interface by 2021—up from 40% of applications in 2019. This should be particularly concerning, with WAFs already struggling to protect APIs.
Significant reductions in false positives, false negatives, and alert fatigue
Perimeter defenses are notorious for generating too many false-positive alerts, which is a significant blocker to operations unless an organization is willing to dedicate a team of engineers exclusively to manage constantly required perimeter defense (WAF) configurations. Over half of cybersecurity professionals indicate their organization is at risk due to staff shortages, especially in AppSec areas, making this expertise-required approach not even sustainable and certainly not scalable.
Perimeter defenses rely on signature-based protection that can only reliably block the most commonly known and non-advanced threats. Since zero-day malware accounts for 50% of detections, perimeter signature-based defenses also end up being prone to false negatives of the worst kind, continuously missing the truly critical and damaging advanced threats that target and compromise application code, APIs, and libraries. This is a very serious concern.
Making matters worse, because of the inability of perimeter defenses to effectively identify and block critical advanced threats, security teams are forced—out of necessity—to set perimeter defenses to “monitor-only” mode to reduce all the false-positive noise that is generated. Unfortunately, this effectively disables their entire application defense.
“Low-touch” operations and reduced cost of deployment
Unfortunately, perimeter-based defense solutions (WAFs) require significant coordination between security and network teams to ensure they see the right traffic. Security teams must frequently communicate with development teams, just to arrange configuration time for tuning these “high-touch” perimeter defenses. Quite often, full-time staffing is needed just to manage WAF rules.
Why choose outdated solutions that require an army of expensive experts to make any kind of change? Coordinating updates of static signature-based perimeter rules places incredible demands on many resources and comes with high deployment, configuration, and maintenance costs. This is a serious challenge for security teams that are already bandwidth constrained and facing cybersecurity skills shortages.
“Set-it-and-forget-it” DevOps-native elastic scale
Traditional perimeter defenses have a problem when it comes to scalability. For fast-moving DevOps environments that depend on continuous integration/continuous deployment (CI/CD), WAFs are required to be perfectly tuned and then re-tuned with each new code deployment. This does not support effective scalability. For developers, this constant maintenance disruption of tuning severely limits productivity.
Tuning and redeployment processes for security teams are complex, and business growth slows considerably when scale cannot be performed within a perimeter defense because there is too much maintenance-related activity. Even if constant tun
*** This is a Security Bloggers Network syndicated blog from Security Influencers Blog authored by Derek Rogerson. Read the original post at: https://www.contrastsecurity.com/security-influencers/appsec-goes-beyond-perimeter-rasp