Security Experts:

Should Application Security Become its Own Discipline?

Let’s play the “Analyst Firm Dating Game.” We asked four of the top analyst firms what technologies they consider to be in the realm of application security. If we compile their answers into a table, it would look like this:

Web Application Security

(Actually, you don’t date analyst firms, you pay them for their services, but that’s neither here nor there.)

But seriously, are you surprised how many technologies live in the realm of application security? I had to take off my shoes just to count them all. I ran out of toes and had to switch to an abacus. There are 28 different technologies.

Why are there so many?

Because everything is an application these days, making the definition of application security quite broad. Vulnerabilities can metastasize anywhere in an app—from the client to the application server, to the back end—making for a huge threat surface. This depth and breadth of application vulnerabilities provides fertile ground for new technology solutions.

Patch vs. Virtual Patch

The only two technologies all analysts agree on are the Software Development Lifecycle (SDLC) and Web Application Firewall (WAF). The former is the process for fixing bugs; the latter involves applying virtual patches when the dev team is too busy with other stuff.

Mature Application Security Technologies

Three of the four analyst firms agree on Dynamic Application Security Testing (DAST) and Security Information and Event Management (SIEM). Neither technology provides any prevention on its own, but both dramatically increase the security visibility for application owners. Fraud detection has matured as well. FinTech organizations finally have a grasp on how much capital is being lost to fraud.

WAF Derivatives

A new derivatives of WAF approach virtual patching from different angles. Runtime Application Self-Protection (RASP) cuts out the WAF middleman and integrates the WAF technology into the application itself, either at the client or the server. RASP means embedding security policy into the app itself, which, in theory, could have been solved with SDLC in the first place.

RASP seems pretty cool, right? The number one complaint about WAF has been the complicated policies and a lack of trained staff to run them. RASP can mitigate the former, but technology can’t solve the latter. Here’s an example of why neither WAF nor RASP by themselves are the complete answer.

I met with a hotel chain (who’d rather not be named) that was losing $10,000 a week to fraudsters who were brute-forcing their customers’ passwords, transferring reward points into a shared account, and then removing them via gift cards. The chain brought in a WAF, and the WAF specialist added policy to lock the accounts on brute force detection. Problem solved, and half a million dollars saved. Or, so they thought.

Within a week, the fraudsters figured out how to get around the detection. They slowed their brute force attempts to just outside the detection limit and started using a botnet such that each attempt came from a different IP address. Their probes were now so subtle as to be nearly indistinguishable from legitimate user patterns. It took the WAF specialist two more weeks of fine-tuning the WAF policy to detect these probes and protect the reward points.

Attackers are Human; Defenders Must Be, Too

The point is that application security policy can never be static as long as there are determined adversaries. It wasn’t the WAF that saved the day, it was the WAF specialist. He was a real whiz kid—probably one of the top WAF specialists in the country. Of course, he was later lured away for a more lucrative opportunity.

The security skills gap that is so prevalent in the industry today is what is driving another WAF derivative: Application Security as a Service (ASaaS). Usually this is sold as “WAF in the cloud,” but the important parameter in the equation is that these cloud WAFs are staffed by whiz kids that live and breathe sophisticated application security policies. The ASaaS vendors can amortize the whiz kids’ experience with attacks and application frameworks across many different customers. Nearly all WAF vendors offer these services now.

Application Security Should Be Its Own Discipline

Considering that you can find vendors, startups, and specialists in any of these 28 application security technologies, is it realistic to expect any one person to be a subject matter expert in all of them?

Of course not. Thus, one of these analyst firms asserts (and I agree) that application security should be a full-time gig; application security should become its own discipline.

A model already exists for what that discipline might look like: call it DevSecOps. Joshua Corman has been calling it RuggedDevOps for years. The 2015 RSA conference had an entire track dedicated to DevSecOps. Integrating security policy into DevOps, in theory, automates policy and lets developers retain their agility. Everyone wins.

Whatever you call it, DevSecOps adoption, conferences notwithstanding, has been slow. Partly because traditional IT silos themselves are slow and can be resistant to process change. Personally, I think it’s because retaining good developers is really hard when Silicon Valley is always tempting them away. And security developers aren’t exactly falling out of trees, either. Like the practitioners at the intersection of cloud and security, DevSecOps may be one of the most short-staffed fields right now.

And when you have shortages of people, that’s when new technologies start popping up to fill the skills gap. We can expect to see even more technologies in the Analyst Firm Dating Game next year.

view counter
David Holmes is an evangelist for F5 Networks' security solutions, with an emphasis on distributed denial of service attacks, cryptography and firewall technology. He has spoken at conferences such as RSA, InfoSec and Gartner Data Center. Holmes has authored white papers on security topics from the modern DDoS threat spectrum to new paradigms of firewall management. Since joining F5 in 2001, Holmes has helped design system and core security features of F5's Traffic Management Operating System (TMOS). Prior to joining F5, Holmes served as Vice President of Engineering at Dvorak Development. With more than 20 years of experience in security and product engineering, Holmes has contributed to security-related open source software projects such as OpenSSL. Follow David Holmes on twitter @Dholmesf5.