Mar 23, 2012

Rugged Summit Summary

I spent the last week in Washington DC as an invited expert to the Rugged Summit, part of the Rugged Software initiative.

The very minute I announced I'd be participating I got several messages on Twitter saying Rugged is a failure and I shouldn't go. Those messages were sent from people I like and trust. Sure, I was reluctant to a manifesto written to developers by security experts. Also, I hadn't heard much since the Rugged announcement in 2010.

But shouldn't I try to bring my view---a developer's view---to the table? Of course I should!

At the summit I got to work with some amazing people. Ken van Wyk, Joshua Corman, Nick Coblentz, Jeff Williams, Chris Wysopal, John Pavone, Gene Kim, Jason Li, and Justin Berman. Four very intense days. And still no silver bullet :).

Rugged Software In Short
My take on rugged is defensible software free from well-known bug types. A rugged application should be able to withstand a real attack as long as the attack doesn't exploit unknown bugs in the platform or unknown bug categories in the app. If the rugged application is breached the developers and operations should be able to recover gracefully.

Rugged also applies to operations and there's an ongoing Rugged DevOps initiative.

Why Should Organizations Become Rugged?
We first focused on *why* organizations should produce or require rugged software. Does software security also enhance software quality? Should we try to measure return on investment, reduced cost, reduced risk or what? What would make a CIO/CTO decide to go rugged?

Fundamentally we believe rugged software is part of engineering excellence. And we all need to do better. Software is enhancing our lives and revolutionizes almost everything mankind does. We want software to be good enough to enable further revolution.

Software security is currently in a state of vulnerability management. That's a negative approach and it hasn't made frequent breaches go away. Rugged is a more positive approach where you're not supposed to find a bunch of vulnerabilities in pentesting.

Here's three examples of motives for rugged we worked on.

"Telling your security story" could be a competitive advantage. Look at and put it in the context of Dropbox's recent security failures. Imagine the whole chain of people involved in a system being built to chip in to produce evidence of why their product or service is secure.

Another idea is to define tests that prove that you're actually more secure after becoming rugged than before. We believe executives feel security is a black art and a pentest+patch doesn't show if the organization is 90 % done or 1 % done. HDMoore's Law could be such a test (works without Rugged too of course). How to actually test against Metasploit will have to be figured out.

Third, if buyers of software started demanding more secure software that would drive producers to adopt something like Rugged. So we worked on a Buyers' Bill of Rights and a Buyer's Guide. Buyer empowerment if you will.

The Rugged Software Table of Contents
The rest of the summit was spent on various aspects of how we think software and security can meet successfully. Our straw man results will be published further on and there will be plenty of chances to help making it the right thing.

