Imagine for a moment a major airline only checking 10 percent of its fleet for safety problems. Now imagine that when they do check an aircraft, they find 22 safety problems (some major, some minor). That would represent a crazy business risk for any airline. Roughly 90 percent of the fleet wouldn’t be checked for safety and mechanical problems. That would never fly. But yet, I am here to tell you that 90 percent of applications in most organizations are naked -- since they have no application security defenses in place.
When I say "application security" I’m not talking about infrastructure, operating systems, firewalls, intrusion detection systems, etc. I’m talking about the custom code you wrote for your business, internal and external. The defenses we have for these custom applications don’t work. Not surprisingly, this is where 54 percent of the breaches come from. Here’s why they aren’t protecting us:
Network security products work because they know what’s behind them. They know that they’re defending Windows, MacOS, Internet Explorer, and Google Chrome so they know how to identify attacks on those products and stop them. Custom application code is different. Every custom application is a beautiful and unique snowflake; you can’t identify attacks on these snowflakes by looking at network traffic. Period. Only the application knows what defenses are in place and what input will allow an attack to succeed. The trick is knowing how to get this knowledge out.
The image below is an attack on one of those snowflakes that happens to process Morse code.
In fact, this is a Cross Site Scripting (XSS) attack encoded using Morse code. To state the obvious, there is no product on the planet that stops attacks in Morse code. I use this exaggerated example to make a very serious point. The attack could be a number, a short string of any characters, a null byte, anything... There is no way to know what an attack is unless you know the application itself.
Application security programs aren’t working
I’ve been in the application security field for a few decades now, and I’ve worked on AppSec programs at almost a hundred companies and federal agencies. What I see is that most organization have hundreds or thousands of web apps and web services. Yet even the best funded and "mature" programs are only really testing 10 percent of their applications. That leaves 90 percent naked, with no real security. And many of the breaches you read about are against the 90 percent. The 10 percent are in pretty bad shape, too, averaging 22.4 serious vulnerabilities per application.
These stunning numbers come from Aspect Security’s "2013 Global Application Security Risk Report." We used a combination of manual code review, manual penetration testing, and automated tools to analyze thousands of critical applications. The most prevalent vulnerabilities are: Identification and Authentication, Input Validation and Encoding, Session Management, Sensitive Data Protection, and Access Control. Compare these results with similar results from tool vendors, and you’ll see a striking difference -- because tools alone can’t effectively test for at least three of the top five categories.
Click to continue to page 2: The Way Forward
The way forward
Over the past 10 years, many organizations have created a separate application security group that does scanning and testing. But in the past few years, software development has simply exploded, making the AppSec group a bottleneck and putting it under continual pressure to go faster and handle a larger portfolio, which lowers the bar and produces fewer results.
To find answers, let’s zoom in on a specific vulnerability -- clickjacking -- where the attacker frames your web page, makes it transparent, and floats it over its own site. When users try to click on the buttons and links on the attacker’s site, they actually click on your transparent page, doing things the user didn’t intend. As long as the unwary victim is logged in, these hijacked clicks can cause real effects in your application. Fortunately, the defense is very simple: Just add an X-FRAME-OPTIONS: SAMEORIGIN header to all your pages.
Compare that to performing a penetration test or scan on every application in your portfolio for this problem, which would take forever. We’re looking for a continuous, real-time way to monitor the whole portfolio at once. Fortunately, there are a lot of ways to accomplish this. My suggestion is to use a passive tool (like OWASP’s ZAP) to verify that the X-FRAME-OPTIONS header is set on all your pages in a test environment. If you’re interested, you can check your website's headers for yourself using a free online tool I wrote called CheckYourHeaders (named after a great Beastie Boys album).
Here are three ideas that you can use to transform your organization to a continuous application security approach. Remember, vulnerabilities are like termites -- every second they go undiscovered, they get more expensive.
Idea 1: Stop doing application security one-application-at-a-time. Instead, look to continuous, real-time, positive, portfolio-wide monitoring as described above. Over time, you can convert all of your security concerns into continuous, real-time monitoring and move away from the periodic tests. Instead of starting over from scratch each year, you can improve continuously
Idea 2: Standardize defenses. Help your developers by giving them a great set of enterprise security defenses. Verifying applications at portfolio scale is considerably easier if you’ve adopted standard defenses. For example, you might adopt the OWASP ESAPI library for input validation, output encoding, and encryption. You could use log4j for logging. Or implement an authentication gateway that relies on LDAP.
Idea 3: Train in secure coding. Training works. One company I worked with had a 74 percent reduction in vulnerabilities on teams where at least half of the developers were trained. If you’d like to know what your development teams know and don’t know about application security, try the free tool, Secure Coder Analytics. It’s simple to sign up and invite a team of developers. Then, each developer takes a fully randomized and anonymized 20-question quiz drawn from hundreds of well vetted questions.
Please share your thoughts in the comments below. And remember: Nobody wants to see a naked app.