Gary McGraw's latest Reality Check podcast features Bob Briggs and James McGovern from The Hartford, its well worth your time to listen in. One of the things I appreciate about Gary's work in Reality Check and this podcast in particular is its focus on real world deployment issues. Napoleon famously said the fifth element is mud; and we all know that amateurs talk about tactics, armchair generals talk about strategy, but professionals talk about logistics.
Its quite simple for vendors and consultants to point out security problems, but its quite challenging to solve some of these problems in a real world company with constraints, humans, politics, budgets, timelines and so on. In short find it more interesting to learn about the logistical challenges, because I think those are the problems we have to work.
A couple of notes from the podcast, we all know its difficult to sell security in a company and believe me until recently selling software security is a hard thing to do. James mentioned the business bought into software security as a preemptive strike so they were not trying to all solve it in our own silo. They also had success in making people realize that attackers dont break into powerpoint, they break into apps. An important yet frequently missed issue.
Bob Briggs made another very useful point around getting developers to take ownership over the issues. This is a horse I ride as often as possible, namely to appeal to the developer's own sense of themselves as an engineer. Its one thing to berate developers, call them "clueless" about security, and to do bug parades generated from pen tests and so on. These have limited utility in my experience. Its usually better to drive for engineering goals around safety.
No engineer wants their bridge to fall down, if you show developers real failure modes and show how to avoid them this is one approach I have seen work well in practice. Its a myth that security is hard, its certainly no harder than programming web or databases. The difference is that we 30 years into optimizing databases and 20 years into optimizing web programming, the difference is engineering. This is the goal we have to appeal to, lay out the challenges in real world engineering terms to developers, let them take ownership and they will often surprise you with creative, cost effective solutions.
You're missing a big point here : you need to enable developers. Train them, give them secure coding tools like ESAPI, have assessment resources work with them, and give them time to fight the "legacy issue". The entire business needs to take ownership, not just your developers.
Posted by: Manicode | October 10, 2009 at 12:39 AM
@Manicode: those are all excellent examples, I should have mentioned them.
Posted by: Gunnar | October 10, 2009 at 08:57 AM