But the table of contents may give you an impression of where we're headed:

  1. Why Rugged?
  2. This is Rugged
  3. The Rugged Tech Executive
  4. The Rugged Architect
  5. The Rugged Developer (I will write the first version of this section)
  6. The Rugged Tester
  7. The Rugged Analyst
  8. Becoming a Rugged Organization
  9. Proving Ruggedosity
  10. Telling the Rugged Story (internally and publicly)
  11. How Rugged Fits in with Existing Work
  12. Success Case Study


  1. John, from my perspective, as a development manager who cares about security, this is disappointing. Nothing that you've said here changes what was wrong and is wrong with Rugged. It's still a group of security consultants telling developers how and why we should do our jobs.

    You were behind the OWASP developer outreach program, another idea that like Rugged has unfortunately gone nowhere. But the outreach program was about open communication and collaboration and engagement and helping developers to solve their own problems. It was the right approach I think, and it had a real chance to make a difference.

    This latest step for the "Rugged Movement" doesn't look like anything has changed, and there's still nothing that people can actually use. Developers DON'T need to be told that it is important to write good software - except maybe for the people who design and develop the browsers and other plumbing for the Internet and keep creating naive security holes that the rest of us have to plug. We already know that we should develop better software. It's insulting to assume otherwise. A program based on insulting the intelligence of the development community will go nowhere and may actually be a step backwards.

    What developers need are better inexpensive (or free!) tools, frameworks and libraries that are secure by default, better constructs in the languages. Not preaching and memes and marketing bs like "ruggedosity". OMG this is poor branding...

    I can't tell from the table of contents here what Rugged is about (which isn't a surprise, since it's never been clear - maybe that's the point?). But based on the lack of progress in pushing Rugged forward in the last 2 years, maybe it doesn't matter.

    I'm frustrated that good ideas like the OWASP developer outreach go nowhere. Rohit and a couple of other people as you know are still trying to push forward a secure framework initiative that could actually have practical positive impact in someone's lifetime. And OWASP had good success working with some of the browser developers and should do more of this. These are initiatives that could make a real difference. This is the kind of work that you and the other talented and well-intentioned people involved in Rugged should be driving.

  2. First of all, John Wilander is a very deep developer that has only positive intention for the application security community. His efforts must be applauded. He is one of the few deep developers who is a regular security inspiration, and he plays a mean guitar. ☺

    But I must agree with Jim Bird. Jim has very unique visibility on the problem of application security as a very senior development manager with many applications under his management.

    First of all, the notion that vuln management is not important or we need to "get past vuln management" is tom foolery. If you are a large organization dealing with hundreds or thousands of applications, vulnerable software is just a reality and needs to be measured if you have any chance of dealing with the problem of scale. Also, vuln management is one of the three core pillars of information security and is fundamental to risk management. Most large organizations don't even do good vuln management, so I think we are still racing to get that “core pillar” right.

    But most importantly, if we cannot give developers frameworks, languages and infrastructure that already have security built in or at least has good security controls available, then we will never win. Look at tools like ESAPI. The idea was great, but it's largely a huge failure since the library is so bulky and takes so much effort to initially deploy and manage. This is just my opinion as someone from the "inside" of the project. We would have done better if we focused those efforts on struts, spring, RoR and other popular frameworks.

    Imagine a future where true deny-by-default horizontal access control functionality, auto-escaping templates, content security policy, good browser sandboxing, integrated CSRF protection and all the other AppSec control goodies (that are mostly available peace meal to developers) are integrated into the core of most web frameworks and languages. That is how we win. I already see these pieces being developed my people like Mike Samuel at Google, and I feel in a few years these kinds of technology will be available wide-spread.

    Jim Bird is right. More investment in building security into the code frameworks that dev's use every day is the way to really "win" AppSec at scale, and that work is already underway if you look hard enough.

  3. Jim x2, thanks for taking time to comment on this. You just made my list of desired previewers of the Rugged Developer chapter/tab :).

    First of all I'd like to point out that I am a developer. I switched jobs :). Here's my journey in brief.

    About five years ago I had spent so much time in software security I was afraid of writing a single line of code. That was not a good feeling. So I decided I had to once again become a developer and see if my insights in security made any sense from that perspective. Kind of go full circle.

    First I did consultancy work on a crypto wrapper in Java, then passed Sun Certified Java Programmer and joined a healthcare project where I wrote Java for 1.5 years. After that I then was a developer on the login and payment team for Sweden's most popular website for one year. I coded alongside top notch web developers. Security-wise I just kicked in whenever there was a security task or issue.

    At this point I was looking for a new job and I made a choice. I quit being a consultant and got hired as a fulltime developer at a major bank. They said my résumé would allow me to work for either the security department or the infrastructure development team. I chose the latter and right now I'm designing and developing the frontend of a new internetbank solution. I do 95 % code, design, architecture, build scripts, and test. Application security is the last 5 %. In essence, that's is my "infiltration-style" rugged developer.

    Back when I was a consultant I was also my company's evangelist in application security which meant a lot of public speaking. I've taken some of that with me. During the Developer Outreach discussions a year ago I decided to set a really tough goal.

    Several of us complain about the echo chamber of appsec. If you just give talks to your peers nothing really changes. So we collectively made a decision to try to go to developer conferences instead. October last year I gave an appsec talk at SenchaCon. Sencha sells popular frontend and mobile frameworks. I had implemented all my XSS and CSRF demos using their framework. Sencha's CTO sat front row and was super pleased, blogged about it, and promised to introduce controls in their frameworks.

    But I wanted to push myself further. To be *really* relevant and succeed in developer outreach I should be able to give talks on *pure* development, no security attached.

    A month ago I fulfilled that promise to myself. I gave a 3 h tutorial on JavaScript for Java developers at Sweden's most popular Java conference. About 100 developers attended. The day after, I gave a 45 min talk on application security for 700 of the attendees. By that I had proven to myself that my new home is now among developers, while maintaining a special interest in IT security. Man it feels good to be constructive again!

    That's when I was invited to the Rugged Summit. So should I be a grumpy guy and hope for Rugged to die or should I try to actually leverage my insights and mix them with the great minds of Ken van Wyk, Joshua Corman, Nick Coblentz, Jeff Williams, Chris Wysopal, John Pavone, Gene Kim, Jason Li, and Justin Berman? That's no brainer. I had to go.

    Here we are. We're all aware of how hard this problem is. We're aware of the large amount of prior work and that Rugged cannot revolutionize appsec in a single blow. We're aware of the "Developers vs Security People" problem – hey, I wrote that blog post remember? :)

    But we've go to try new things. And frankly I've never been part of a more ambitious and frank discussion on the core problems in appsec than last week in DC.

    I will write the Rugged Developer chapter/tab and I sincerely hope you (Jim x2, Mark, David, Eoin etc) will help preview it. In addition I will have non-appsec developers preview it too.

    Then, if it's still all crap I'll gladly dump it and join whatever initiative you guys suggest.

    The importance of security controls and defaults in web frameworks? Absolutely.

  4. I accept your challenge and will be more than happy to review your work on the Rugged Developer chapter/tab. I just worry that you will do all this slave labor for Rugged and other more "marketing" members of the team will take credit for your sweat.

    But that is why I like you John, you don't care about that stuff and you only want to do the right thing. How can I now support your efforts, even if I am not a fan of Rugged?

    Cheers John. I'm looking forward to seeing what you come up with.


  5. In mankind, there are those who fear uncharted waters and those who sail them. Rugged is uncharted and understandably it causes you angst. Yet, that should not cause us to give up and keep doing things the old way--the old way is busted.

    I work on a devops team, building cloud based SaaS products. On that team, we have adopted the Rugged message and are building security in and we will be talking about this as a team at DevOps Days ( in Austin Texas in case you are interested.

    I personally applaud the effort by the Rugged Summit and look forward to what happens from here. Remember Rugged now is as Agile once was.

    -James Wickett (@wickett)

  6. John, I would be happy to review your work and any of the other people's work on this and see if I can help make it matter. I am not questioning the intent or talent of anyone on this initiative - otherwise I would have just ignored the whole Rugged thing. I don't see yet how this is going to make as much of a difference as your outreach idea or what Mark Curphey is working on with the practical security book etc. Up to now Rugged hasn't been much more than a marketing shell for consultants which has been frustrating, but I'll reserve further judgement until I see more than a table of contents.

    My advice to everyone involved would be to please try to get more developers and managers and testers involved and make this relevant to them and their needs. Make it practical, tone down the "ruggedosity" bs and the manifestos, and don't hype it until you have something real.

  7. Hi John,

    I have to echo the comments of both Jim B and Jim M which is largely what I've found myself doing for the past two years of the Rugged marketing material. Let's be honest about Rugged here for a second, all it has been so far is a way for people to get speaking slots at conferences and appear as an application security expert with no relevant skills or knowledge to back up what they are saying.

    There is nothing I hate more than people polluting application security with more useless nonsense for their own gain. I wished you the best of luck with Rugged when you told me you were going to the summit and I do mean that. I actually think you are too good to be associated with something like this John.

    I will again echo something Jim M said:

    "I just worry that you will do all this slave labor for Rugged and other more "marketing" members of the team will take credit for your sweat."

    I know you will work hard at this but I hope your hard work doesn't turn into something the marketing members of your team use for their own benefit (conference talks etc). There are certain members of that team who couldn't design or code a "Rugged" enterprise application if their career depended on it so don't let them take advantage of your good intentions John.

    Finally to again agree with Jim B - drop the BS marketing type terms like Ruggedosity (really??) and create something useful. You never know you might even turn us into supporters if you do.