“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. Rugged also represents a balance between two approaches to establishing, verifying, and monitoring security – a positive control-based approach, and a negative attack based approach.
To encourage this culture, one of the key ideas is to make security visible with a specific and understandable “security story” that captures everything necessary to understand why the code and the organization that built it are Rugged. The security story is both a guide and a reflection of security in the development organization and the software. Making it explicit allows you to create a culture where “builders” and “breakers” can compete and cooperate to make it better. Without a unifying story, all you have are thousands of security fragments that are impossible to understand.
The best approach to these industry game changers is to first understand how they came about and to implement these methodologies into the development process. The concept is simple, but its implementation is really hard, because of the lack of quality standards/metrics in our industry. This is a really important concept, and its complete lack of adoption (and traction) speaks volumes for our industry. For example, how am I supposed to make informed decisions as a software/website user if I cannot be exposed to something like this:
At CabForward℠, we don’t view Rugged as a burden or cost. In fact, this approach should yield time and money savings, while reducing risk. Because the alternative is unacceptable, we choose to be rugged. Not because it is easy, but because it is necessary, and we are up to the challenge.
Hear our podcast contributions to the Society of Rugged Developers at RuggedDev.org.