Wi-Fi has security problems. So does Microsoft's Outlook, and ditto for Cisco routers. While we're at it, Linux, smart phones, Mozilla, and a whole slew of others do too, but what's the common denominator?

Software.

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.

That's where Software Security comes in.

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.

  • Developers need to involve their IT Security team as early as possible in the design process. When you're trying to decide how to build something, it's not easy to ponder how that same thing can be mis-used or broken. You have to ''think like a security person''. Well, the members of your IT Security team have spent their careers studying how to break things, and they can help you understand what kinds of attacks your software is likely to face.
  • Similarly, let the IT Security folks help design some of the security tests. And no, I'm not (just) talking about a penetration test one week before deploying the application. I'm talking about all of the rigorous testing of the application that you do. (You do perform rigorous testing of your software, don't you?)
  • Consider deployment tactics that the Operations Team can leverage to increase the security of your software. For example, are there a couple of files, shared libraries (e.g., .DLL files in Windows), or other components that are absolutely critical to the security of your software? The Operations Team won't necessarily know what those are unless you tell them. Armed with the knowledge of where the software's Crown Jewels are, however, they can ensure file access control, event logging (including intrusion detection), and such are fine tuned to protect those items and alarm the right people when something goes awry.
  • IT security folks should learn about your organization's software development processes and procedures. You need to be able to speak intelligently with the Software Development team.
  • Spend some time studying Software Security and see what security touch points you can incorporate into your organization's SDLC to properly address security from the ground up.

    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.