Co-authored with Sammy Migues
The more the world spends on computer security, the worse things seem to get. This has led Marcus Ranum (among others) to suggest that perhaps we should drop spending to zero and see what happens! Despite all this, we remain optimistic that computer security is making forward progress in spite of itself, mostly because a new paradigm of software security is actually catching on. We say, "in spite of itself" because the old network security paradigm -- comprising firewalls, fairy dust, and forensics -- is quickly approaching its technical limits. Let's investigate why.
A market growing in interesting ways
By almost any measure, computer security is growing. Look no further than the record number of RSA attendees this year (more than 25,000), the spectacular IPO of FireEye or the impressive compound annual growth numbers for the space touted by technology analyst firms. IDC, in Revenue by Segment and Revenue by Delivery Platform Breakdowns for 2010, reported an 8.9% compound annual growth rate (CAGR) for IT security products. At Cigital, we estimate the 2013 worldwide market for goods and services in IT security at somewhere between $30 billion and $45 billion. Not bad in a world economy still in slow recovery from the Great Recession of 2009.
Software security, a submarket of IT security, is growing more than twice as fast, with a CAGR of 20%. Most impressively, the 2013 software security market accounted for approximately 10% of all IT security revenue. What explains this growth?
The old paradigm reaches its limits
First, let's talk firewalls. Though new players and initial public offerings (IPOs) have reinvigorated the firewall market, the technology behind firewalls remains fundamentally the same as when it was invented. The idea is simple: Put a machine on your perimeter that protects your internal network from the outside by filtering packets. There are many ways to filter packets, but they all boil down to determining where a packet is coming from (source), where it is going (destination) and in some cases, what kind of stuff it has in it (inspection), then deciding whether to let it go by.
There is nothing particularly brilliant about this approach, which even the so-called new breed of firewalls follows. In fact, there are some serious drawbacks. First of all, a perimeter security defense like this assumes you have a perimeter to defend. These days, cloud services, massively distributed architectures, mobile devices and global enterprises all collude to dissolve the perimeter. Without an obvious perimeter, firewall placement becomes tricky! Secondly, the notion of "protecting the broken stuff from the bad people by putting a thing in between" begs the simple question: Why is the stuff broken? In fact, it was that very question that sparked the field of software security and my book, Building Secure Software.
Relying solely on a firewall for security ignores the fact that most attacks today target application software directly. Because these applications are hosted on the enterprise network, firewall rules are set intentionally to pass traffic to the application directly from outside. Trouble occurs when the apps have vulnerabilities that allow an attacker to target them through the firewall.
For example, consider an app that has a buffer overflow vulnerability in its authentication procedure. An attacker's exploit code passes through the firewall on its way to the app since the firewall can only assume the traffic is legitimate. Once the exploit arrives at the app, it does its dirty work. A firewall can do very little to block application-based attacks like these.
What about Web application firewalls (WAFs)? They don't work very well. You see, in order to make a WAF really useful, you need to give it lots of information about the application so that it knows what kinds of input and output to expect. Automatic training systems for WAFs do a scattershot job of this. Adding in that kind of knowledge by hand is possible, but the level of effort this requires would better be spent working on the application code itself. In final analysis, a WAF is far less effective than removing vulnerabilities from the application in the first place. That is, the real answer is to secure the app itself using software security techniques (code review, architecture analysis, app pen testing). See why software security is growing?
Now let's talk fairy dust. Simply put, software security is not security software. You can use a crypto library to add a security feature to an application, for instance, but that's not at all the same thing as making the application secure. Crypto alone is not the answer. There are two reasons for this. No. 1: Most attacks against applications do not target security features specifically (and crypto is just another security feature), but rather target defects in other parts of the application (bugs and flaws) in any part of the reachable code. Using lots of crypto does nothing to fix these defects or protect them from exploit (e.g., all SSL does is protect my exploit from prying eyes as it whizzes by; it might even allow my attack to sneak right by some firewalls). No. 2: Applied crypto is designed to protect data, not the application that processes data. Data in motion between machines can be protected. Data at rest on a disk can be protected. But data being manipulated in real time by a running application is a sitting duck.
Finally, let's talk forensics. Gartner points out that CIOs are beginning to express concern over our current collective approach to computer security. We refer to this approach as the cleanup on aisle seven approach to computer security, since there is a broad emphasis on network security and failed perimeter controls, followed immediately by forensics, system cleanup and handwringing. Forensics plays a key role in all of this precisely because the firewall-centric approach fails so often.
Though stories of advanced persistent threats perpetrated by nation states against newspapers and corporations are fun to read, they don't go far enough to get to the root cause. Instead of focusing on the impact of the hacks, we should dig for the reasons these systems were so vulnerable in the first place. Almost without fail, the root cause is bad software (including badly designed software that allows users to be easily phished or otherwise bamboozled).
Speaking of badly designed software, we kicked off this article with a the more we spend, the worse it gets aphorism. To expand on that, the marketplace is now spending billions on security products to separate the broken stuff from the bad people, to capture all the logs from all the things that separate the broken stuff from the bad people, to manage access to all the systems that process all the logs from all the things that separate the broken stuff from the bad people, and so on until you arrive at this Dr. Seuss-ian all-caps sentence: ALL OF THESE SECURITY THINGS YOU ARE BUYING ARE INCREASING YOUR FIRM'S ATTACK SURFACE! Every firm has inserted hundreds, if not thousands, of new software globs in its networks, has given these new globs access to highly sensitive data, and has crossed its metaphorical fingers and hoped for the best. If your own code isn't getting better and you've added hundreds of attack points to your networks, can the computer security situation ever really improve?
Have you gone to the cloud? Guess what a cloud actually is: It's millions of lines of code, all written in the last few years and not subjected to the test of time. Your software must be better than the cloud software, not depend on it.Have you gone mobile? Maybe you should look into our views on trusted on busted.
There is plenty of money to be made in cleanup-on-aisle-seven security. Ironically, the worse the software we rely on is, the more successful the perpetuation of this approach will be. If we begin to fix the broken stuff properly, we will need less security janitorial supply work. Hmm.
The new paradigm blooms
As we reach the limits of firewalls, fairy dust and forensics, it's no wonder software security is growing at twice the rate of the rest of the computer security industry! We certainly have our work cut out for us. Thanks to the Building Security In Maturity Model, or BSIMM, we can describe not only how to do software security at the enterprise level, but also how to measure our progress. Because we can measure and improve a software security initiative over time and watch as our developers get better at security and thus build stronger software, we can steadily bend down the security cost curve.
Dig Deeper on Secure software development