Many security insiders believe that the only way organizations will be able to effectively meet the onslaught of attacks against Web and other home-spun applications is to implement secure coding practices from the ground up.

Changing Processes

The difficulty most organizations have when implementing security in their development processes is that security is not just a single step that can be added like a special feature. It must be embedded into the entire programming cycle.

“Security is an emergent property, which means that there is no phase on the assembly line where somebody bolts the security on,” says Brian Chess, chief scientist for Fortify Security, which makes code analysis tools. “You need to look at all the different paths and processes that are involved in making software in order to make it secure.”

Doing so can take a lot of additional time, a commodity most programmers don’t have in spades. Even those senior coders who might understand security development principles will set them aside if they’re rushed by bosses who put a higher priority on features and deadlines than on shoring up the code.

“The agile development philosophy says to release early and release often, which is counterintuitive to the build-security-upfront kind of philosophy,” says WhiteHat’s Grossman.

According to Microsoft’s Howard, the only way an organization can get its programmers to write securely along the way is to prioritize that process starting at the top of the enterprise and then drive down those principles over an extended period. He speaks from experience. Howard was instrumental in developing Microsoft’s internal Security Development Lifecycle and instituting it companywide. Much of the SDL focuses on three main principles: never trusting input, fuzz testing for validation that you’re not trusting input and threat modeling.

The years-long project of instituting these principles took a lot of developer hand-holding early on, he says, but that eventually changed as programmers put the practices into their daily routines.

“All of a sudden, people have grown up,” Howard remarks. “They recognize that security is part of the job—something you’ve got to do. There’s no longer the permanent requirement from our end to keep going back to the development group to make sure they’re doing the right thing.”

Microsoft believes so strongly in the power of SDL that Howard’s boss, Steve Lipner, senior director of security engineering strategy, and the rest of the SDL team recently announced that Microsoft would be making its internal threat-modeling tool available to the industry.

Business Advantages

Though sometimes difficult to quantify, the fruits of secure coding labors can make a meaningful impact on the bottom line. “I can’t give you hard numbers, but we have definitely noticed that testing is not as expensive as it was before,” Howard says, explaining that testing times have diminished because programmers are addressing problems earlier in the cycle and fixing them along the way.

And secure coding does more than cut down on testing time. It also makes for a higher quality product, according to Fortify Security’s Chess. “A lot of times, catching security bugs early makes everything else you do more predictable, and that predictability can be a big advantage,” he says. “It also means that when you announce a ship date, you’re more likely to meet it because you’re more in control.”

Most importantly, though, organizations are mitigating potentially millions in losses by heading off security breaches. Microsoft’s Howard says he helped one colleague at a different company justify an extra $200,000 in resources for secure coding by bringing in the risk management department and showing them the value of the information the investment was intended to protect.

The expenditures that executives initially balked at seemed like chump change once the risk managers explained that it would mitigate the risk against $30 million in assets. By the time the presentation was over, Howard recalls, “They said, ‘Where do we sign?’”