Are You a Builder or a Breaker
I am reading Brain Rules; great book! In the opening chapter there is a wonderful quotation from an interview with Frank Lloyd-Wright that resonates with how I feel about the application security industry.
“When I walk into St. Patrick’s cathedral here in New York City, I am enveloped with a feeling of reverence”, said Mike Wallace.
“Sure it isn’t an inferiority complex?”.
“Just because the building is big and you are small, you mean?”
“Yes.”
“I think not.”
“I hope not.”
“You feel nothing when you go into St. Patrick’s?”
“Regret”, Wright said without a pause, “because it isn’t the thing that represents the spirit of independence and the sovereignty of the individual which I feel should be represented in our edifices devoted to culture.”
It’s certainly no secret among my friends that for past several years I have grown increasingly disillusioned with the information security industry and especially disillusioned with the application security industry (whatever that really is). Why? I will get onto the information security part where fluffy compliance and best practice culture seems to be gaining acceptance in future posts (probably after a few glasses of wine) but if we take the application security industry specifically then I personally find it is disappointing that after a decade of it being considered a discipline in it’s own right, it is still predominantly made up of breakers and not builders. 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. We need more computer scientists, engineers, designers, architects and builders and less breakers in my humble opinion.
Don’t get me wrong, I get and buy the fact that you can learn about how to protect systems by learning how to break them but this is not my point. If the application security industry is to be taken seriously by the mainstream development community (and by taken seriously I mean engage with them as a partner and not as a PITA) then it has to engage in complimentary activity; the design of secure systems. We have to stop enumerating badness and slinging mud and start adding positive value.
If we think about a typical development team we have;
- Product / Program Managers
- Architects
- Developers
- Testers
Today application security seems more closely aligned to testing than architecture or development and this needs to change. Designing secure software and systems is clearly not as trendy as showing clever parlor tricks to hack a system but there is room for both.
These days I much prefer to attend and speak at development conferences than security ones, even if it’s on security topics. I find that the people are positive and focused on the right things and I think are in general better equipped and motivated to make a real difference to the cause of insecure software. To illustrate this I just got back from TechEd New Zealand and Australia. If you look at the speaking tracks (including the security track) you will find talks on .NET 3.5 security features (CAS etc), Zermatt (our new claims based identity and token framework) and similar topics . Contrast this with popular security conferences and you will see that the security industry continues to enumerate badness.
Take for instance the upcoming OWASP conference in NYC. I love OWASP, brilliant stuff but it’s almost all attacks based. Even a talk entitled “Web Application Security Roadmap” looks like its about more testing and more enumeration of badness.
Loads of talks about injection attacks, not a single one on WS standards or SAML or ………
The great divide between the builders and breakers seems to be widening. I think we need more builders.
PS: Ironically this blog post was crafted sat outside a cafe at the Rocks in Sydney underneath the awe inspiring Sydney Harbour Bridge. Imagine what Australia might not be if the settlers took a look around and only focused on the things that were bad with the country!
September 10, 2008 at 4:53 pm
Hi Mark, this is a well-thought-out argument.
I think it goes back to something that I was taught to do by some of the good NCOs I’ve worked with over the years: Don’t point out problems if you don’t offer a solution.
As an industry, we haven’t been following this advice, simply because it’s sexier to point out where things break.
September 10, 2008 at 7:16 pm
Interesting point, and I’d agree. For me some of this stems from the fact that the application security industry is very close to and, to extent, has grown out of the penetration testing industry, which is inevitably focused on breaking rather than building.
September 11, 2008 at 6:38 am
I’m a Builder. Principles, patterns, and practices. Nail the root issues over chasing symptoms.
September 11, 2008 at 8:23 pm
Mark,
There is no doubt that you are right on this topic - I’ve firmly held the believe that security is (should be) part of the process of building software, and not just tacked onto the end as a final check of “have we done it right”. I would certainly like to class my self as a “builder”, but spend more of my time as a “breaker” than I would like.
In saying this though, an awful lot of security is, as you rightly point out, just focused on the “testing” part at the end. In some aspects this isn’t a bad thing - software can be designed, architected , and developed to be “secure”, but you need to have those final tests to say “is it so” rather than just having faith that the process did it’s job. We’ve been building software (collectively) for a long time now and still introduce bugs/defects - why would anyone think that security would be any different?
What you and I see a lot of is companies going for the biggest bang they can get for their buck. Often in security it is testing (although I don’t actually agree with that - it’s a common perception out there). Validating the end product is like random sampling at the end of a production line - you can find where the quality doesn’t match what you are after, but it doesn’t tell you why, and things can slip though if the sampling isn’t granular enough. From the info gathered at the end of the process, we should go back and make changes (process feedback), but more often than not this doesnt happen - the attitude of “we’ll fix the issues” is much more prevalent that “we’ll figure out why those issues arose”. Even if it’s a developer mistake/oversight, there’s still an underlieing *reason*, and I very seldom see that addressed in the industry at large.
So that’s why security is focused at the testing phase: because many companies arent willing to make the investment in it across the lifecycle. As you’ve said before, software is often an enabler in business, not the reason businesses exist (although MSFT, and other similar companies are clearly exceptions, but overall they are a minority). With this in mind, “good enough” is just fine, and testing tells them when it’s good enough
As for the security technologies, that’s certainly a fair point if you are designing/architecting/developing a system - you need to know the best, most secure, methods that are out there so you don’t have to re-invent the wheel. In *testing* however, having an “appreciation” of the technology is certainly required, but knowing the in’s-and-out’s of a given technology I don’t believe are totally necessary. For example, testing a web app, you want to test as close to the protocol as you can so you can possibly bypass anything added but higher-level protocols and/or the client. Same with a traditional app, you want to watch the network traffic, files touched, API calls made, to try and introduce/block behavior. Having an in-depth knowledge of SAML certainly might help me test a site/app that uses it (or cut down on the testing required), but I also want to be sure that the assertions are actually being both made and handled correctly.
If attacks get complicated enough to warrant a UML diagram, I’m sure they will be documented that way. Unfortunately, for most of the attacks/vulnerabilityies being seen today, seldom of them are very complex - as you say, there’s a lot of parlor tricks and clever filter evasion, etc - things that don’t lead themselves well to UML (or UML is complete over-kill). Attacks that are that complicated generally require a lot of “insider” knowledge, and I would guess that if security is important to these people then it’s better documented elsewhere (attack trees in the threat model perhaps?). A large number of the attack I see don’t even have good reproduction steps (sequence diagrams would help there), or are even ignored (which is why I do screen records of all my high-risk findings that warrant it). Even with the latest DNS issues, I didn’t see any kind of graphical, easy to digest, description until way after the details were released.
I believe (hope in fact) that security will just “go away”, be “transparent” to both end users and developers. Having well-testing and “known secure” building block for developers to use will certainly make things better. Even better if these things are just “there” for them, as defaults, so they don’t even think about having to use them. XXX. At the moment there’s far too much rebuilding/repurposing going on so everything that I see is very “custom”. It’s as if we aren’t learning from the other engineering disciplines who have patterns of what works and what doesnt in a given context.
Just my $0.02. I can go on for a *long* time on follow-up’s but I’ve already written far too much for a blog comment as it is
September 12, 2008 at 1:35 am
Totally agree. I would add that I think being a builder is considerably harder (and ultimately more fulfilling) than being a breaker.
But the OWASP conference is not BlackHat. All of the talks MUST talk about both problems AND solutions. And plenty of talks are focused entirely on building, including my talk on the Enterprise Security API project.
September 12, 2008 at 12:54 pm
Hi Mark,
Great blog post and I couldn’t agree more. I too have become overwhelmed with the cynicism and negativity surrounding this ‘profession’. Let’s not forget though that it’s still early days and that there’s a hell of a logn way to go in order to build our capability maturity.
September 12, 2008 at 1:58 pm
This is a very interesting article and you have given an excellent angle to the issue of Security.
However, I believe the whole concept of security is not given due importance during the years of learning one undergoes. If this awareness was developed(pun unintended!) during those days then software professionals would waste lesser time trying to learn a thing in order to understand how to code the secure way, the smart way.
Personally I know I learnt about security only when I began development as it was not given enough, nay any, importance in the days when I attended classes.
September 17, 2008 at 5:12 am
Mark,
I’m a bit conflicted over your post. There’s so much of it that I agree with, yet I’m so frustrated from my own experience. I can’t say whether I’m a builder or a breaker. I’ve spent my career as a systems administrator. While I can code a bit, I’m certainly not a developer by any stretch. I try to be part of the solution rather than just the guy that carps about how bad something is. In spite of that desire, I’m forced to to be the breaker, the bad guy, or the rain cloud.
I’ve had so many discussions where I’m speaking with project managers, developers, architects or development managers where I’m essentially told to “Prove it.” I’ve been told that all permissions should just be set to 777, to give Everyone full control, or that the whole thing is just philosophical anyway. When I mention Cross Site Scripting, SQL injection, or running with limited privileges to this audience I get the same blank looks you describe. Until an application is attacked and exploited, there’s no problem. Even then known, bleeding issues get ignored as long as the application works (mostly).
Do I think that application security folks can’t do better at being part of the solution? No, not at all. I know for a fact that I could be doing much better at it. But too often the other parties don’t even believe there’s a problem to solve and want to know why I’m even in the room.
September 17, 2008 at 3:19 pm
Great post! Like many of the other commenters I have to agree that I’m a little conflicted. I think there is a simple economic argument for becoming a breaker - it is easier and faster to learn. I think becoming a builder is harder for a number of reasons. For one, being a builder takes a lot longer - you have to learn to be a programmer/architect *and* a security professional. I think builders, by necessity, have to go through a breaking “phase” to learn how attacks work. Unless builders can learn to think like attackers they can’t anticipate attack vectors, so this phase is necessary. Sadly, it’s much easier to learn how to push buttons in MetaSploit and charge to do penetration testing than it is to learn how to architect and program systems securely. Add to this equation the fact that companies don’t pay builders commensurately with the investment it takes to become one. I’ve never seen a job offering for a security architect that meant the person on a software development team who focuses on building the application securely. Such a person would have to be a skilled enough coder to keep up with the programmers, a skilled enough architect to keep up with the systems architects, and also know security well enough to implement features to defeat attackers. How would you find people like this? How much would you have to pay them to encourage people to get into the field? I think unfortunately, most people with these skills are still in the “breaker” market, only they operate at a much higher level. These are the people who can do code analysis and build their own exploits. Sometimes they’re doing this in a way that makes applications more secure, but rarely are they ever rewarded for their efforts and there’s a great incentive to try and sell discoveries like these or hold onto them so as to have the best 0-day parlor tricks…
September 17, 2008 at 5:16 pm
Mark,
Finally, someone else who agrees with me.
I’ve had no luck getting into our security conferences by offering building talks. I find that repulsive. I’m no longer going to submit talks to our industry’s conferences, only developer conferences.
The next version of the guide will be only about building, not testing or reviewing. There will be links to these issues, but there it will be much shorter. Mainly because unless there’s a specific countermeasure to a particular weakness we must deal with, it will have basically zero discussion of attacks. My aim is that if you do the 16 or so things right in the OWASP Developer Guide 3.0, you’ll be safe against the 700+ CWE items automatically. This means for example, we will simply not talk about dynamic SQL queries except to say that they should not be used, and what sort of care needs to be taken if using parameterized queries, stored procedures and ORMs. Therefore, the chapter dealing with data sources will be about 1 page long.
thanks,
Andrew
September 19, 2008 at 7:48 pm
Concerning the OWASP event - there are (2) “camps” the training of how to do it properly and the talks about frameworks and projects like ESAPI, DHS Software Assurance Initiatives, NIST, Practical Advanced Threat Modeling and Security in Agile Development etc…
Training like;
T1. Defensive Programming
T2. Secure Coding for Java EE
T3. Web Services and XML Security
T4 — ok that is a breaking training…
T5. Leading the Development of Secure Applications
T6. Building Secure Rich Internet Applications
T8. Secure Coding for .NET
And yes, there is the other side that take more pride in poking holes and vulns…
Next Generation Cross Site Scripting Worms
Security of Software-as-a-Service (SaaS)
and more…. will not bore you simply visit: http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference
The part that you have NOT heard yet about this event is the following.
OWASP FOUNDATION WILL BE VIDEO TAPING ALL OF THE SESSIONS and releasing the content for FREE on October 1st to the world so that if you were unable to make the event for the peer-to-peer networking, parties etc.. you can still see the content at NO COST keeping it OPEN as OWASP is.
Build it and they will come - Break it and Media will come…
-Brennan
September 20, 2008 at 11:24 am
It’s fine to claim to be a builder, but it is rather hard to prove. Building is measured in years, breaking is shown in milliseconds. So we have a compelling advantage in the job market if we are a proven breaker; in contrast, there is no easy way to a great builder from a mediocre one.
What’s the solution? I don’t know. In the historical past, the guilds managed this conundrum, but guilds don’t work on the net, because there is an open market, and in an open competition between guilds, the incentive is to race to the bottom. So maybe the challenge is to build a guild that reaches up to higher architecture, not outwards to emptying your pocket.
More on my blog.
September 20, 2008 at 12:42 pm
[...] week Mark Curphey asked Are You a Builder or a Breaker. Even today at RAID 2008, the issue of learning or teaching offensive techniques [...]
September 20, 2008 at 5:50 pm
I find it strange that this post seems to equate being a “Builder” with knowledge of SAML, Enterprise Message Buses, WS-x spec, UML diagrams, 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 industry standards, but about principles and methods for building secure systems.
September 22, 2008 at 7:01 pm
[...] Mark Curphey On Builders and Breakers Gunnar writes about builders vs. breakers. He references Security Buddha’s excelent article on the same subject. Both are worth [...]
September 23, 2008 at 9:53 am
I agree with this blog post BUT is this really new?
Incompetent “Security Consultants” (or charlatans if you prefer) have been around for ages, a quick look around some (seedy, granted) sites will prove this.
What it used to be “generic BO” now it is “generic XSS”.
As an old manager of mine used to say “10% guns, 90% tin”. Same goes for “security consultants”
10% actually know what they are talking about and the rest 90% are just “button pushers”.
Application security, the way is practiced today, is nothing more than glorified testing (I wholeheartedly agree) and, judging from what I have seen in the field, minus the testing communitiy’s testing and experience, more like a random ad hoc pick-n-prick approach. However, unless customers get EDUCATED, this is the shoddy level of service they are getting.
For the love of Jobe, don’t get me started on the “best practices” and “standards” thing
Keep up the good work Mark
October 1, 2008 at 7:28 pm
Mark –
You and I have talked about “builders” and “breakers” before. Great post summarizing the issues.
I’ve always felt that the builders/breakers divide is a bit like the one between the first artist & art critic in “History of the World, Part 1.”
October 16, 2008 at 11:56 pm
that was a fantastic words from the Brain Rules.it has the deepest meaning if you analyze it well.
——–
ragavendra
Link Building
October 20, 2008 at 4:08 am
[...] Friday Day 2 was focused towards the "building" rather than the day one "breaking" theme – Mark Curphey would have been proud [...]
October 20, 2008 at 4:50 pm
I am equally annoyed by so-called appsec experts who sit on their high horses, thinking that I can dictate to my customers what they want and will pay their money to get.
Please forgive me, Mark the Great Microsoft Koolaid Drinker, for not speaking in forked tongues about SAML, EMBs, and WS*
Stephen
October 21, 2008 at 9:01 am
[...] is more exciting than designing and developing for most people. I understand and acknowledge that; but I have to conclude that it does skew the relative [...]