Making an Application Security Program Succeed, Part Two

“Failure is only the opportunity to begin again, only this time more wisely,” is a quote attributed to legendary automaker Henry Ford. While it seemingly has nothing to do with secure application development, all you need to do is talk to a handful of enterprises who have tried to implement a secure development lifecycle – and you’ll certainly see how it applies.

George Hulme“Failure is only the opportunity to begin again, only this time more wisely,” is a quote attributed to legendary automaker Henry Ford. While it seemingly has nothing to do with secure application development, all you need to do is talk to a handful of enterprises who have tried to implement a secure development lifecycle – and you’ll certainly see how it applies.

“We started a secure development program around 2006, and it didn’t go anywhere fast,” says the lead systems engineer at a major retailer. “We ended up [annoying] our architects, development teams, and the executives leading our web commerce. We came in with vulnerability reports and demanded that flaws be remedied. We didn’t have much more structure than that. The program was set back for nearly two years.”

That’s a story that has, unfortunately, become commonplace in recent years: The well-intended plans to stomp out as many application bugs as possible – as soon as possible – often go sideways.

“People need to realize that this is all still relatively new. Secure application development is not as mature as mass production manufacturing, where you do X and Y and you’ll always get Z,” says Gunnar Peterson, software security architect and CTO at IT consultancy Arctec Group. “That’s why it’s important to be realistic about what they can accomplish out of the gate. The application security initiative is probably the first time your security team has worked with your application developers and architects. They don’t know each other, and they may not like each other.”

So start modestly, with attainable targets.

“Don’t try to be a 10 out of 10 with everything. Don’t try to rid all vulnerabilities from all applications. Pick one area, get a success and make a statement. Then move on to the next area,” Peterson advises.

“That’s what we eventually did to get our application security program back on track. We scaled back our objectives and started small, and worked from there,” says the systems engineer. “It’s not where we need to be, but it’s growing in the right direction.”
Rafal Los, security evangelist at Hewlett-Packard Software agrees it’s important to start small, and adds that it’s important to measure those successes.

“We have to start to understand that if you don’t know what to measure, it’s just as bad as not measuring anything at all,” he says.
Some of the performance indicators Los says successful programs track and measure include the time it takes to remediate security related defects and how often defects are re-introduced into applications over their lifetime.

“Don’t try to measure everything at once, pick a couple indicators and build from there,” he adds.

It’s also crucial to keep costs under control. “Application security can very quickly turn into a never ending money vacuum. And what CIOs fear very much is that’s exactly what these efforts turn into,” Los says. “One of the best ways to keep costs down is to eliminate vulnerabilities as early in the development process as possible. Create the processes and give developers the means to be able to find these mistakes early.” 

Once application security becomes woven into the fabric of the development process, it becomes easier says Peterson.

“That’s when you can look back and feel good. Secure development isn’t something special anymore. If they want to secure an Oracle database – they know what to do. If they want to properly use certificates, it’s not a mystery. Application security then loses its mystery. It’s no longer some form of magic with gurus chanting in strange languages. It’s just good software development,” he says.

Suggested articles