Mark Curphey On Builders and Breakers

Superb post by Mark on what I think is the biggest problem we have in security. One thing you learn in consulting is that no matter what anyone tells you when you start a project about what problem you are trying to solve, it is always a people problem. The single biggest problem in security is too many breakers not enough builders. Please understand I am not saying that breakers are not useful, we need them, and we need them to continue to get better so we can build more resilient systems. But the industry is about 90% breaking and 10% building and thats plain bad.

It’s still predominantly made up of an army of skilled hackers focused on better ways to break systems apart and find new ways to exploit vulnerabilities than “security architects” who are designing secure components, protocols and ultimately secure systems. If you don’t believe me go have a conversation with a  so called application security  consultant about SAML or security issues in Enterprise Message Buses and you’ll almost definitely draw blank stares. Ask application security consultants if they know about the latest HTTP or HTML spec and they’ll likely say yes (and want to demonstrate the latest issues) but if you ask them about the latest WS-x spec you’ll likely draw more blank stares.  When was the last time you saw an attack drawn out as a UML sequence diagram? This is worrying and somewhat sad. I don’t think we are culturing, encouraging and nurturing people with the right skills to make a positive difference. 

This is exactly my experience as well. Not only that, we have too much destruction and not enough construction, this is a big enough problem all by itself. I would go one step further and say we need creative destruction, breakers breaking things that lead to better systems over time. Maybe we need an OWASP Builders project?

In any case, for my small part I am builder. I teach a class (and will at OWASP) that is 100% focused on building secure Web services, identity management, distribut authN, authZ, message security and so on. I can tell you first hand there are not a lot of people approaching the problem from a builder mindset. 

Comments

[Jeff Williams]

Great post. OWASP does have lots of "builder projects" - the venerable OWASP Developer Guide, the Enterprise Security API, AntiSamy, Java security project, and lots more.

[Iang]

It is basically easy for outsiders to understand a breach, but almost impossible for them to understand a building. This is very seductive, and of course it is too easy to puff oneself up as being good at what you don't understand.

How we get over that is hard to say. Classically it was done with guilds, but they don't work so well in an Internet context because there is an open market in guilds, so the race becomes a race to the bottom -- course signups, certificates, etc.

More on the blog.

[None]

I'm not so persuaded, myself.

I find it strange that these posts seems to equate being a "Builder" with knowledge of SAML, Enterprise Message Buses, WS-x spec, UML diagrams, authZ, and so on. Security is not about features; it is about assurance; and likewise, I suspect the essence of being a good builder is not about knowing a checklist of standards and buzzwords, but about principles and methods for building secure systems.

[Gunnar]

Jeff - you're right, ESAPI in particular is a great example

Iang - yes grandstanding is one of the biggest problems.

None - Security is not about assurance. Assurance is about assurance. Security is about policy and mechanisms, assurance is about making sure they are consistent. We need better mechanisms.

[Andrew van der Stock]

@ None - It's been said before, it only takes a couple of days to demolish a house by one person with a bob cat. It takes months and many skilled folks to build a house that meets code, stands up to petty burglary, high winds and keeps out drafts.

Which is more useful to society? Building. It produces wealth and has a useful output.

What don't we have? Enough security architects and trained developers who know how to do this stuff right.

Researchers like myself are in the building mindset because we know enough about breaking stuff (face it, with web apps, breaking pretty much every app is too easy), but not enough about secure building. We can't do it alone.

It's not solely about SAML, but it is important to understand the security implications of a feature, the best way to implement it, and what the ramifications of failure are.

If I asked you to write a safe and robust login process that uses Active Directory, how would you go about preventing LDAP injection? Are there controls that can minimize the risk of dealing with the AD interface? Is there a parameterized LDAP interface? Can you bind to AD using an encrypted but low privilege account? Why is a low privilege account important when verifying a login?

Most breakers simply do not know the answer to these questions, and yet if you want to be a security architect, you must know this stuff.

It's far, far harder to be a builder than a breaker. At least an order of magnitude and the domain knowledge required is maybe two orders of magnitude more than breaking it, especially if you're a breaker who only knows tools.

Andrew

[None]

This kind of feuding about who is more important, Builders vs Breakers, is not helpful. Yes, many of our systems are so insecure they're all too easy to topple over. Yes, good Builders are in short supply. Yes, we need more knowledge of how to build good systems. But yes, Breakers can play a useful role, too.

We can recognize the important contributions that Builders make without belittling the contributions of Breakers. Let's do that.

P.S. And let's not make the mistake of thinking that knowing a lot of industry buzzwords of the day necessarily makes you a great Builder, any more than having an ISSCA certification necessarily makes you a great security expert. At most, buzzword compliance is a necessary but not sufficient condition; at worst, buzzword compliance can become part of the problem, because it channels people into building upon complex, poorly-engineered, but industry-standard stuff.

[Gunnar]

None - both builders and breakers are important. Builders are under-represented in the community today