Software has security problems. And all of the security patching and firewalling that we're so fond of hasn't a prayer of keeping up at the current rate.
We're producing software at an enormous rate these days, and we're making our computing and network systems increasingly complex. At the same time, our ability to patch hasn't improved one bit, at least not in a substantive sense. We have simply got to make some fundamental improvements in the way we develop software.
Software Security is an (arguably) young discipline that addresses the security attributes of software as it is being designed, tested, implemented, and deployed -- that is, throughout the Software Development Life Cycle (SDLC). It involves incorporating numerous security activities at various stages in the SDLC, such as threat modeling, risk management, and security testing.
A major factor contributing to our current predicament is the fact that software sevelopers and IT Security folks tend to focus on their own priorities, quite independently of one another. Software development typically focuses its efforts on issues like software functionality, performance, cost, etc. Oh, these are important topics, to be sure.
On the other hand, IT security teams typically address the security of an application after it has been written. They look for ways to segment the application with technology tools like firewalls, VLANs, and such -- an approach that the Software Security community generally calls Application Security.
The problem with the application security approach is that it tends to be predominantly reactive, without sufficiently addressing the root causes (no pun intended) of the problems. It's basically the status quo, and it is largely responsible for the security problems that we're facing in our data centers today.
If you look at an SDLC process over time, you'll notice that the software developers, by and large, live on the left side of the chart, and the IT Security folks live on the right, with very little overlap. I've been fortunate to have spent time on both sides of this chart and I'm here to tell you that there's a lot we can do to improve the state of things if we pool our resources a bit.
I've listed a few concrete suggestions of things that we can do to improve the security of our software, from the earliest stages possible.
Clearly, much of what I'm saying pertains primarily to organizations that develop business applications. But even in places where only third-party software is being deployed, there are valuable lessons to be learned, especially in the area of improving the security of the deployed operational environment. But that's another topic for another column.
Software Security, as I said, is still pretty much in its infancy. We're certainly not going to achieve magical results over night. However, it's been my experience in my dealings with software development organizations, that the two areas where we can benefit the most are in threat modeling and rigorous security testing.
These are likely to be viewed as the low-hanging fruit that will give us the greatest improvement for our investments.
Kenneth van Wyk, a 19-year veteran of IT security, is the prinicpal consultant for KRvW Associates, LLC. The co-author of two security-related books, he has worked at CERT, as well as at the U.S. Department of Defense.