Wednesday, August 15, 2012

Rugged Implementation Guide - Strawman

The people behind Rugged Software have quietly made available a Strawman release of a “Rugged Implementation Guide”.

This guide is supposed to offer practical guidance on how to build a secure and reliable application following application security best practices. It is based on the idea of a “security story” for a system – a framework that identifies the technology and organization security lifelines and strategies, the defenses that implement these strategies, and assurance that the defenses are implemented correctly.

The guide walks through an example security story for the different lifelines and strategies at an online bank. These examples include just about every good idea and good practice you can think of, even including a “Simian Army" (of course) and a bug bounty program (in a bank… really?). It’s overwhelming. If doing all of this is what it takes to build “rugged software”, then I don’t think very many (any?) organizations are going to succeed unfortunately.

The cynical part of me noticed that the framework and examples were heavy on verification, especially third party verification: third party architecture reviews, third party application and network pen testing and code reviews. And comprehensive developer training. And the use of ESAPI and of course lots of other tools. All of this is good, and all of this is especially good for appsec vendors and appsec consultants (e.g., the people who wrote the guide).

I tried to understand the Implementation Guide in context of the “Rugged Handbook” which was also quietly released at the same time. There are some interesting and useful ideas in the Handbook - if you get past the introduction (I wasn’t able to the first time I tried to read it), which unfortunately contains pages and pages of stuff like “Work Together like an Ant Colony” and “Defend Yourself Like a Honey Badger”… Towards the end of the document the authors explain how to get people together to write a security story and how different people in the organization (executives, project managers, analysts, developers) should think about and take responsibility for application security.

Although there’s nothing in the Rugged Handbook on the Rugged Implementation Guide or how it is to be used, I think I understand that development organizations need to go out and create a “security story” that explains what they need to protect, how they are going to protect it, and how they will prove that they have protected it, using these two documents as help.

The “security story” framework is a good way of organizing and thinking about security for a system - once you get past the silly marketing junk about badgers or whatever. It looks at security both in the design of a system and how it is designed and built and supported, targeted I guess more towards developers than security professionals.

So now what?

With these documents from Rugged, development managers have another, still incomplete description of how to do secure development to go along with OpenSAMM and BSIMM and Microsoft’s SDL. The over-worked part of me isn't happy that now there are more things developers have to think about and try in order to do their jobs properly.

I know that there is more work to be done on these documents and ideas. But so far I don’t understand yet how or why this is going to change the way that developers build software – maybe that was in the part about the honey badgers that I didn’t read...

3 comments:

jwilliams said...

Hi Jim,

Thanks for the comments. We're trying to make sure that Rugged isn't "incomplete" and "overwhelming." Maybe we didn't explain as well as we could.

You really don't need to do anything extra beyond what you're already doing. You can follow the guides to assemble your security story from what you already have. Hopefully it's strong. If not, you'll see the holes.

If you do this, you'll have a concrete model that you can iterate and improve. We believe this (and the other parts of Rugged) are the path to a culture of software security.

I'm sorry the nature analogies we used didn't work for you -- we're trying to examine and learn from how nature creates secure ecosystems. It's certainly not intended as marketing. I hope you'll give it another look.

I can assure you that there is no ulterior motive behind Rugged, just some folks that think we can and must do something different and better. Rugged absolutely isn't a process model designed to promote consultants and consulting.

We really would value more feedback on the ideas in Rugged so far. Thanks!

--Jeff




Jim Bird said...

@Jeff, thank you for responding so quickly. Am I correct that the audience for Rugged is developers and organizations who don't understand appsec or the case for appsec? If so, here are my thoughts:
1. The story of the bank is well-written, but way over the top. The audience you are trying to reach aren't going to "get" it, and they aren't going to be able to use it. It has everything AND the kitchen sink in it. Write a simpler story using the same framework, a story that is not about a bank, but a simpler online web app that people can understand and appreciate. A practical story that is risk-based, that starts off relatively small and then builds out. One that doesn't include ESAPI (as beautiful as it is), that doesn't include dynamic scanning AND static analysis AND Selenium tests of security features AND....(one of them, not all of them). No Simian Army, no bug bounty. Something achievable and affordable. For third party verification: pen testing or code reviews, or... not AND AND. Point out the holes and compromises that have to be made, and where to go next. But don't hit them with everything that anyone can imagine.
2. For the messaging, split up the Handbook into 2 documents: a "What is Rugged?" with the background case and the bugs and furry animals; and a "Rugged Story" document with the stuff on roles and how to build a Rugged story. Shorter, clearer and easier to use.
3. I wasn't questioning the motive of the writers, but the result. Good consultants can't help selling what they do for a living when they talk about what they know best. The selling messages come out strong in the example story, whether it was intended or not.
4. I thought originally that Rugged was going to be about writing software properly so that the system was both resilient and secure - hence "rugged". But the message is exclusively about appsec so far, standard OWASP stuff mostly, with a little Devops thrown in. How is this different from what is already out there?

jwilliams said...

Thanks Jim - those are excellent points. I think creating a leaner example story is an excellent idea. Maybe with a full blown story as the "future" state. The original idea wasn't to do an AND AND type story, but to show that we could get so much more assurance for our dollar if we actually had a line-of-sight to what we were trying to achieve in the first place.

> 4. exclusively about appsec so far

Check the scope section. We had to start somewhere. But the goal is to test these ideas and expand.

> 4. How is this different?

Rugged isn't compliance or a process model. It's not about forcing developers or shaming them. We're trying to focus on the cultural causes of software insecurity in the organization. The story and the other practices are our first (and to be tested) set of ideas for accelerating the path to a healthy security culture.


Site Meter