Mary Ann Davidson Blog

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.

For More Information:

Lyrics for the Hokey-Pokey (which was developed for the ski crowd in my own town, Sun Valley, Idaho, in the 1940s!): http://www.niehs.nih.gov/kids/lyrics/hokey.htm

Ballet terminology, if you are dying to know what a fouette turn is: http://www.messiah.edu/org/acclamation/BALLET/Terminol.htm

Nathan Aweau just won a Na Hoku Hanohano award for the following collection, all of which are Hawaiian mele that hula dancers particularly like (and which includes a great recording of Wahine 'Ilikea). If you aren't ami-ing around the living room to these, you have no 'uhane:

http://www.mele.com/music/artist/nathan+aweau/hawai%60i+classic+series+vol+2+-+hula/

The web site for the Merrie Monarch Festival (serious competitive hula):

http://www.merriemonarchfestival.org/

More on hula terms:

http://the.honoluluadvertiser.com/article/2005/Mar/31/il/il01p.html

http://www.huapala.org/Hula_Steps.html

A funny site on worst songs of the 1970s (so much dreck, so little time to listen to it, including the deservedly maligned Billy, Don't Be a Hero):

http://www.furious.com/perfect/badsongs.html

I am trying something a bit different with this blog entry, which is to tag team it with a colleague. The idea for this entry came out of an email exchange inside Oracle about identity and privacy. It was an interesting enough discussion that a third colleague thought it would be worthy of a blog entry. From my perspective, it's a chance to work with a great colleague and vent my spleen while doing so. What's better than that?

I should do a brief introduction here to my co-blogger, Roger Sullivan, who is VP of Business Development for Oracle Identity Management. I could provide Roger's more formal CV but suffice it to say that on a "street creds" level, Roger is a very well respected identity management kahuna (e.g., he is also President of the Liberty Alliance).  On a more personal level, a few years ago, Oracle acquired a company of which Roger was then-CEO. I remember punching the air with multiple "woo hoos" when I heard the news, because I knew Roger and thought that the fact we were "acquiring" him as part of the deal was at least as important as the technology (which itself was pretty cool).
 
The original email exchange Roger and I (and others) had was around federated identity. There is probably a fancier definition of federated identity with which Roger can enlighten us, but as a practical matter you can think of it as being able to have an "identity" that is recognized in multiple arenas that have some business relationship among them. For example, suppose I go to a web site for FooHotels. FooHotels has a business relationship with a car rental agency, RentHotCars (they offer joint car rental/hotel packages, and you get hotel points for renting cars and vice versa). From a consumer standpoint, I'd like to be able to go to a single web site, book a hotel and rent a car (and get all those points!) without having to separately identify myself to each entity. In particular, if I jump to RentHotCars.com from FooHotels.com, I'd like to be able to do that without typing in yet another cryptic username and password. I can do that through the magic of federated identity.
 
One of the beauties of federated identity is that the standards work in this area was driven by real businesses (not merely technologists in search of a problem to solve "elegantly"). As such, a lot of work to-date has been pragmatic, implementable, and focused on a clear problem that it would be useful to solve. And Roger has been a leader in developing those standards. Woo hoo!
 
<Roger> Mary Ann, you are too kind.  I think it is safe to say that all of the Identity Management acquisitions, including the recent announcement of Bharosa joining the family have, been great moves for Oracle and our customers.  The synergies created by the union of these "best of breed" companies have been truly remarkable and have catapulted Oracle into a leadership position in the Identity Management market.
 
Mary Ann has provided a great description of the essentials of Federation.  What else would I say to a former U.S. Navy officer with a loaded weapon?  (Read on...)
 
Federated Identity Management provides benefits to each of the participants.  For the Service Provider, federation extends their reach into their markets.  For the Identity Provider, it provides a singularly secure mechanism of storing the essential identity elements.  And for the individual user, it provides a safe and secure means of disclosing only the required information necessary for the task at hand.
 
<Mary Ann> To me, the business need (and utility as a user) of a being able have a federated identity is a different issue than having (or needing to have) a single identity recognized by lots of disparate entities who don't have a business relationship. This lack of business need (dare I say Need to Know?) coupled with many people's natural desire for privacy to me means that we don't actually need a single identity and in fact, I'd really resist it. I do resist it.
 
For example, I have multiple "identity cards" in my wallet (I have lots of them in fact, judging by the thickness of my wallet). These identities are issued by different organizations, each of which has a different authority to issue them (and don't in general need to know of my other personas). For example, I have a concealed weapons permit in the state of Idaho (which required me, among other things, to take a gun safety class and pass an FBI check). I also have an American Express card. American Express neither knows nor cares that I am licensed to carry concealed in Idaho and the state of Idaho presumably neither knows nor cares what my credit rating is, as long as I pay my taxes on time. This is one reason why I have two cards: it reflects the fact that these identities have no relationship with each other, and each has "authority" to recognize "Mary Ann's identity" that are unrelated. They don't even need to know I am the same person.
 
<Roger> Mary Ann has hit upon the fundamental issue that concerns many who are using web-based services.
 
Consider the following example of how we interact in our daily (non-electronic) lives.  Let's say that I'm driving home from work and receive a call from my wife asking me to stop at the store for some milk.  I don't have much cash, so I swing by my bank's ATM machine.  This simple example involves at least four distinct identity elements.  [Pause now while the "Jeopardy" music plays and you try to identify at least four forms of identity.]
 
The cell call will probably have my wife's name on the screen as I answer because her number is passed through the cell network and I have that number associated with her name in my contact list.  There is reasonably strong assurance that it will be her on the other end, unless she has loaned the phone to someone else.
 
At the ATM machine, I'll need to insert my ATM card (something I have) and enter a PIN code (something I know) in order to provide multi-factor authentication that it's really me trying to access my bank account.  This is good for the bank and especially good for the security of my funds.  I like providing these extra steps.
 
At the convenience store, the only "authentication" required is that of the $5.00 bill that I present for the milk.  For some transactions, there is an implicit right to anonymity.  Neither the store clerk nor I have any need to know the other's identity for this transaction.  If, on the other hand, I looked considerably younger than I do and was buying beer, the clerk would have an obligation for me to provide proof of legal age on some sort of recognized identity card.  I know that this is expected in the various day-to-day transactions in which I participate.
 
What we want to achieve in the electronic world, is the same kind of humanly intuitive interaction with web-based services.  The minimal set of appropriate credentials - and only those - provided for the transaction at hand.
 
[PS: The 4th form was my driver's license with beaucoup identity information on it.  If I want the privilege of driving, then I will agree to carry and provide this authentication mechanism to the local constable on reasonable demand.]
 
<Mary Ann> Unfortunately, more and more of our representative identities are linked through the magic (or curse) of Social Security Numbers (SSNs). As such, we have the "collapsing" of identity, sort of the metaphysical equivalent of having one persona instead of many, which has made it a lot easier for identity thieves to flourish. It used to be the case that losing a single credit card did not lead to an identity theft nightmare. You just called the company and cancelled the card (I only did this once, when I "lost" a credit card that later turned up).  Now, if you lose (or misplace) one "identity" that is based on your SSN, or someone else gets access to it, they can often "link" to all your other personas. You didn't lose one card, you lost your entire identity.
 
The entire identity theft explosion has been fueled by too darn many people using Social Security Number for purposes for which it was never intended: as a single unique identifier (that enables linkages between non-related personas, many times for no purpose that could possibly be construed as beneficial to a user).  Putting it differently, if my magazine subscription record is leaked, so people know that I take Surfer's Journal, I really would not care. (So what? It's a great publication and no harm to me if people know I read it.)  However, if my "subscription record" were to include my Social Security Number (for no good reason, and there is no good reason to use it), I am in deep kimchee because that SSN allows a bad guy access to many other Mary Ann personas. Bad guy can "become" me.
 
If a Social Security Number is ubiquitous (and it is) but not secret (it has been used as people's health care number and driver's license number, conveniently located on your health care card or driver's license in 12 point font, bold) and the key to "who you are," it is the perfect storm of one "key" (which is not secret and cannot be changed) unlocking your entire identity, so that it can be stolen. The only worse thing would be substituting your fingerprint as your "unique identifier," which is also not secret and can't be changed.
 
I confess to being a professional crank on this issue. Some years ago, I registered for a class at UC Berkeley Extension (which had and presumably still has excellent classes). They wanted my Social Security Number in order for me to register. Here's how the dialogue went:
 
UCB: "We'd like your Social Security Number."
Me: "Why, is this a taxable event? Because if it isn't, you shouldn't be using SSN."
UCB: "We want to uniquely identify you."
Me: "That's your problem. I know perfectly well who I am. Besides, if you want a unique identifier, use a database sequence number. Trust me; I know about these things."
 
I won the argument through sheer stubbornness. (In the interests of full disclosure, I am told that UC Berkeley no longer uses SSN as student identifiers, so good on them. Perhaps in my own small, cranky way, I helped them see the light.)
 
I should note that Oracle has technology (transparent data encryption, woo hoo!) that can encrypt columns (or entire tablespaces, as of Oracle Database 11g) of sensitive information like Social Security Numbers. It's a nice weapon in the security person's arsenal. A great one, in fact. But the entire world is not Oracle, and encryption, as wonderful as it is, doesn't help you if the data is "inappropriately accessed" in decrypted form.  Eventually, data - any data - has to be decrypted to use it.
 
<Roger> As Mary Ann points out, Oracle provides sophisticated security mechanisms in order to protect the information that our solutions manage.  In addition, we strongly believe that these solutions must be based on industry proven standards.  This provides our customers with the investment protection and flexibility that web-based applications require in a connected world.  There is a very long list of boring acronyms that detail the identity-related standards that our products support.  Moreover, there are equally long lists of standards for virtually every product area in the company.  A fundamental criterion for the successful integration of acquired companies is their adherence to relevant standards.  This enables Oracle to quickly achieve a return on its acquisition investment.

<Mary Ann> Clearly, there are times when an organization needs to collect sensitive information (like your employer, who needs your SSN to for tax reporting purposes). Many organizations take appropriate care to secure that information. Those aren't the folks that make my blood boil.
 
You do have to ask, and I have, why is really sensitive data being collected by so many people who do not need it and who don't secure it? Especially when it is users and not "collectors" who pay the costs of recovery from identity theft? It's like someone demanding to borrow my car (something of value to me), getting drunk (not acting responsibly with my property), wrecking my car, and leaving me to pay the repair bill. It's a rotten deal. Any reasonable person would say, "You shouldn't borrow my car; get your own. If you are going to borrow it and you wreck it in a drunken stupor, you pay for it. The entire megillah."
 
<Roger> Identity standards have been well established for the means of collecting and "connecting the bits" so that the necessary identity information can be protected and securely shared for legitimate purposes.  The danger is that, once the bits are connected for illicit purposes, they can spread at light speed through web infrastructure.  The identity industry is beginning to establish policy standards that go beyond simple interoperability of the technology.  Rules can be created so that there are secure electronic safeguards in place to ensure that only legitimate connections can be made, thereby significantly reducing the opportunity for identity theft.  Additionally, one can assure that the mechanisms for managing the data and performing risk analysis can be thoroughly audited.  Establishing, implementing, deploying, and auditing these standards-based solutions will add enormous confidence to those who are using web-based services.  And that will yield comparable market growth.  
 
<Mary Ann> I like what I am hearing from you, Roger! Federated identity is a wonderful thing when there is a business purpose for linking my identities, as there so often is. As someone who is forever being asked to create another username and password for yet another website, I wish we had more of this where it makes sense. However, federated identity is most assuredly not "having a single persona that relies on an immutable non-secret for security." Only God and my mom - well, maybe only God - knows or should know all the different facets of my persona, or anybody's persona. I for one would like to keep it that way.
 
<Roger> So, Mary Ann does your spleen feel sufficiently vented?
 
<Mary Ann> On this topic, yes! Thanks for adding color, detail and expertise to the discussion, and for being part of the solution, not the problem.

For more information:

Liberty Alliance:

http://www.projectliberty.org/

Surfer's Journal, a great publication:

http://www.surfersjournal.com/surfer/SFNT.html

Roger Sullivan's blog:

http://blogs.oracle.com/rogersullivan/

Oracle's acquisition of Bharosa:

http://www.oracle.com/corporate/press/2007_jul/bharosa.html?rssid=rss_ocom_pr