Rugged Software FAQ

  1. What is Rugged?
  2. “Rugged” describes software development organizations which 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.

  3. What problem is Rugged trying to solve?
  4. 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 use 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.

  5. How is this different from other security standards, compliance, risk management, or process models (like OpenSAMM or BSIMM)?
  6. 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.

  7. How do I start?
  8. 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.

  9. Is Rugged compatible with Waterfall, Agile, or DevOps?
  10. 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.

  11. How can I help?
  12. Rugged and this Handbook are far from complete. In fact 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. You can start by visiting the website at We challenge you to forget everything you know about application security and re-imagine how it could be reinvented to produce superior code.