Dark Reading

The shift is on: Many leading firms are currently engaged in large-scale software security and application security initiatives. If your organization is not yet doing so, the best New Year’s resolution you can make for 2008 is to improve your software security.

One of the biggest challenges with software security is getting started. Every enterprise is different and there is no one-size-fits-all approach. At Cigital, we’ve helped advise and steer many software security initiatives over the last several years, and we've come up with four ways to get started. Depending on the way your enterprise is organized and run, one of these approaches should work for you: the top-down framework; portfolio risk; training first; and leading with a tool.

Software has become the lifeblood of industry, and software defects have likewise shifted from mere technical annoyances to real business problems with huge financial ramifications. Over the last several years, some organizations have begun to realize the magnitude of the software problem that they’ve designed and coded themselves into. They've come to this realization through a combination of penetration testing performed by “reformed” hackers, Web application security testing tools like IBM/Watchfire and HP/SPI-Dynamics, and code review.

The good news is that the badness-ometer approach illuminates how the software problem applies to your own software. So the common myth that software security bugs and flaws apply only to open source code or to code written by others and surely not to yours, is profoundly debunked when within seconds an automated tool hacks your Website.

The problem with the badness-ometer approach to security is that recognizing you have a problem does not actually solve the problem. The result: a piling-up of huge numbers of security bugs and flaws that have yet to be fixed. The dam is likely to break in 2008, so it's time to eradicate some software defects and to learn how to stop making more of them.

A top-down framework approach follows the plan laid out in Chapter 10 of my book Software Security. The idea is simple – perform a gap analysis between where you are and where you want to be from a software security perspective. Then build a plan to address the gaps. Make sure to include software security best practices for software you build, assurance activities for the software you buy, a portal for software security guidance, and an enterprise-wide training program for developers and architects. (See Want Turns to Need.)

The framework approach works well in an organization with strong centralized IT leadership that has both the power and the budget to undertake a large-scale initiative. We’ve seen this approach work nicely in global financial services firms, even when the development organization has tens of thousands of developers spread over multiple continents.

The portfolio risk method takes a more business-oriented approach to the software security problem. The idea here is to assess the entire application portfolio according to some risk criteria agreed on in advance. The results of this risk survey help determine which kinds of security controls and activities should be applied in what order to what applications. Organizations that are set up with strong but stove-piped business units often benefit from this approach. When executive management understands software risks clearly (and what to do to mitigate them), good things usually follow.

The training first approach to software security is more grounded in the technical world. This approach helps developers who love to do the right thing but just don’t know what the right thing is when it comes to security. Having trained over 6,000 developers on software security, here are some pointers from us at Cigital: Make sure that trainers are actually software people (not security people with no software experience); use examples from the enterprise code base if possible; and include lots of hands-on exercises with real tools and techniques. Training is an essential part of any software security initiative, and sometimes it makes sense as a first step.

The lead with a tool approach, meanwhile, makes sense for an organization that has already purchased and attempted to roll out a security analysis tool. In many cases, QA departments are furnished with Web application security badness-ometers. Sometimes development organizations are mandated to use static analysis tools like Fortify, Ounce, or Coverity. After the dust clears, the real work of tool adoption begins. In our experience, writing custom rules (linked to corporate guidelines) for code review tools can be a very effective way of upping static-analysis tool adoption. Likewise, security testing training geared for QA is important for engendering an attacker’s perspective among professional testers who are used to focusing their attention on features and functions.

In the end, your organization may require some combination of the four paths to software security.

— Gary McGraw is CTO of Cigital Inc. Special to Dark Reading