The Rugged Manifesto

I am rugged and, more importantly, my code is rugged.

I recognize that software has become a foundation of our modern world.

I recognize the awesome responsibility that comes with this foundational role.

I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended.

I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic, and national security.

I recognize these things - and I choose to be rugged.

I am rugged because I refuse to be a source of vulnerability or weakness.

I am rugged because I assure my code will support its mission.

I am rugged because my code can face these challenges and persist in spite of them.

I am rugged, not because it is easy, but because it is necessary and I am up for the challenge.

Documents

Rugged Software FAQ

What is Rugged?

“Rugged” describes software development organizations that have a culture of rapidly evolving their ability to create available, survivable, defensible, secure, and resilient software. Rugged organizations use competition, cooperation, and experimentation to learn and improve rather than making the same mistakes over and over. Rugged organizations also actively seek out threats and create defenses before they are a problem. Rugged can also be used to describe the software applications produced by rugged organizations. These applications are not only well-protected against attacks, but are also able to analyze themselves, report on their own security status, detect attacks in progress, and respond appropriately.

Rugged is NOT a technology, process model, SDLC, or organizational structure. It’s not even a noun. Rugged is NOT the same as secure. Secure is a possible state of affairs at a certain point in time. But rugged describes staying ahead of the threat over time. Rugged organizations create secure code as a byproduct of their culture. You are rugged because you run the gauntlet, instrument your organization and your code, constantly experiment to see if anything breaks, and survive the process of hardening yourself through real-world experience. Rugged organizations produce rugged code designed to withstand not just today’s threat, but future challenges as well.

What problem is Rugged trying to solve?

We are convinced that negative and reactive approaches to application security cannot scale and are doomed to fail. These approaches primarily rely on finding vulnerabilities and fixing them. We believe that fixing holes without establishing strong defenses against the threats that matter does not make sense. Yet most organizations today rely entirely on penetration testing or automated tools as their sole source of assurance. These organizations are not learning from their mistakes, they simply patch over the symptoms and continue introducing the same vulnerabilities over and over again.

The best projects today perform activities like threat modeling, security architecture, secure coding training, and security testing. However, it’s generally unclear how these activities connect back to the business goals that are important to the organizations. That is, there’s duplication, gaps, and no line of sight that explains the benefit of these activities in business terms. Frequently these activities simply report vulnerabilities or risks that do not become part of any sort of coherent security strategy. In fact, most of these efforts create no lasting value, and are simply repeated from scratch after some period of time. In many organizations, the complexity of the current approach to security is overwhelming, and they resort to building a compliance based program. While their intended goal is to improve security, these programs often result in a race for the bottom, where the organization is motivated to perform the minimal amount to achieve compliance, and certifiers are motivated to “check the box” for the lowest price. Neither trend is encouraging nor do they reduce real business level risk.

If you are tired of your organization making the same mistakes over and over, expecting tools to do more than is possible, only reaching a portion of your application portfolio, or expecting a process model to change your culture, perhaps Rugged is worth investigating.

How is this different from other security standards, compliance, risk management, or process models?

We believe that the key to producing secure code is to develop a certain type of software development culture - one that naturally encourages security by promoting communication, collaboration, and competition on security topics. We have to get beyond looking at the technology and examine the software development organization that created it. We believe change has to start with the people, process, technology, and culture of that organization. Existing standards, techniques, and process models have lots of useful ingredients, but there’s no overall recipe. Rugged organizations might use these techniques, but only to support well articulated and understood security goals.

How do I start?

The good news is that you don’t have to achieve an imaginary level or pass some arbitrary test. Perhaps the simplest way to start down the Rugged path is to take a shot at capturing your security story. It doesn’t have to be complete, accurate, or even legible. And you don’t have to start it at the beginning of a project. Having a concrete story will allow you to start adding, deleting, rethinking, and refactoring to make the story more accurate, simple, and compelling. You should show the story to as many people as possible and get many different perspectives. Start your story by brainstorming about the things that are most important to your business. What are the outcomes that you could not afford to have happen? Capture a list of all the threat agents that might attack your business. Think what harms they might be able to cause and start to prioritize them in terms of severity.

Is Rugged compatible with Waterfall, Agile, or DevOps?

The Rugged approach is totally compatible with existing software development approaches. With waterfall style projects, the story tends to evolve from top-to-bottom where the top-level security concerns are identified early, architecture and defenses are defined, implementation details are added, and finally evidence is generates. On Agile style projects, a single theme is fully articulated and then additional themes are added to the story over time. Because Rugged doesn’t specify processes or practices, you can build your story however you want.

How can I help?

Rugged and this Handbook are far from complete. In fact we’ve only just started. We are publishing this early version, a strawman, with the intent of provoking you, challenging you, and inciting you to think differently about security, assurance, development, and operations. We invite you to participate in the Rugged Project. The simplest way is to give it a try and let us know how it worked for you. We would love your help further developing Rugged or figuring out how to extend Rugged concepts. We challenge you to forget everything you know about application security and re-imagine how it could be reinvented to produce superior code.

History

Rugged Software was created by Joshua Corman, David Rice, and Jeff Williams in 2010. A project to create the Rugged Handbook in 2012 was a collaboration including Ramesh Balasubramanian, Justin Berman, John Bernero, Nick Coblentz, Josh Corman, Gene Kim, Jason Li, Randy Meyers, John Pavone, Ken van Wyk, John Wilander, Jeff Williams, and Chris Wysopal.

License

All materials available under the Creative Commons Attribution-Share Alike 3.0 License.