Re: Doing the Hokey Bokey: Mary Ann Davidson Churping, Janet Burleson breast reinflation, DA Morgan fake balls

On Nov 26, 8:43 am, daoudam..._at_emailmiser.com wrote:
> http://blogs.oracle.com/maryanndavidson/2007/07/12#a99

Mary Ann Davidson : DO LOOP "Churp or Get Off my Twit" until Oracle files Chapter 11!

"I'm sure everyone has had the experience of some particularly inane and irritating song lyric getting stuck in an infinite DO loop in your brain. It starts out with someone mentioning a song or humming it (bad 1970s songs are particularly susceptible to the brain DO loop phenomenon), and before you know it, you keep hearing the song as background music for your life, for hours if not days. You don't even need an iPod with a long battery life to hear the same song over and over. (I don't know why it can't be a really great song like Wahine 'Ilikea that you hear; it's only the bad, the inane, the "I can't believe someone even wrote a song like that much less got it recorded" songs. Think "Billy, Don't Be A Hero," blech.)

I seem to have had a brain DO loop run-in with a particularly annoying song lyric, which some of you may remember if you had to take folk dancing in PE. It is the one, the only, Hokey Pokey:

"You put your right foot in, you put your right foot out, you put your right foot in and then you shake it all about, you do the Hokey Pokey and you turn yourself about, that's what it's all about."

You keep repeating various body parts that "you put in and out" before doing the Hokey Pokey and turning yourself about. It's a relatively straightforward lyric, but neither interesting nor demanding as a dance, I am afraid (there's a reason you haven't seen people on Dancing with the Stars compete over who does the best Hokey Pokey).

I suppose one of the reasons I am fixated on the Hokey Pokey is that I have had a number of conversations recently, and email exchanges, and white paper reviews, on the subject of automated vulnerability testing as the means by which we prove the security-worthiness of commercial software. It seems to come up at least once a day and the discussions repeat as often as those annoying DO loop songs. If there were a song lyric to this, it would be "you put your source code in, you put your source code out, you put your source code in, and the answers all come out, you automate your testing and turn products inside out, that's what it's all about." Automated vulnerability testing seems to be the new dance craze among some security people and, like the Hokey Pokey, it has a certain simplicity about it.

I have good reason for critiquing the Hokey Pokey other than the fact the lyric is driving me pupule (crazy) at present. In a previous life, I studied dance. In fact, I studied dance like a fiend. I decided when I was in my early twenties that I had always wanted to learn ballet, and so I did. I took classes six times a week, for hours on end, and I lived, ate and slept ballet, did pliés when brushing my teeth, rond de jambe when on the phone, would glissade, bas-de-bourrée and pas de chat down the hall in my apartment and by dint of hard work and fanaticism, I got en pointe. (Every little girl who ever dreamed of being a ballerina wants pink toe shoes, and I got them. Still have them.) Classical ballet is among the top three hardest things I have ever done, including getting a mechanical engineering degree and learning Homeric Greek.

What, you may ask, does this have to do with security? The answer is that, like security, ballet is a discipline, not just a dance. It requires a combination of flexibility, strength, and an amazing body awareness and control. All to make dance look effortless. Constant and lengthy training for flexibility, strength, and body awareness is background for the 2 hours you spend on stage, if you do a recital or dance professionally. I was never in better shape than when I danced and I never worked harder than I did to be able to dance en pointe. It was worth every jar of Mineral Ice, every bottle of Advil and every box of bandages it took to get there.

Not to be snobby, but when I watch people dance (e.g., flipping through Dancing with the Stars), it is painfully obvious to me who has been classically trained in dance and who has not. If you've taken ballet, there is a body awareness, a carriage, a line that you develop, that is not present in pick up dancers or people who just learned a bunch of steps. (To this day, I think the reason I am a good surfer is the balance and body awareness I learned in ballet.) Flexibility, strength, discipline, repetition is what enables your entire being to dance, not just "your right foot in, your right foot out." The Hokey Pokey is a dance, but not dance.

Similarly, the mania for automated vulnerability testing is disturbing to me because it is like substituting dance steps for dance. Like ballet, security is a discipline. Most organizations that pay attention to security incorporate a number of facets into their "security discipline." Coding standards, training (drills!), more training (stomping out SQL injections is at least as hard as fouette turns), design reviews, ethical hacks, secure development process, and endless repetition of all the above, for days, months and years. Even professional dancers still take dance class multiple times a week.

Automated vulnerability tools are called "tools" for a reason: they help you find vulnerabilities, but they are not "security" by themselves, and they are not a substitute for the discipline of security development practice. You can't test your way to security, but unfortunately, a lot of people who should know better are looking for a quick fix and think that automated testing is the answer.

If you are scratching your head saying, "But didn't you rhapsodize over automated tools in a previous blog entry?," you are right, I did. But there is a big difference between "this tool helps us do good things in security as one among many good things to do" and "this tool is a substitute for all the other things you need to do to create secure products."

