etween project deadline pressure and user demand for the latest software features, security often isn’t the highest priority for development teams. Many times, eliminating vulnerabilities is seen as a task that someone or, in larger organizations, a team performs in the testing phase at the tail end of the software development lifecycle (SDLC), after the developers have completed the code. But when it comes to secure coding, this typical sort of SDLC is setting developers up for failure.

The emphasis on security in the SDLC at the recent RSA security conference, as well as secure SDLC initiatives at software giants such as Microsoft, indicate that the old way may be changing. Many in the software security space believe all the phases of the SDLC?from requirements through deployment?should participate in a common activity: security assurance. Security tools vendors in particular are promoting the idea as an industry best practice, because they know their products will produce best when the organizations purchasing them have security implemented throughout their development processes.

Jack Danahy, CTO and founder of OunceLabs, makers of source code analysis technology, says a lot of people blame the developer for insecure software, seeing them as the ones who create the problem. “Our philosophy is the problem was the way these developers were asked to build the software.”

The Early Bird Catches the Worm

Jeff Williams, CEO, Aspect Security

Every software consumer ostensibly has an expectation of security, yet it often isn’t part of the discussion during the requirements-gathering phase of the SDLC. The requirements should include the security expectation, because, after all, the developer programs only to those requirements. Jeff Williams, CEO of the application security services company Aspect Security, thinks software organizations today aren’t doing enough at this stage. “They think through the functional requirements, but they don’t think through the security requirements right upfront,” he explained. “That metric falls through, so it doesn’t get into the software architecture.”

During a RSA session titled “Baking Security into the Development Lifecycle”, Herbert Thompson, Ph.D., chief security strategist for Security Innovation, said “We’re used to thinking: ‘what are the functional needs of this software product?’ From the requirements phase, we need to ask the customer what they expect for security.”

Herbert Thompson, Ph.D., Chief Security Strategist, Security Innovation

Thompson pointed out that for customers in government-regulated industries “security’s becoming a non-negotiable expectation,” but he also acknowledged that those in other industries often don’t know what their security needs are. The requirements phase is a perfect time to guide the customer or user through the possible risks so they can make informed decisions about security tradeoffs.

Getting the customer’s buy-in at this early stage will avoid conflicts not only when the software is less secure than expected, but also when developers proactively provide more security at the expense of a desired feature. Fortify Software CTO Roger Thornton likens this scenario to hiring an architect to design your dream house. “And when the contractor built it, you went in and saw that the fireplace in the bedroom was missing. You ask why and he says it’s too dangerous. Well, [the contractor] didn’t ask.”

To give the user and the developer a clear assessment of the risk, threat modeling or developing abuse cases for the software in development is a widely recommended technique. “Any organization that goes through carefully building up these cases with both the users and the developers is fine from then on, because [as a developer] I’m not doing security to make some security guy happy, I’m doing security because I saw clearly a way that it could be compromised,” said Thornton.

Microsoft Senior Program Manager for Security Engineering Michael Howard, who co-presented the “Security into the Development Lifecycle” session with Thompson, said once software reaches design, “threat modeling is the only way to properly implement security at this phase.”

Roger Thornton, CTO, Fortify Software

He added that Microsoft has developed some 1,099 threat models internally. The models and abuse cases can take many forms as one tries to get into the mind of an attacker and identify all the ways he may attempt to break or exploit the software. However, according to Thornton, they all need to address three essential considerations:

• Who are the potential abusers who will compromise your system?
• Which techniques might they use?
• What would the impact be?

Let the Coding Begin?Securely

Once the software moves into development, programmers often aren’t equipped to ensure secure code without some help?even with security practices implemented in the previous requirements and design phases. According to findings by the Secure Software Forum, a joint initiative by the Information Systems Security Association and vendors including SPI Dynamics and Microsoft to advocate secure software practices, 65 percent of developers don’t feel confident in their ability to write secure applications and 70 percent of security problems are in the application layer. As a result, many security tools vendors find awareness training and code auditing products to be compelling solutions for customers.

“If you can give developers some basic training on things they need to understand, particularly if you can apply it in the context of whatever applications that they’re working on, you can get great return from that,” explained Dale Gardner, Product Management Director for Secure Software, a vendor that offers awareness training along with its CodeAssure application security suite.

However, even with training, developers can hope to be aware of only so much. According to Thornton, Fortify’s research has identified 116 categories of vulnerabilities, and each category can have many more calls. He said, “A SQL injection is a category, but there are thousands of different calls that will wind you up there. There’s just no way in the world a human being can do all that. Using tools to do all that can be very effective.”

These tools relieve the developer from manually auditing code based on his or her vulnerability knowledge, but the cure can be worse than the disease if they aren’t sophisticated enough to distinguish the serious threats from the trivial ones. Chasing down every possible vulnerability on a long result list, many of which turn out to be false positives, is not good use of a developer’s time. Tools vendors have worked to improve accuracy. For example, Secure Software simulates the execution of the code to essentially establish a model of the application, with which its tools can verify their analyses. OunceLabs tools return ranked results with the known vulnerabilities at the top.

Secure SDLC in Practice

Microsoft, whose products are perhaps the most scrutinized for vulnerabilities, adopted the secure development lifecycle (SDL) program internally as part of its Trustworthy Computing initiative. SDL is a process for developing software that defines security requirements and milestones (or gates) at every stage of the lifecycle and doesn’t allow a software project to progress beyond a gate until it meets those requirements. Among its mandates is a threat model for every new project. Redmond reports a reduction of at least 60 percent in the reported security bulletins from its pre-SDL releases to its post-SDL releases of Windows Server, SQL Server, and Exchange Server. Bill Gates devoted much of his RSA keynote address “Microsoft’s Security Vision and Strategy” to the principles of Trustworthy Computing and the SDL.

Dale Gardner, Product Management Director, Secure Software

According Howard and Steve Lipner, who co-created SDL, the program is an evolving process that updates twice a year, but keeps improvements lightweight. “To submit a change, you must show five security bulletins that would’ve been prevented by implementing the change,” says Howard.

The principles of SDL are evident in other vendors’ initiatives as well. With its Application Security Assurance Program (ASAP), SPI Dynamics actually has the stated goal of putting tailored SDLs into practice within all organizations. Secure Software developed CLASP (Comprehensive, Lightweight Application Security Process), which describes two dozen different activities that an organization can use to implement security into software development. “We’ve done it with an activity-oriented focus to make it easy to fit into different SDLC processes that people might have,” said Gardner.

Of course, having such a strong advocate of security practices in an executive as senior as Bill Gates is a luxury that security evangelists in many other companies don’t have. If you feel like your requests for improved security practices and the investment they require fall on deaf ears, gaining management buy-in and a sustained commitment is a tougher task.