Wednesday, March 30, 2011

What I've learned about Rugged in the past 24 hours

Well, I learned yesterday's post touched something in some people.  Based on the comments I got, both online and offline, I can guess a few of us are confused about what Rugged is about.   Especially those of us who've only read about it, instead of having it explained to us.   And sadly, some of us "saw it and dismissed it" as another security fad. Maybe this post can help fix that.

A lot of folks, including @joshcorman himself, stepped up to help me understand Rugged. Very nice, Lazyweb!


First, let's start with the problem (as I see it)


Software security programs have a poor Raison d'ĂȘtre. This is likely because it's hard to define what "secure software" is.  (heck, define "secure")  Is secure software?
  • Resistant to cross-scripting and SQL injection attack (insert attack du jour)
  • Bug-free?
  • 100% OWASP complaint (yes, I have been asked this)
  • Have no high vulnerabilities?
  • Made with high quality?

Waste of time, right?  We all know secure is a sliding scale based on value and risk.  You can't arbitrarily define security, which makes it less than useful for talking to executives and business program managers.  So how do we frame the conversation in a useful manner?  Enter Rugged.

Rugged leap-frogs over all these definitions and points to the qualia we security grognards are jumping up and down about.  It brings it down to earth with a clear and sharp image that conveys the essential intrinsic properties of "secure software"

To answer my own questions:

1) How is Rugged different than any other Best Practices?
Well, it's NOT really a best practice… more of a framing technique… or (ulp) a paradigm.  I was expecting too much of Rugged to even put it in this category, it's just not that kinda thing.  It's just a way to simplify the dynamic and intangible.  Of course, we could apply some evidence-based analysis over time to see how effective it is in helping the non-security folks understand us.

2) Convincing the developers to write more secure/stable software isn't my problem. My problem is convincing customers and managers so that they'll let/encourage the programmers to to write more secure code.
Ah, this would be Rugged's sweet spot.  Here is a meeting ground for the security team, developers and money spenders to agree on something that is useful and clear.   A way to communicate what needs to be asked for, what needs to be done and what the final product looks like.

3) Software security problems are deep and complex.
Actually, digging deep enough into Rugged, this issue is acknowledged.  And Rugged doesn't aim to solve these problems directly, but again, it gives us all something we can put hands around when wrestling with them.

4) Rugged appears mysterious and embryonic.
Hopefully we can change that.  The more we spread the word (and ask questions), the less confusion we'll see.  So I'll light a candle now:

Here's how I would summarize it as guidance from management to the developers.

"If our software is Rugged, it is built to withstand adversity, tolerate anomalies, and always do what we intend it to do. Our customers depend upon this level of unyielding reliability; in fact, they expect nothing less. It is our responsibility to meet these expectations."

How's that sound?

2 comments:

Anonymous said...

I've actually been internally (as in, my own head) dismissive but watchful of Rugged for a while. Maybe I was putting too much on it as well, similar to saying to someone, "My code is secure," and me thinking, "Yeah, secure enough, secure today, secure as far as you might know, secure as in tomorrow it might not be..."

It's nice to see that "Rugged" has kinda stopped and just is a sort of manifesto for code-writing, and not prescriptive at all.

Of course, that doesn't help anyone directly. It's like a developer who knows he should write better or more secure code, but doesn't know how or have the time or the push from his management...he's still on his own to figure it out.

And I think it's noble to push students into thinking about the rugged nature of their code, but I truly believe things like quality, performance, security, and "ruggedness" of code can *only* come about through experience, time, intelligence, and sympathetic expectations of code consumers. Beating someone over the head won't help, even if you're using a nerf bat and trying to put it in a nicer tone.

(The down side to making "Rugged" a generic manifesto is that it is not the least bit arguable. It's like saying, "We should be better people." Except in this one time, or that time, or in my definition... [insert other qualifying factors ad nauseum...])

-LonerVamp

Anonymous said...

As a follow-up, that's not to say I'm totally dismissive of Rugged. It's a great step to getting developers (and others) into a proper mindset; and a necessary one. I'm just not sure how useful it will be and it certainly is not actionable.

Billy, be nicer! ...Umm, ok...how?

-LonerVamp