On 26 Nov, 16:47, daoudam..._at_emailmiser.com wrote:
> 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 ...
>
> read more >>
I hope her knowledge of Oracle exceeds her knowledge of the Hokey
Cokey. :)
Received on Tue Nov 27 2007 - 07:45:54 CST
