Content area
Gary McGraw, CTO of Cigital, is the author of "Software Security" (Addison-Wesley, 2006), "Exploiting Software" (Addison-Wesley, 2004), "Building Secure Software" (Addison-Wesley, 2001), "Java Security" (Wiley, 1996) and four other books. McGraw was a keynote speaker at BZ Media's Software Security Summit, February 2006, in San Diego.
Full text
By Invitation
When I started working on software security 10 years ago, I couldn't convince even my mother of its importance, much less network security guys and developers. Things have come a long way since then. Today, everyone seems to agree that we need to do something to address the security problem at the software level, and a number of companies are even starting to do something about it.
It's still the early days for software security, though, and it's a very good time to assess the state of the problem, how far we've come to address it, and how far we have to go. In general, I am very optimistic about the state we're in, especially considering the progress that leading software producers are making.
WHY SOFTWARE SECURITY
By almost any measure, it's clear that the software security problem is growing. The Trinity of Trouble-connectedness, complexity and extensibility, the three major factors that make the problem a continuously evolving challenge-does its part to keep things interesting. CERT reports that the serious software vulnerability problem continues to grow, with an increase since 2000 of more than 500 percent. In 2005, there were 5,690 software security vulnerabilities that resulted in widespread security attacks.
What's critical to understand is that not all of these problems happen at the "application level" as some security vendors wish you to believe. Software security problems show up in router code, in operating system code, in cell phone code and even in code for public key cryptosystems. Sure, Web-based applications suffer from serious software security problems too, but declaring that the problem applies only to Web-based software running over HTTP is naive at best, and dangerous at worst.
If software plays an essential role in your business, you need to concern yourself with software security.
BEST PRACTICES
When I wrote "Building secure Software" with John Viega six years ago, we spent much of our energy describing the problem. This was important philosophical ground-breaking, and I am very happy with the result, but the time has come to stop wringing our hands about the problem and start doing something about it.
The good news is that there is something we can do about the problem today. In my new book "Software security," I describe in detail seven specific best practices that can be easily adopted by any software-producing organization no matter what software development process they currently use. I call these seven best practices the software security touchpoints.
By focusing security attention on a set of common software artifacts like source code, architecture and requirements documentation, I avoid religious warfare over which approach to building software is best and get down to the business of building better software. If you build software today, you're ready to adopt the touchpoints.
The seven touchpoints, presented in the order that they should be applied, are:
1. Code review with a static analysis tool
2. Architectural risk analysis
3. Penetration testing
4. security testing
5. Abuse case development
6. security requirements ;
7. Software security operations
Adopting all seven touchpoints may be too much to swallow for some organizations, especially all in one fell swoop. My recommendation is to start with the first two, code review and architectural risk analysis, and go from there. Whatever you do, though, don't fall into the trap of applying either of the first two touchpoints without the other. It is important to pay attention to both kinds of software defects that lead to security problems-bugs at the implementation level and flaws at the architectural level.
If you find yourself applying only the third touchpoint, by hiring "reformed hackers" to hack your software, you may do fine diagnosing the problem, but you're unlikely to know what to do about it. Better to review your code and take a close look at your software architecture, and then fix what you find.
One last thing about the touchpoints. Notice that the touchpoints are not security features or mechanisms like cryptography, authentication, access control and confidentiality. Instead, they are lightweight software analysis and construction activities that should be carried out during development. Software security is not security software.
SECURITY TOOLS
There are two lands of basic tools for software security that are widely available: security testing tools (which I refer to as badness-ometers) and source code analysis tools.
Security testing tools for software, such as the ones made by SPI Dynamics and Watchguard, have an important role to play in the evolution of software security. Though they test only Web-based application software, application security testing tools can help alert an organization to trouble in the software sector. That is, if canned black-box tests find problems in your applications, you know you're in very deep trouble indeed!
Of course, if the same tests find no security problems at all, all that you , know is that those particular tests didn't find any problems...you do not know that you're secure. That's why I refer to such tools as badness-ometers (as opposed to security-ometers)-they can return results only in the range from "deep trouble" to "who knows?"
All that said, I hope everybody stocks up on badness-ometer tools and uses them on a daily basis. Turns out it's good to know if you're deep in software security trouble. Such knowledge can help motivate an initiative to do better.
More important to making progress in solving the software security problem than those tools that only diagnose the problem are source code analysis tools such as the ones produced by Fortify Software, Ounce Labs and secure Software (to name just three). Static analysis tools that help developers and software security analysts find and remove common software security bugs from their code are essential. If you're not using a source code security scanner tool today, I believe you are negligent.
The first touchpoint is based on properly adopting these tools in all development groups. Of course you can't simply throw a bag of tools over the wall to the developers and expect the software security problem to disappear magically. But these tools have built-in knowledge and analysis power often lacking in most software development shops.
SOFTWARE SECURITY INITIATIVES
Simply put, we can't tool our way out of this problem. Instead, we must adapt the way we build software by integrating security deeply into the software development life cycle.
Probably the best-known large-scale software security initiative in a large enterprise is Microsoft's Trustworthy Computing Initiative. That's because Microsoft has put some serious muscle behind the program and is proud to trumpet the result. Michael Howard, Steve Lipner and the others at the heart of the initiative deserve high praise for their work. The interesting thing is that many other large enterprises are diligently working on corporatewide software security initiatives involving thousands of developers (though they're not touting them in public PR campaigns).
I've been fortunate to be directly involved in five such programs, in organizations ranging from large finance houses and investment banks to producers of consumer goods and hotel chains. Turns out that a number of large enterprises that you might not associate with software understand the kinds of business risks that software brings to bear, and they are working hard to manage them.
These large initiatives all have several things in common: a framework that is sponsored and supported at the executive level, a large-scale awareness and training program for developers, creation and maintenance of a portal resource that includes code for development, and the instantiation and adoption of best practices like the touchpoints inside development groups themselves.
SOFTWARE SECURITY NOW
Organizations go through several phases of maturity when they address software security. First-stage companies still need to get a handle on the software pile and its associated risks. Second-stage companies build an internal group that often ends up functioning as a fire department. Third-stage companies execute against a framework for enterprise best practice adoption. We have customers in every stage.
No matter what size your organization is, from a handful of developers to tens of thousands spread over four continents, the time has come to spearhead a software security initiative. Computer security depends on it.
WHAT DO YOU THINK?
SD Times welcomes feedback. Letters should Include the writer's name, company affiliation and contact Information. Letters become the property of BZ Media and may be edited for space and style. Send your thoughts to [email protected].
Gary McGraw, CTO of Cigital, is the author of "Software Security" (Addison-Wesley, 2006), "Exploiting Software" (Addison-Wesley, 2004), "Building Secure Software" (Addison-Wesley, 2001), "Java Security" (Wiley, 1996) and four other books. McGraw was a keynote speaker at BZ Media's Software Security Summit, February 2006, in San Diego.
Copyright BZ Media LLC Jun 1, 2006