Software Magazine - Building Secure Software: Can We Get There From Here?

Building Secure Software:
Can We Get There From Here?
by Jim Reavis

We are starting to awaken from our dreamlike lust for nifty new software and are finding that the dark side of this software we built is pretty scary stuff.


In one of my favorite movies, “The Matrix,” our protagonist Neo is given the option of taking the blue pill and returning to slumber in the machine-simulated world of the Matrix or taking the red pill and waking up to see the horribly scarred world as it really is. As an information security professional, this scene resonates with me because I feel that only now are my good friends on the software development side of the house starting to take the red pill en masse. You see, in the roaring 1990s, when it came to software it was all about features, time tomarket and getting online ASAP. We are starting to awaken from our dreamlike lust for nifty new software and are finding that the dark side of this software we built is pretty scary stuff.

As far as I can tell, we live in a world with two types of software — the code with vulnerabilities we know about and the code with vulnerabilities we don’t know about. Time and popularity seem to be the two factors that draw the glitches out of all software, but the fact that it will be buggy is as certain as the rain in Seattle. From a Chief Security Officer’s perspective, this has been a vexing problem and one over which the CSO has had little control. The CSO typically has no choice but to deal with the software after it is baked, whether it is developed internally, bought off the shelf or customdeveloped offshore. A little security testing during pre-production integration perhaps, but basically we security professionals are mitigating risks within living, breathing production systems.

In San Francisco in February, I was lucky enough to be the master of ceremonies and moderator for the Secure Software Forum, an event organized by SPI Dynamics and sponsored by Microsoft. The forum was actually mentioned by Bill Gates at his RSA keynote speech, which might account for the overflow crowd. The premise of this forum was that maybe software vulnerabilities are not something we have to accept and in fact maybe there are some strategies to turn the tide. So what, you say? Aren’t I just recycling talk about Trustworthy Computing and Microsoft sending programmers to security school for a month? Is Microsoft any better for the effort?

The biggest problem we have in information security is a lack of credible metrics, but I do believe Microsoft has made some serious strides. Their development environment is much more robust than in previous years. A big problem they deal with is the consequences of architectural decisions made years ago, before Trustworthy Computing was a glimmer in anyone’s eye. But what we learned at the Secure Software Forum is that a singular focus on Microsoft and their security vulnerabilities is to ignore the millions of other vulnerabilities that are out there. To quote a CSO I know, “We have over 300 buggy applications that we need to document controls for SarbanesOxley. I would love to blame Microsoft, but we wrote every one of those applications in house.” And that was a key finding — this problem was created by all of us and it belongs to all of us.

For the forum, SPI Dynamics recast the acronym ASAP, coining the term Application Security Assurance Program. They are basically describing the need to integrate security throughout the software development life cycle and throughout the production lifespan of the application. This is the direction we need to stampede toward and change the face of software development. Most of my CSO friends are not there yet. As one of our panelists, Theresa Lanowitz of Gartner related to the audience, only about 5% of organizations have done a superior job of integrating security into the software development life cycle. That is appalling, especially when you consider the benefits those organizations could derive. Some studies have suggested that software bugs that are remediated during the production phase are 60 times more expensive than if caught and fixed during the design phase. The ratio isn’t quite as exciting during the coding or quality assurance testing phase, but in all cases is much cheaper than fixing released software.

The CSO needs to be involved in software development from the beginning — in fact before the beginning. When a new business initiative that requires new software is dreamed up, the CSO needs to do a risk assessment. He needs to see to it that security checks are built into all logical milestones of the software development process. In some cases the CSO needs to be an advocate for revamping the process or providing new tools and automation to help assure a better quality product.

Not Happening Yet

Yet, by and large, this isn’t happening yet. Why? CSOs, security teams and application development are different creatures that historically have few points of intersection. Developers like to get whacked on Red Bull and fly down a mountain at 100 miles an hour. The CSOs sit at home quietly behind deadbolt locked doors and have no friends. Seriously, the cultural difference is there, but the business imperative is also at odds. For developers who are rewarded for getting a product out the door, time to market is crucial, and process junkies who slow things down are the enemy.

CSOs are slowly getting the leverage they need to fight this battle. Regulations such as Sarbanes-Oxley, are giving their mission some board-level backing. Developers are getting hungrier for technical education related to security. But we also need to look at the tools we equip our developers with, and do a lot more automation to eliminate repeated mistakes. Jon Callas, CTO of PGP Corporation, who was reacting to comments at the forum that seemed to indicate that C++ was going to be with us forever, said, “Sure C++ is going to be with us, but it doesn’t need to be everywhere.” The CTO of SPI Dynamics, Caleb Sima, who has developed a class library technology called SecureObjects, noted: ??If we just did input validation in our software, we could solve 70% of our problems. When a field is supposed to be for phone numbers, obviously only a phone number should be entered.”

I don’t know if we will ever see the actual end of this movie, but I have hope that the good guys can gain some ground. If events like the Secure Software Forum become more commonplace, and more importantly, developers and security practitioners start practicing what they hear, we will see software that doesn’t scare us all.

Jim Reavis is president of Reavis Consulting Group and editor of the CSOInformer newsletter. He focuses on security issues of top concern to IT professionals. He is an advisor to the International Board of ISSA, the world’s largest organization of information security professionals. Learn more at: www.reavis.org.