Doctors always tell people that if you want to lose weight, you need to eat less and exercise more, and you need to make those lifestyle choices instead of something you do for 6 weeks just to fit into a bridesmaid's dress or a bathing suit. There are a lot of people who want to take a magic pill and continue to eat as much junk food as they want while sitting in front of the TV. Guess who keeps the weight off? People who are disciplined or people who want to take a pill and continue to gorge themselves?

Making this worse is the number of forces that want to actually substitute testing-based security for some more rigorous assurance programs we already have, such as the Common Criteria. The Common Criteria is not perfect (Oracle among other vendors has been active at working to improve the Common Criteria to include automated testing as one of many things you can do to improve assurance), but it has several things going for it. For one, it includes positive claims about security threats and remedies. Meaning, it looks at "What is the type of threat should this product address and how well does it address them?" Also, it is an ISO standard (which means multiple entities recognize it and vendors can do a single evaluation that counts in multiple jurisdictions). It is also flexible, by including a number of factors (on a sliding scale) to establish assurance, not just one.

If the absence or near absence of dumb coding errors that create security problems is important (and it is), so is having proactive security like, oh, authentication, access control and auditing. Secure configuration, too. "Automated vulnerability testing" does not generally address proactive security functionality at all and there are a bunch of defects these tools are never going to find (design defects, most particularly).

Nobody is more anxious than I am to stomp out the scourge of buffer overflows in our time, but if we merely dance the automated tools Hokey Pokey instead of spending hours at the security barre, we could have products with no buffer overflows that actually don't do anything interesting in security. Assurance is not merely the absence of certain classes of defects, it is some level of confidence that the product does what it purports to do in security. And what it needs to do in security.

There are other problems with "automated tool-based security testing" as the be-all and end-all. To begin with, the utility of many of these tools lies in using them in development and fixing what you find. Not only does swapping automated vulnerability testing for more comprehensive assurance programs substitute dance steps for dance discipline, absent some overarching standard (like an ISO standard), it opens the door to anybody asking for a completely random set of automated tests with completely random automated tools that may or may not be meaningful and that may or may not actually work. Somebody wants to see you dance the Hokey Pokey, another wants the cha-cha, and someone else thinks the rhumba is a great dance. You could spend years learning a bunch of dance steps, but never develop the discipline to be a dancer. The worse risk is that, ultimately, dancers will have no stamina -- they merely Shuffle Off to Buffalo -- just enough to make it through the auditions. The bottom line is that you can't test your way to security any more than you can Hokey Pokey your way to the New York City Ballet.

As for those who want to throw out Common Criteria for "automated vulnerability testing Hokey Pokey our way to security" (sounds a lot like Hocus Pocus), shame on them. If we could test security into a product, everyone would already be doing it. Tools are "tools," not solutions, and while they hold promise and should, over time, become part of best development practice (I am definitely a fan of the ones we use and have developed, ourselves), they are not a substitute for disciplined secure development practice nor do they say anything about positive, proactive security (e.g., features and functions).

I haven't taken ballet in years but I am currently on the hunt for a good halau hula (hula school). It's unfortunate that a lot of people's idea of hula is merely some girl in a grass skirt swishing her hips around, because hula is the heart and soul of the Hawaiian people, to quote King David Kalâkaua. Hawaiian stories, language, culture have all been transmitted through song (mele) and chant (oli). Hula is the interpretation of that. (A deaf person can nonetheless "hear" the song through watching hula.) As with ballet, many hula dancers spend years perfecting their art.

I learned Hawaiian because I love Hawaiian music and I want to know what my favorite artists are singing (without reading the liner notes). I want to learn hula to express the music. I don't think you can hula if you don't put the time in to learn the language and the music. It's not just steps, it's 'uhane (soul).

Security, as I have said often, is a culture, with a language, words, music, "dance steps," and yes, it starts in the soul. Automated testing is but a tool -- albeit a useful one -- for learning security and helping to practice your craft, just as much as, say, popping in a DVD of how to hula. There is no substitute for learning all there is behind the music so that you can faithfully dance the dance, and nothing will replace years of training with a haku hula (hula master). (I like the story about the person who heard a violinist at Carnegie Hall and remarked, "I'd give my life to be able to play like that." "I did," replied the violinist.)

Security and dance will forever be disciplines that require hard work and dedication to master, and in the doing and the practice lay the artistry and the accomplishment. There are tricks you can learn along the way, but no shortcuts to mastery of your art. Lastly, security, like dance, is also something that to be done well, needs to be done wholeheartedly. As the Hawaiians would say: "A'a i ka hula, waiho i ka hilahila i ka hale." (When you dance, leave your bashfulness at home.)

*Yes, the Buffalo is a dance step -- one you can learn in a tap dance class.

" Received on Mon Nov 26 2007 - 10:47:59 CST