BSidesSF: Hug your developer, even when they can’t understand you

SAN FRANCISCO — You’ve heard the complaint a thousand times over: Security would be so much better if only the developers slowed down and wrote more ironclad code.

Microsoft and other IT vendors have put a lot of effort into making that happen with things like the Security Development Lifecycle.

There’s also BSIMM — the Building Security In Maturity Model — a set of best practices Cigital and Fortify developed by analyzing real-world data from nine leading software security initiatives and creating a framework based on common areas of success.

But in the bigger picture, it almost seems like a losing battle some days. After all, companies and customers want new, better, faster apps with increasingly sophisticated features.

In that atmosphere, a developer under pressure isn’t inclined to listen to the nagging security person in the room.

Meanwhile, the folks who break software for a living aren’t necessarily the people who can fix it.

So what are we to do?

Brett Hardin, senior software engineer at Symantec, took a crack at answering the question at BSidesSF this morning.

Hardin has been around the block. He’s worked as a pen tester, a product manager and, most recently, he’s taken on the role of “fixer” — trying to help bridge the gap between the developers and the breakers.

He presented the following scenario:

The builder (developer) mentality is to get it out there, make the features amazing and change the future. He made an example of Foursquare, which, he said, can care less about privacy because “the more you tell them, the more features they’ll give you.”

Then there’s 37Signals. Hardin said their mentality is to get the product out as fast as possible, let the community find flaws, and they’ll fix them within two days.

The breaker mentality, he said, is “Make it fail,love pwning, and say it’s all about secure development.”

Out of this is the reality that breakers don’t know how to fix stuff.

“They are like a wrecking ball,” he said.”A good wrecking ball man can’t build a building. Breakers oversimplify things by saying the hole they found is so easy to fix or that developers are stupid.”

But code is very complicated. Fixing it is even more complicated, he said.

In the end, perhaps it’s best to let the breakers break things, the builders build and focus on being the fixer, the one who bridges the gap, Hardin said.

One thing is clear, he said: Dissing the developer will fail every time.

The developer will always win the argument with a security person because the developer is doing what the top brass wants: Building new apps and building them fast.

Firing developers and making examples of them won’t work for the same reasons.

Not expecting them to understand security might be step one in moving things in the right direction, he suggests.

Good food for thought.

— Bill Brenner