Mary Ann Davidson

Subscribe to Mary Ann Davidson feed
Oracle Blogs
Updated: 16 hours 47 min ago

Perspective

Thu, 2007-09-27 17:42

A few errata correction on my last blog entry before I go any further: 1) my mother insists that I was closer to 3, not 4 years of age when I threw a fit and demanded (and got) my own library card* and 2) the name of the devastating fire in Ketchum, Idaho last month was the Castle Rock Fire, not Castle Creek Fire. I can only plead brain fuzziness based on the amount of smoke I inhaled over the two weeks it was burning. 

 

Now that the fire is over, I have a newfound appreciation for the beautiful, clean, cool and pristine air in Idaho. For the two weeks the 46,000-acre Castle Rock Fire was burning, dense smoke and haze clouded the sky to the point that I could see neither the ski runs at Sun Valley (just a hoot and holler from my house) or the Boulder Mountains to the north of me. You will never know how beautiful clean air can be until you've lived through several weeks of smoke, ash, and debris falling around you. It's like living through the Apocalypse, particularly the experience of looking across the valley and seeing fire burn down the ridge so fast that it was as if it were being fanned by the Devil himself.

 

The fire has been hard on people, particularly businesses. It caused a cancellation of a lot of activities over Labor Day that were not only a lot of fun but that the local merchants depended on to bring in revenue. We are now officially in what is known as "slack season": hardly anybody comes here in fall, though heaven knows why. Fishing, hiking, camping and hunting are all great Idaho fall activities. I once went on a beautiful 6-mile hike to a pristine alpine lake and I did not see a single other soul during the hike, other than my hiking buddy and my dog. (Try that in California.) So come on up to Sun Valley, y'all. If there is anything better than terrific natural beauty, it's terrific natural beauty with no crowds.

 

My other change in perspective (besides a newfound appreciation for clean air) is the way I feel about firefighters. You hear all the time - and most of us believe it - that firefighters are heroes. I never doubted that. But it's one thing to think that in the abstract and another to have experienced it firsthand. I got to see a lot of them in Sun Valley in August, since we had 1600 firefighters in a town of 3000 people. My house was never in any real danger, for which I am grateful. Furthermore, there was no loss of life and no structural damage to anybody's houses or businesses. The critters even made out OK, too, though there are a lot of hungry bears wandering around looking for chow.  Pretty much every place in town now has a "thanks, firefighters" sign or banner displayed prominently. We really mean it: thank you, wildland firefighters, you saved our town.

 

Now that the fire is 100% contained, a lot of locals are saying that in the long run it is going to be healthy for the forests that we had a burn; in fact, we were overdue for one. The forest will recover; the wildlife will thrive (so long as cheat grass doesn't crowd out the sage that is a key habitat for many species). It's only been a couple of months since the Trail Creek Fire burned one of my favorite hikes in Sun Valley, but you can already see a sheen of green on the mountains and some new seedlings sprouting up through the blackened detritus. Forests recover, and a periodic burn gets rid of the underbrush that can otherwise build up and contribute to "crown fires" where the fire spreads not along the forest floor, but leaps from treetop to treetop. The difference between a disaster and a blessing in Ketchum was the skill of the firefighters, the grace of God and also the passage and perspective of time.

 

When you think about it, it's amazing how much of what you see really is based on your perspective. Perspective can include where you are as you look at The Big Picture, where you are in the picture and who else is in the picture.

 

I was reminded of this recently in a discussion with a state government struggling with open records issues. States keep a lot of data on their citizens to support, among other things, taxation (personal and property) and licensing (driver's, hunting, fishing, construction, "concealed carry"  permits and more). The question they were asking was how much of this data should be on-line and searchable?

 

I did not offer to write, critique or edit their state's open records laws, but I did point out to one of their legislators that a lot of concerns over privacy might depend very much on who is accessing the data and why they might want to access the data.

 

Most people are OK with some data being collected relevant to a transaction between parties. For example, to get a concealed carry permit in the state of Idaho, I needed to give the state some information to so they could do a background check on me. I also expect the state of Idaho to keep records about the fact they gave me a concealed carry permit (so that a law enforcement official can independently verify that I have a valid license and not a fake one, for example).

 

Many people who provide information for a service or transaction become unhappy if that data is accessed or sold or otherwise used for some purpose they didn't agree to. If you are dealing with a government entity like a state, you expect that when you give information to the state (that they need for things like raising taxes and providing services to citizens) they are going to use it for those "stated" purposes (no pun intended) and not for three thousand other things. I would not expect that the Idaho gun permit database would be searchable, say, by a gun ownership organization (or, conversely, by an anti-gun ownership organization). "Taint none of their goldurn business."

 

When data suppliers' expectations on who accesses what and for what purpose do not match with data collectors' uses, it's a problem. For example, if you've ordered books from Amazon.com, the next time you log on, you might get a friendly message that says something like, "Hi, <Your Name>! Based on your last few book purchases, we think you might be interested in the following books..." (In my case, the book list will be on military history or the Hawaiian language.) Many people might think: "Wow! How cool that they know me and can recommend books I might like!" 

 

Now imagine, if you will, the exact same message coming from the FBI**: "Hi, <Your Name>, based on your last five book purchases, we think you might be interested in ..." Many people would be outraged to think that the FBI (or another law enforcement entity) was looking at their book purchases. But, and here is the kicker: it is exactly the same data! Whether the above message is a "service" or an "invasion of privacy" depends on who had access to "my" data, who is doing the data analysis and why they are looking at the data. It's all about perspective.

 

In the private sector, these discussions take place in the realm of what a company collects, what they use the data for and who they can share the data with. Most companies have privacy policies that forbid collecting data for one stated purpose and using it or sharing it for another purpose that the "collectee" did not agree to, for example.

 

However, if data is public, or a public record, especially if it is Internet accessible and searchable, potentially anybody can access and analyze the data, for any purpose. My advice to the state was that they ought to hire someone to review the data they already have and figure out all the ways that data access could be misused by the evil-minded, like spear-phishers or stalkers. That is the place to start a legitimate public discussion about "open records;" specifically, how much the citizens of the state want to trade off convenience for privacy, and how much citizen data should be searchable and accessible by someone other than the state agency that collected it. It's all about perspective. 

 

People's perspectives on data collection can also be colored by the accuracy of the data that is kept. If someone made a mistake in doing a background check on me, that led to my being denied a carry permit, I should be able to get that "mistake" corrected. Otherwise, someone down the pike may find that I was once "denied" a carry permit and deny me something else. It's the second law of thermodynamics applied to data: entropy always increases. If data is inaccurate, inaccurate decisions will flow from use of that data.

 

Along those lines, there is another issue I've opined about a couple of times, and I'd be done with it except the topic keeps rearing its head in different forums, and that is the idea of "automated vulnerability testing your way to security." As much as I think that the use of automated tools can help deliver more security-worthy software and have said so, there are too many discussions of late dominated by the perspective that vendors are all evil, lazy and greedy slugs (ELGSs) that happily ship products with tons of security holes in them. The perspective of people who subscribe to the ELGS theory is that vendors must be forced to submit their code to multiple, random, unvetted tools to "validate" their security.

 

A differing perspective (mine) is that these tools are useful only to the extent they are used and work in development: they can't "prove" security, and vendors should license and use the tools that work well for them in development. The idea, after all, is to make products better, not have public "rat out" sessions after products have shipped. And I feel really strongly that anybody wanting to run a third party tool against a product should have to prove the tool works properly and accurately. It's only fair.

 

In fact, they ought to have to prove that the tool is accurate before it's used, otherwise the results may "taint" a vendor (just like a mistake in my background check could color people's perceptions of me forever if it is not corrected).

 

The idea of "burden of proof" is important for a couple of reasons. One of them is that we are still in the nascent stages of tool usage (if it were easy, everyone would already do it) and some of the tools don't work so well. The last thing industry needs when we are trying to promote and encourage tool usage in development is every customer, or every country, deciding that IT products need to be submitted to 348 different "tool tests."  Aside from annoyance and inefficiency, accepting tools' "vulnerability alarms" without question goes against the grain of how a lot of other things are supposed to and generally do work. For example:



  • People who are put on trial are assumed to be innocent until proven guilty. Hardly anybody gets thrown in jail for 25 years to life without someone (a prosecutor) validating the evidence, presenting it in court, and defending it (from defense challenges). The burden of proof in our court system is on the prosecution, and the standard of conviction is "beyond a reasonable doubt." (A 90% "false alarm rate" of evidence presented in a prosecution would not be "reasonable doubt.")


  • Journalists are expected to check facts before reporting that, for example, a celebrity was caught in a love nest with another celebrity. Furthermore, if journalists get the news wrong, they generally print a retraction or correction. (Of course, at that point, reputational damage may not be "retractable," which is one reason why good journalists are rigorous about fact checking.)


  • Gossip is called "gossip" and not "impartial fact exchange" because so much of it is not true and potentially hurtful or damaging. This is why your mom tells you not to do it. Mom is right, as she almost always is.

 

The ugly issue in the promise of automated vulnerability tools is that there is no standard for these tools: what they find, how well they find it. Which means anybody can create a tool, point it at a product, claim to find problems, and all the work is on the product vendor to prove their product does not have a problem instead of on a tools vendor to prove the tool is accurate. And let me tell you, having to go through hundreds or thousands of "potential vulnerability fire alarms"  to validate every one makes security worse, not better, because it takes a scarce resource (a security-aware developer) and puts him/her to work chasing phantoms instead of improving products.

 

Some tools vendors push the "evil vendor" perspective because to the extent they can convince IT vendors' customers that their products need to be scanned, they create fear, uncertainty, and doubt (FUD) and thus increase the demand for their scanning product. Can't blame them for that: it's capitalism at work. That said, I take the perspective that these tools offer promise, but they need to be validated to prove that they are accurate before anyone can be expected to use them. Only if they are accurate are they useful. If they are inaccurate, they are useless and harmful.  (Putting it differently, if IT vendors need to "prove" their products are secure, why shouldn't tools vendors need to "prove" their tools are accurate before anybody would even think of using them? What's sauce for the goose is sauce for the gander.)

 

Lastly, some of these tools are so "chattery" and "noisy" that it really is like gossip and, like gossip, the damage is done even if there is a retraction. A tool that has a lot of false alarms taints a vendor's brand just like tabloid journalists can print innuendo that damages someone's reputation unjustly. I shouldn't have to prove the coding equivalent of "I did not spend the weekend in a love nest with a celebrity,"  the vulnerability tool maker should have to prove that I did.

 

(Aside: one of my own amazingly wonderful ethical hacking team members just improved one of our internally-developed tools, a protocol fuzzer lovingly called BitRotter, to do more pernicious and nefarious code breaking in a good cause. He's just rechristened it ByteRotter. Thanks, Jeff.)

 

Clearly, my perspective isn't unbiased, because I work for an IT vendor. I believe in better security, doing more in secure development, and in industry "raising the bar" through better development practice. Automation (and automated tools) can definitely help.

 

I also believe in accuracy and fairness as basic principles of any business undertaking, because it is only when the haze and smoke and debris is swept away, that you can see - really see - what is there.

 

I climbed to the top of the ridge behind my house a few days after the Castle Rock Fire was declared 100% contained. The fall rains had come to help soothe the burns, and the winds that a few days prior had been fanning the fire were now whisking the few remaining puffs of smoke out of the valley. It's about a 600 foot climb through sage and scrub, but when I got to the top of the ridge, I could see the Boulder Mountains in the distance, and the ski runs at Sun Valley, still green and beautiful, and the aspens beginning to change color on the mountains that ring the Wood River Valley.

 

After two weeks of hellish smoke and ash and debris, I could see rightly - 'ike pono, as the Hawaiians say - for miles and miles and miles. There is no better perspective than that.

 

 

*  Mom also noted it was far from the last fit I would throw. What can I say? I learned useful business skills early.

 

** Disclaimer: I know several people who work for the FBI. They have difficult jobs that the rest of us don't understand and take for granted. I am quite sure they have more important things to do than check up on my latest book-buying binge. Ergo, no slight to them was intended nor should be inferred.

 

For more information:

 

Book of the week: I just read another book by James Hornfischer: Ship of Ghosts, about the USS Houston, sunk at the Battle of Sunda Straights in March 1942. Many of the survivors were forced to build the Burma Railway. An amazing story of survival and heroism. Definitely worth a read.

 

http://www.amazon.com/exec/obidos/ASIN/0553803905/bookstorenow69-20

 

About the Castle Rock Fire:

 

http://www.inciweb.org/incident/952/

 

http://www.sunvalleyonline.com/news/article.asp?ID_Article=3894

Summer Reading

Mon, 2007-09-03 12:41

It's not often that I read a headline that almost causes me to spill my morning coffee and then weep, but I confess I had that reaction to an article making the papers this week. The article said 1 out of 4 adults read no books in the past year. I find that as astonishing as if I had read that 1 out of 4 adults hates dogs. (Who doesn't like dogs?)

 

I really wonder what those 25% of adults do with their free time, because almost every minute of mine (not spent surfing) is spent reading. As long as I can remember, I have had a book addiction severe enough that I've thought about joining a 12-step program for Bookaholics: People Who Read Too Much. I started early and have never really slowed down. (I learned to print my name at age 4 only so I could get my very own library card.)

 

As an adult, I have books stacked two and three deep in all my bookshelves. I have them on top of the radiators (which I turn off - I'd rather shiver in winter than ruin a book). They are stacked under tables (with long tablecloths to hide the stacks) and on and under my nightstand. Under my coffee table and under my sofa, too. My mother expects to read that my apartment in San Francisco has sunk into San Francisco Bay from the weight of all those books. It's not quite as bad in Idaho, because a) I have more room! And b) I don't buy books so much anymore, but I devour whatever the Ketchum Community Library has - and they are really well-stocked.

 

It's not that I think I am better or smarter than those 1 out of 4 adults. (My dog differs but he is allowed his prejudices, which I happen to know can be bought for a couple of Greenies.) But reading has opened my eyes to worlds, histories, thoughts and dreams I never would have experienced otherwise. I can't imagine a life without books. I don't even go out of the house without reading material, because waiting in line (or at an airport or at a cafe for a friend) is an opportunity to read just a few more pages.

 

I am also a "carrier." When I find a book I really like, I buy copies for friends and nudge them into reading them. (Only I keep forgetting what I have already bought my nephew, which is how he ended up with two copies of Goodbye to All That by Robert Graves and 2 copies of Stories of Hawai'i by Jack London. Sorry, Piers!) My buddy Elad and I have traded books and writers back and forth for a couple of years now and have been known to read the same book at about the same time to have someone to enthuse with (or alternatively, pick a book apart).

 

I simply don't understand people who don't read books.

 

Love of reading is not a function of educational level, either. I had a friend once who, despite two degrees (2 - count 'em - 2) from Stanford, freely admitted she had read no books since graduation. (Yeesh.)  She marveled at the number of books in my apartment and wanted to know if I actually read them. It was all I could do not to say, "No, <name omitted>, they are wall insulation. Of course I read them!" No matter how impressive your educational credentials, a university education is just the beginning of knowledge. You learn, or should learn, to teach yourself. Books are the key. Reading also helps give you a broader perspective on the world than you might otherwise have. Let's face it; technology (for example) is not the be-all and end-all we sometimes think it is. (A shock, I know, to some in Silicon Valley who think history began with the transistor.)

 

I guess there is a security aspect to all this, somewhere, somehow. For a start, I do read a lot of military history and that helps me look at IT security from the posture of a warrior. I haven't personally worn a "war suit" for years or done field exercises/war games in years, but I think that reading military history helps give me a different slant on computer security. It also helps me connect with customers (like the Defense Department) because I can speak their language. I think about computer networks like battlefields and I look at battles of the past to think about IT defense.

 

Also, so much of history is military history. It grieves me to no end that all kids seem to learn about WWII anymore is synopsized in the following: "We interned the Japanese: That Was Bad. Women (like Rosie the Riveter) entered the workforce: That Was Good."Nothing about Midway, Guadalcanal, Iwo Jima, Okinawa, Stalingrad, Kursk. Why we fought, who fought, how the world changed and how the world was - for better or worse - shaped by war. I don't think we can hope to understand the present or shape the future if we do not understand the past. We also need to try to learn from the lessons of the past:  it history does not repeat itself, as the dictum goes, it sure does rhyme.

 

(Another "security" aspect to my reading: I would not have known, without reading Miracle at Midway by Gordon Prange, that the victory at Midway was made possible in no small part because the US had broken Japan's JN25 naval cipher. Code breaking was critical in other aspects of the war, too, as anyone who has read about Enigma knows. The lesson here is that you should never assume your codes are unbreakable unless you are using one-time pad ciphers and not reusing the pads.)

 

So, I offer below (because it is, technically still summer, and because kids aren't the only ones who need reading lists), a smattering of books in no particular order I'd recommend for anybody's reading list.

 

Oracle 10g Performance Tuning Tips and Techniques by Rich Niemic

 

Well, it's not fiction, and it's not history, and normally, I would not put a tech book on my reading list. All that said, it's actually easy to recommend this book because I am a) not a performance tuning person and b) not someone who was ever even remotely interested in performance tuning. I am, however, a charter member of the Rich Niemic Fan Club (Rich is the former president of the Oracle User Group and a big Oracle security friend). Rich asked me to provide a quote for his book and, in reading the sections he sent me (I wanted to make sure the book was great before I gushed over it publicly), I became really interested in performance tuning. Who knew? This book is very readable, it's really interesting, and I can guarantee you that your Grandma from Des Moines will be a performance tuning fool after reading this book. Life's too short to buy some dull Oracle-related tome that you will never read and that won't help you. (Especially when you can buy this one that's fun to read and will most definitely help make your database crank!)

 

Sea of Thunder by Evan Thomas
Last Stand of the Tin Can Sailors by James Hornfischer.

 

Many of us spend oodles of money to go to the movies to see battles of derring do between good guys and bad guys, or defenders of the universe vs. evil aliens. Save the $10 ($15 with popcorn) and buy one or both of these books to read about real heroism against the odds. Both books describe the Battle off Samar in the Philippines in 1944, a story that should be told and retold as long as acts of heroism are recounted through generations. This is the story of the men of Taffy3 (destroyers, general purpose or "Jeep" carriers and destroyer escorts) against the Japanese armada, including the Yamato, the largest battleship ever built. Think about a bunch of determined gnats going up against an angry tiger - and winning!

 

I confess to having more than a passing interest in this story: Mick Carney, ADM Bull Halsey's chief of staff (and family friend) is liberally quoted in Sea of Thunder and another family friend is quoted in Last Stand of the Tin Can Sailors. I have read both books, more than once, and as I close the back cover, I always say, "Where do we get such men?" There is also (gotta work that security angle in here) a retelling of the incredible but true story of an well-known encryption blunder: the infamous message from ADM Chester Nimitz to ADM Bull Halsey: "Where is task force 34 the world wonders?"  (The last three words were message padding, a slight rip-off of the Charge of the Light Brigade by Tennyson and not intended to be part of the message; Halsey read it, thought Nimitz was ridiculing him, and had a fit. He then turned his carriers around from pursuing the Japanese and headed back to where Taffy3 was in the thick of battle. Some LTJG was cashiered for that mistake, one suspects.)

 

Power, Faith and Fantasy: A History of America in the Middle East: 1776 to the Present by Michael Oren

 

The Middle East is much in the news these days, and it is interesting to note how long America has been involved in the Middle East: since the origins of the country. There are a lot of amazing factoids in here, such as: one of the reasons the United States has a strong constitution (supplanting the Articles of Confederation) is because of the Barbary pirates (and that at one point, the United States was giving up 25% of our GDP in tribute  - better known as "blackmail" - to the Barbary pirates). The states realized that individually, they could not raise a strong navy, but a strong centralized government could, and voila - we have a strong central government and the beginning of US naval power. (Ever wonder about that line in the Marine Corps Hymn: "...to the shores of Tripoli?" That came from the war against the Barbary pirates.)  A really interesting read and a view of history you won't readily find anywhere else.

 

A Peace to End All Peace: The Fall of the Ottoman Empire and the Creation of the Modern Middle East by David Fromkin

 

If you want to know a lot of why the Middle East is the way it is, you need to understand how the borders got drawn and by whom. For that, you need to at least go back as far as the first World War and the dissolution of the Ottoman Empire. This book tells you almost more than you want to know about the subject, but it is thorough and will explain a lot that you can't easily understand without reading history. I confess to having had an argument over the Middle East once (well, more than once - I'm obviously opinionated on a number of topics) and I threw out a lot of points related to "how the borders got drawn and who did all that, anyway?" The gentleman I was arguing with asked - in amazement - how I came by all that information, to which I responded (slightly censored version), "I read history." I should have said that I read this book. It's a worthy (and non-polemical) read, well researched and presented.

 

A Better War by Lewis Sorley.

 

For those of us of a certain age (if you lived through the late 1960s), reading about or discussing Viet Nam is a painful exercise. The author is a West Point graduate and a former intelligence professional and, well, you will have to read the book to have your myths shattered. It should be required reading for anybody before even thinking about discussing Viet Nam. The book is balanced, thoughtful, well researched, but an eye opener.

 

Pied Piper, Trustee from the Toolroom, Requiem for A Wren, In the Wet, aw heck, how about anything by Nevil Shute

 

I had the unfortunate experience recently of reading a really dreary modern piece of dreck...er...literature for my book group about loss (related to September 11), and I could not but contrast the heavy handed plot, the wandering, aimless prose and the thoroughly unsympathetic characters in that book with Requiem for a Wren by Nevil Shute (also published under the title The Breaking Wave), that I had just read. What comes through in his work (besides his keen interest in engineering, aviation, archeology and other topics) is the fundamental decency of his characters, many of whom are confronted with hard choices and with unspeakable losses, but who soldier on, anyway. I am pleased to say that the Ketchum Community Library has 13 works by Shute and I intend to read them all. (Several of his books have been made into movies, including No Highway (the movie version is No Highway in the Sky), Pied Piper and On The Beach.)

 

From a security aspect, No Highway talks about an engineer who is convinced that a plane is about to have a catastrophic failure. It also concerns the lengths he goes to to ground the plane before there is an accident. It is a lesson in integrity, risk, and the moral issues around how far one can go or should go to ensure safety.

 

The Poems of A.E. Housman

 

I have a Housman fetish. I once spent two years looking for his books in print - anywhere. It took me that long to find a (used) copy of his complete poems. Later that same year, I went to Blackwell's in Oxford, England (the Mecca for bibliophiles, or one of them) and they had three shelves of works by and about Housman. Sigh. I think the folks at Blackwell's are still washing the saliva off the floor from the amount of drooling I did there. There is no finer poet or one more capable of eliciting wistfulness from the reader. "To an athlete dying young" is a particular favorite (and should be familiar to you if you saw Out of Africa).

 

Jasper Fforde's Thursday Next books (The Eyre Affair, Lost in a Good Book, The Well of Lost Plots, Something Rotten, First Among Sequels)

 

Fforde is just as witty and silly (good silly) in person as his books are; I heard him speak recently about his latest book, First Among Sequels. His books are really hard to explain; they simply defy genre. I liked the review that said they are a combination of Buffy the Vampire Slayer, Harry Potter, and Monty Python. The books contain absolutely outrageous puns and amazing literary references (Jane Eyre is a character; so are Hamlet, Miss Havisham and Mrs.Tiggy-Winkle). Life is serious enough; sometimes you need to read something very smart but amazingly silly.

 

The Code Book by Simon Singh

 

Closing out with a security book of sorts. I confess to not being a technical security kahuna in a lot of ways, particularly in the area of cryptography (which is, let's face it, one of the sexier parts of security). The Code Book really explains cryptography, and the history of it, in a readable, interesting way. You can sit through a lot of truly dull lectures and presentations, or you can grab this book and happily read your way to being a whole lot smarter about crypto (and a lot more appreciative of code breakers and makers throughout history).

 

A few closing thoughts. Lest anyone think I am a stuffed shirt who only reads Meaningful Tomes, I freely confess that I have read more than my share of murder mysteries, suspense books, adventure tales, science fiction, children's books and things that don't always qualify as literature but are great reads. Some days, after a hard week at work, you want "mind candy" and not War and Peace (with apologies to Count Leo Tolstoy).  It is just not that hard to be one of the 75% of adults who read at least one book a year, so go for it.

 

Almost all of these books can be ordered from Amazon, Borders, Barnes and Noble and so on and so forth. Or, you can patronize your local independent bookseller (the ones who remember what you like). Or you can support your local library and borrow the book. (Libraries like donations, too.) Go get lost in a good book.

 

For more information:

 

1 in 4 adults read no books last year:

 

http://www.msnbc.msn.com/id/20381678/

 

Rich Niemic's book:

 

http://www.amazon.com/Oracle-Database-Performance-Tuning-Techniques/dp/0072263059

 

About Nevil Shute:

 

http://www.nevilshute.org/biblio.php

 

Jasper Fforde's web site:

 

http://www.jasperfforde.com/

 

About the Battle off Samar:

 

http://www.bosamar.com/

 

The Code Book:

 

http://www.simonsingh.net/The_Code_Book.html

 

Selected poems of A.E. Housman online at:

 

http://www.chiark.greenend.org.uk/~martinh/poems/housman.html#ASLxix

 

A review of A Better War:

 

http://findarticles.com/p/articles/mi_m0IBR/is_3_30/ai_67502116

 

More on "the world wonders" padding screwup:

 

http://en.wikipedia.org/wiki/The_world_wonders

 

A really great biography of Halsey by the late E.B. Potter (former professor emeritus at the US Naval Academy):

 

http://www.amazon.com/Bull-Halsey-Elmer-Belmont-Potter/dp/1591146917

 

Who also wrote a great book on Nimitz:

 

http://www.amazon.com/Nimitz-E-B-Potter/dp/0870214926

 

Sanctuary

Tue, 2007-08-28 09:16

As many of you know from previous blogs, I have a language fetish I like to indulge as often as possible. One of my recent acquisitions is Baibala Hemolole (Holy Bible, translated into Hawaiian) which gives me a chance to practice my incipient (OK, rudimentary) Hawaiian language skills by reading something that's familiar to me in English, so I can do a sort of "reverse translation" into Hawaiian. For example, since I know Psalm 137 by heart ("By the rivers of Babylon, we sat down and wept, when we remembered Zion...") it's pretty easy to read it in Hawaiian and pick out the meaning of Hawaiian words whose meanings I don't otherwise know.

 

(Small aside: lots of people love the King James Version of the Bible for its majestic language, but it is fairly widely acknowledged to be among the worst translations in terms of linguistic accuracy. If you don't know Aramaic, Hebrew and Koinic Greek (and who does besides seminary graduates and classicists?) go with the New International Version if you want to read something that's as close to the original texts as linguistic, cultural and "manuscriptural" differences will allow.) 

 

Occasionally, I find a translation that actually sounds better in Hawaiian than in English. A Jewish friend asked me how the translators had done with the ten plagues of Egypt (described in Exodus): how accurate were the words in Hawaiian? As far as I could tell (this after an hour or so with Baibala Hemolele and a Hawaiian dictionary), most of the words used by translators were pretty spot on. I went through about 6 or 7 plagues to reach that conclusion. When I got to the plague of darkness, I found that the translators used the word  po'ele'ele.  In Hawaiian, pô is night, 'ele is black, and reduplication adds emphasis, so a good translation of po'ele'ele would be "the deepest darkness of night." And truthfully, that is a far more terrifying plague (if you are Pharaoh) than plain old "darkness." I like that.

 

There are actually a number of words whose meaning has shifted or been corrupted over time (or through moving into different languages) until what we swear a word means is actually not what it means at all. One of these words is taboo.  The Merriam Webster online dictionary provides the following definition:

 

1 : forbidden to profane use or contact because of what are held to be dangerous supernatural powers
2 a : banned on grounds of morality or taste <the subject is taboo> b : banned as constituting a risk

 

So, most people use taboo to mean something that's forbidden, or that is outside societal norms. However, if you look at where the word came from, that's not what it means at all. The origins of the word taboo are Polynesian: tapu in Tahitian, tabu in Tongan or kapu in Hawaiian. What the word really means is "sacred." Now, that's a surprise. Sacred, not forbidden. After you let that sink in, you realize that it's actually quite understandable why people think the word means "forbidden," because in many religions, the things of God (or the gods) are sometimes forbidden to mere mortals. In Hawaiian religion, there were things that only the ali'i (chiefs) or mo'i (kings) could do, eat, or access. Various surfing spots, for example, being sacred (kapu), were reserved for the ali'i and thus forbidden to commoners.

 

One source I looked at said the kapu system existed to maintain pono (rightness) between the gods, lands, and people. For example, the Hawaiians had a practice of putting various fishing grounds out of rotation to preserve the larger ecosystem. A fishing area was declared kapu: sacred, off limits. By doing this, the Hawaiian avoided the problem of overfishing (and implicitly recognized that the bounty of the ocean is a sacred thing, if I can be indulged here).  Having experienced the mystery and the wonder of surfing when honu (Hawaiian green sea turtle) flipper through the lineup, and Hawaiian monk seals lope through the waves, I can say that the experience is indeed kapu, sacred.

 

It's therefore with some appreciation that I note that the largest marine sanctuary in the world was created about a year ago, in the northwest Hawaiian Islands. It's also the largest conservation area in the United States. It has, of course, a Hawaiian name: Papâhanaumokuâkea. (Click here if you want to know how to say it properly:  http://www.hawaiireef.noaa.gov/about/PMNM_Pronounce.MP3). The kupuna (ancestors) would approve.

 

Along similar linguistic lines, the word "sanctuary"comes from the word sanctus in Latin, meaning "holy" or "sacred." Here is (Merriam Webster's) definition:

 

1 : a consecrated place: as a : the ancient Hebrew temple at Jerusalem or its holy of holies b (1) : the most sacred part of a religious building (as the part of a Christian church in which the altar is placed) (2) : the room in which general worship services are held (3) : a place (as a church or a temple) for worship
2 a (1) : a place of refuge and protection (2) : a refuge for wildlife where predators are controlled and hunting is illegal b : the immunity from law attached to a sanctuary

 

What the Hawaiians would have declared kapu has become the largest marine sanctuary in the world, with the same idea. Something that is sacred is "off limits" to some, so that its sacredness can be preserved. And Papâhanaumokuâkea is also a place of refuge for the critters that live there, to address both senses of the word sanctuary.

 

Sanctuaries can crop up where you least expect to find them. For example, we are starting a metrics project within my team. Metrics are one of those tricky areas that can inspire the full range of reactions from near-religious ecstasy (speaking of the sacred) to the gag reflex, depending on who is talking about the issue and which metrics are actually in use. I view metrics very simply: as a tool in order to be able to manage better. I had an engineering professor who said, "All the easy problems were solved in the 19th century." I am not so sure about that: I think there are easier and harder problems left to work out. However, trying to determine which are the biggest problems  (e.g., through metrics) certainly helps you work on the problems that matter. Also, and as I talked about in an earlier blog entry, nobody ever has unlimited time, people, computing cycles, and so on, so trying to whack away at the worst problems first (which metrics can help identify) is just good management.

 

A secondary goal of metrics is holding people accountable for things whose outcome they can control. That last bit is an important qualification because there are, alas, people who jump on metrics with It's The Latest Business Fad fervor, only to use metrics as a way to identify whose throat to choke. I'm all for accountability, but accountability without authority is a recipe for frustration. I can measure the weather pretty accurately, but I can't reasonably fire anybody for it being too hot unless I can find someone who works for me who actually has the ability to control the weather.

 

Our goal in the metrics project is to both data mine what we already have (such as the Oracle bug database) to look for interesting patterns (do we have differences in, say, the top 5 security vulnerabilities that vary by development group?) and to try to develop metrics that help us manage better going forward. I should also note that we have plenty of metrics we use in development already for things like code coverage, bug counts and trends, and so on. What we are doing is working up some security-specific bug metrics beyond what we already do. I have to say that development groups seem keen to embrace this, because the Amazingly Wonderful Person who is driving the project (and who has a well ordered plan) has been chivvied into immediately jumping into data mining for one of the development groups. Those developers want to know where their biggest problems are so they can attack those first. Who could ask for anything more? It's kind of like wanting to know your top five sins so you can properly repent of them.

 

It may seem strange to talk about metrics in the same breath as "sanctuary." Like the word "kapu," the received wisdom about what the word means is at odds with what the word actually does mean. My goal for this project really is simple (I have no hidden agenda): for us to manage better. If we find, for example, that the top five major security vulnerabilities do differ by development group, it may mean that we need different tools (from one group to the next), or different training, or better tricks to make it easy for people to do the right thing (e.g., we give them an API instead of telling them "go roll your own code"). I am also optimistic that nothing succeeds like success. If you can help development do better, faster (by targeting their efforts), then they get to reap the rewards of that and they want to continue to invest in improvement.

 

Targeting your energies also help avoid the "everything is number 1 priority" syndrome that so many companies fall prey to. I once had a manager who (and I am not making this up) had literally three pages (single spaced, double column, about 12 point font) of projects that we were not doing (in addition to the ones we were doing). Every week at his staff meeting, we went over the Projects We Aren't Doing List as well as status of ones we were working on. I finally got so irritated that I pointed out to him that even managing the list of Things We Aren't Doing creates work and consumes resources (why, only last week, I Didn't Climb Mount Everest and I Didn't Invent a Cure for Cancer). Why not make a decision just to Not Do These <Dumb> Projects, period?  Because some of them we were never, ever going to get to, anyway.

 

I hope that this metrics project will, in a way, create a sanctuary for development, because the data will help them focus their energies and help give them credit when we make progress. Not that I am ever shy about speaking up and saying "the emperor has no clothes," but I don't want my team to be the team thought of as "the people always giving development a hard time" as much as "the team that helps make it easy for development to develop securely." And just like religion, while people might start doing the right thing out of fear, it is far better, in the long run, for people to do the right thing from a sense of what is pono (right)  and kapu (sacred).

 

"And what does the LORD require of you? To act justly and to love mercy and to walk humbly with your God?" Micah 6:8

 

"A he aha ka mea a ke Akua i kauoha mai ai ia oe, ke ole e hana i ka pono, a e aloha i ka lokomaikai, a e hoohaahaa i ka hele ana me ke Akua?" Micah 6:8

 

 

For more information:

 

Speaking of sanctuary, my home is my sanctuary, as it is for most people, so a big mahalo nui loa to all the terrific firefighters who are currently battling the Castle Creek Fire in Ketchum, Idaho that is threatening so many people's homes and the Sun Valley ski resort. You guys and gals are no ka 'oi - "dabest."

 

An essay on the religion(s) of Polynesia:

 

http://philtar.ucsm.ac.uk/encyclopedia/poly/geness.html

 

About the Hawaiian Marine Sanctuary, Papâhanaumokuâkea:

 

http://www.hawaiireef.noaa.gov/about/welcome.html

 

Where to get your very own Baibala Hemolele:

 

http://www.amazon.com/Baibala-Hemolele-Hawaiian-Bible-FL/dp/1585161993

 

Or find it online at:

 

http://baibala.org/

 

More on Hawaiian green sea turtles (honu):

 

http://www.islander-magazine.com/honu.html

Speed Bumps

Tue, 2007-08-14 12:15

Summertime tends to be the time of year when people naturally slow down. (In some cases, it is because of absolutely unbearable heat -- who wants to move fast when it's 98 degrees out?) Summer is the season when you take vacations, change gears and get away from work. You realize there is a big wide world out there that comes to you through other vectors than email and the Internet. Even if you are working, there are a lot of distractions, like warm summer nights, sun-dappled days for bike rides, warm water and late sunsets for surfing. Summer is just one big speed bump telling you to slow down, observe, to pay attention to something other than the daily commute. You need those speed bumps.


 


I was out surfing recently at my usual surf habitat in Pacifica. Normally, you catch a wave, the face slopes; you slot into it and keep riding the face of the wave. My best surfing buddy, Kerry, calls me "the Queen of Trim," because when I catch a wave, I am really good at finding the absolutely right spot on the board to keep it in perfect trim: slotted into the wave so I can keep riding until there is no more wave. In my opinion, "kicking out" before the ride is done is the 8th deadly sin and a waste of a perfectly good wave.


 


The local surf break I frequent has a bit at the north end of the beach that's kind of steep, so depending on the tides, you may be riding in and find that you meet the backwash of the previous wave -- or two. Those backwash bumps are really a surprise when you hit them, because you end up riding UP the back of a wave and down the front again, sometimes more than once. Fun. Strange. Shakes up the surf session. Surfing is not, in general, supposed to be like riding a roller coaster. Except when it is. You remember not to surf on autopilot or you will wipe out when you hit the "speed bump." It's the ocean's way of getting you to pay attention.


 


Some of the speed bumps I get are in my inbox: I hear from people I haven't heard from in awhile, I end up being distracted from my "regular work," only the distraction turns out to be pretty important. I got an email recently from a colleague and friend -- Jaime Chanaga. I was impressed with Jaime the first time I met him (I think we were on a panel together at some security-fest or another). Jaime is among the few -- the very few -- who, as a CISO several years ago was already putting questions in his RFPs asking about the kind of care his vendors took in the way they built security into products.


 


Anyway, Jaime recently emailed me with a PPT he had done on security excellence, which, in my own nosy parker way, I suggested he turn into a blog (he did). His security excellence principles include things like valuing people and leading with integrity. Why is his blog a good speed bump? Because you could read an endless procession of Management Tomes without ever finding useful advice like this. His advice is good, solid, and timeless. I know this because I spent two years getting an expensive graduate business degree from Wharton and I am not really sure that most people there know or care about the difference between management and leadership. (Unfortunately, too many people who espouse "principle-centered leadership" -- or whatever the latest business buzzword is -- are not practitioners of it: "look after people" really means "look after (self; by using) people."


 


Since I know him, I can say with confidence that Jaime practices what he preaches. His suggestions for security excellence are good reminders for those days when you are feeling like crankily cutting corners with people you work with or who work for you. Thank you, Jaime, for a speed bump reminder -- your email -- that being a decent and good person of high integrity is among the most valuable business skills there are, for security gurus and others. (These principles are mom-approved, too.)


 


I am playing fast and loose with the term "speed bump," but I would like to extend it to various other cautionary signs that admonish some attention on the road from where you've been to where you are going. I add that some of these signs have real meaning here in Idaho.


 


"Game crossing," for example, does not mean a bunch of geeks with X-boxes are likely to cross Highway 20, no sirree. Not only do "Game Crossing" signs in Idaho mean that herds of critters -- like elk -- move along various corridors that cross highways, the state of Idaho adds a flag to the Game Crossing signs during the seasons when the animals are most active. It's Idaho Fish and Game's way of saying, "Pay attention: we really mean it!" I just read a blog entry by the former police chief of Hailey, Idaho talking about near misses with large critters. His theory is that suicidal and vengeful deer cross the highway to target people who have hunting licenses. (I feel compelled to add that Brian's blog entry provides a far better sense of a road trip across America than most anything else I have read.)


 


Game crossing signs, aside from mitigating the risk of "bull elk as unwanted hood ornament," do help you slow down and look at the scenery, which in Idaho is pretty spectacular. On the road from Boise to Ketchum, I've seen elk, moose, deer, antelope, peregrine falcons (Idaho is the home of the World Center for Birds of Prey, and has done more than any other state to help bring the peregrine falcon back from near-extinction), coyote, skunk, owls, porcupine, sand hill cranes, and foxes. There are wolves in the northern part of the Wood River Valley, though I've never seen them. Only last night, I saw a mother mule deer and twin fawns crossing Sun Valley Road at dusk. I hope I never get jaded at seeing such amazing animals. (It sure beats doing that 512th email of the day.)


 


The other speed bumps that really mean something around here are the fire warning signs. This summer has been unusually hot, dry, and windy. A perfect (fire) storm. Large parts of the west are burning, in some cases because of lightning strikes, in other cases because of stupid and careless individuals. A sign in a campground that says "No Campfires" means no campfires. "Please do not set off illegal fireworks," means it, too. The first fire of the summer here in Blaine County burned one of my favorite walks in Sun Valley -- Trail Creek. The entire mountain is blackened and looks like a moonscape. All because someone carelessly set a fire during high burn conditions. If you are camping or hiking in the west this summer, be careful, folks. Fire warning signs really mean something this year and there is no Undo button if you get it wrong.


 


Since I happily set up a topic on cautionary notes/speed bumps, I am going to add one myself, and it goes to the always contentious, World-Wrestling-Federation-has-never-seen-anything-like-it area of how to handle security vulnerabilities. I'm going to avoid the pothole -- for now -- of responsible disclosure vs. full disclosure except to note that, like everything else in life, there is no perfect disclosure policy that optimizes on all parameters. And in fact, there are no perfect patching policies, either. Only in Never- Never Land or Oz can you patch every single security vulnerability of every single severity in real time on all affected versions such that patch application is real time and perfect, too. That should be obvious -- when we get into these discussions -- but it isn't.


 


The gritty reality is that life is constrained. No company or organization or individual has infinite resources ("resource" includes time, expertise, people, pretty much anything that you need to effect positive change but doesn't grow on trees). By definition, something that is not infinite or free  -- or both -- is constrained. For example, I don't have to pay to use the ocean, but my surfing is constrained by the number of other people out in the water, the time between swells (sometimes it's a good 20 minutes between waves, some days it's more like "catch a wave, paddle out, catch another wave right away, come in after 45 minutes because you are exhausted") and so on. Even surfing is constrained because while there are an infinite number of waves -- over time -- there are only so many during the time I am out surfing and each wave holds two people at most.


 


We shouldn't always attribute evil motives to the fact that organizations live with constraints. Constraints affect both vendors and their customers. Vendors cannot always create patches for every single issue on every single old version of product (sometimes, a fix would require an architectural change, which we all know can't happen on old products in all cases since architectural fixes aren't always backportable). Constrained resources also apply to the companies who apply patches. At a minimum, companies need their systems to be up some reasonable amount of time so that people can work (one reason that companies really, truly hate taking systems down for "emergency fixes" unless it's truly an emergency -- and not a manufactured emergency, either).


 


Even if a vendor could create the equivalent of The Security Patch That Ate Cleveland (e.g., a patch that includes fixes for all security vulnerabilities from the beginning of time), the amount of work for a customer to actually apply The Security Patch That Ate Cleveland is equivalent to upgrading to a new product version (containing all those fixes already), which many customers do regularly for other reasons. Living with constraints mean that as a vendor, you sit around and try, within some basic principles, to figure out how to do the most effective good for the most people. It doesn't mean doing the minimum and hoping nobody notices, but it does mean weighing a lot of different factors in trying to make the best use of time and people to protect the most customers you can in the most cost effective way for them.


 


Small digression: this is a good time to give a quick recap of the amount of work that does go into fixing security issues, which is why we continue to work to avoid these problems in the first place (through coding standards, better vulnerability testing tools, process improvements, and so on). So, here goes: Oracle has multiple large product stacks, each of which has multiple supported versions, each of which runs on multiple operating systems (the last major release of the Oracle database alone shipped on something like 19 OSs). The stacks are interdependent (for example, Oracle eBusiness Suite runs on Oracle Application Server and the Oracle Database).  And of course, we have made many product acquisitions that also have "other Oracle product" dependencies.


 


In short, it's not enough just to fix a product problem where it occurs, you need to make sure it does not break something else that depends on the product, otherwise the "fix" is useless to a customer. And of course, all the moving parts (patches) across the company have to come out on the same day, because you don't want customers bringing down, for example, Oracle Application Server one week to apply an Oracle Database (client-side) patch, the second week to fix an Oracle Application Server bug, and the third week to patch some Oracle Collaboration Suite components that run on the middle tier. The interdependencies, time constraint (we have a fixed delivery date that can't move) and "ripple" effect are the main reason why fixing a security issue is something measured on a calendar, not a stopwatch. I try to explain this in terms of the well-known Mastercard ads:


 



  • Two line code change fixing security bug -- 20 minutes
  • Finding all similar/related bugs, on all affected product versions, fixing them, thoroughly testing the fix across all versions and product dependencies -- 3 months
  • Handing customers a fix that doesn't break anything else --priceless

Where does this leave us? With a speed bump that says, in effect, newer versions of products -- almost any vendor's products -- are probably, all other things being equal, "more secure." This seems obvious, but it is worth stating. Vendors -- most of us -- know more about secure development and secure coding than we did even three or four years ago. Newer products reflect that. Also, even if we can't fix every single security issue on old product versions, we certainly are going to fix it in new versions. Preferably, as soon as we can because it is just good business and common sense to do this.


 


I think I should pause now and comment on a predictable screaming point -- the idea unfortunately -- but widely -- promulgated that all security issues should be fixed at exactly the same time for everybody. If they aren't, the conventional wisdom goes, the vendor is being evil-minded towards their customers.


 


With all due respect, that is a lot of hooey, for reasons that should be obvious.


 


Suppose I am a developer building a housing development containing 100 houses. Suppose also that 20 houses into my development, I realize that I have a problem with leaky bathroom sinks. In fact, it's systemic enough that I need a different sink to be dropped in. I can't just fix the leaks -- I need to swap out the sink. I have several choices here:


 


n      I can finish the 80 other houses with the old leaky sinks, so everybody's house is equally leaky. Then, I rip out 100 sinks and retrofit them all at the same time. In the construction business (and I know this because I used to work in construction) this option is called "How Dumb Can You Be?"


 


n      I can use the new sinks in the next house I build (number 21) and in the rest of them (houses 22-100). I can then go back and fix the 20 houses with the old bad sinks. We can argue about the exact timing of who, in houses 1 through 20, gets the new sinks when, but one thing that is clear -- if I am just about to drop a bathroom sink into house number 21, and I have a chance to put a WORKING sink in that doesn't leak, that's what I should do. Having 100 flooded bathrooms to prove a principle of equality is a recipe for being out of business. It's also really dumb, expensively so, for everybody.


 


Note that I am not disputing that maybe, the sink design should have been reviewed earlier, or more carefully. Or that the contractor should learn from the sink problem so new housing developments have better sinks (maybe the architect was at fault, or maybe the contractor had a bad supplier). These are all good points, and valid ones. But the reality is, and I also know this from working in construction, there is just no such thing as a building that goes up with absolutely no change orders (contract modifications due to something needing to be fixed during construction). I spent about 80% of my first job in the Navy negotiating change orders to construction contracts, and about 20% of my time managing the actual contracts. And I had mostly good architects, good engineers, and good contractors.


 


Oracle has tried to optimize fixing critical -- and we mean critical -- security issues in reasonably consumable chunks, four times a year for people on older product versions. We call these "critical patch updates." I also note that we actually fix security issues going forward (in new versions and patch sets) FIRST. This means, all things being equal, newer versions and patch sets have more security fixes, and generally have them sooner. We do this because, if we have a product train leaving the station, and there is a critical security problem, it makes sense -- and protects customers best -- if we get that critical issue fixed going forward if we possibly can. We bundle many -- but not all -- security fixes into critical patch updates and release those four times a year. Because of the amount of overhead in fixing, backporting, testing and integrating combined fixes, it means that there may be and often is a time lag to get a fix into older product versions (which is when we announce the fix -- when a patch goes out for those older versions). Just like the folks in houses 1-20 might have to wait to get new sinks (while people in houses 21-100 don't have that problem). It's not a perfect solution, but it is better than not fixing anything going forward to the point that everybody ends up having to install the The Security Patch That Ate Cleveland.


 


The most unpleasant conversations I ever have with customers, and I have had several of these, occurs when a customer has never applied any security fixes (in the days when we did security alerts) and is running on a version that was (at that time) long out-of-support. (Even with new support models we've put in place, we do not issue security alerts or CPUs for all versions.) The customer is now running on what can only be construed as an archeological version of product (as in, Oracle7 or Oracle 7.2, and I am not making that up), and yet it is a mission critical application. The customer wants to know if they are "at risk" from unpatched security vulnerabilities. I think I can safely say that they are. And I have. I also tell them that we do not do security analysis on out-of-support versions of product, but in many cases an issue we are fixing (via a critical patch update) has been in code awhile and probably does exist in the really old, out-of-support product version.


 


I know people like nice, stable versions of product; who doesn't? (I drove a Honda CRX for 17 years and only got a new car since the Honda was coming up on 300,000 miles and I couldn't retrofit cup holders into it.) But I tell customers they need to plan on some regular maintenance, and -- all things being equal -- newer versions of product are more secure. If I had to put this into rote form, it would be: "Dear customer: it is in your interests to upgrade from time to time, because we cannot fix every single security issue of every single severity on every single old version. Nobody can. We try as best we can to protect the most customers to the best of our ability. Part of that also means making newer versions better. Please don't move to the second-from-oldest supported version to 'get current,' please move to the latest and greatest product version if you possibly can."


 


I offer the above as my own speed bump -- a chance for people racing along the highway of security and in particular, security vulnerability handling to stop, look, observe, and slow down.


 


For more information:


 


Jaime Chanaga's good advice on security leadership (July 16 blog entry):


 


http://blog.csoboard.com/cso/


 


The Hailey, Idaho (former) police chief's blog on Vengeful Deer, Jesus and Bob and Big Water:


 


http://blog.sunvalleyonline.com/index.php/msg-from-the-chief/1906/


 


Pictures of the Trail Creek fire:


 


http://www.sunvalleyonline.com/news/article.asp?ID_Article=3681


 


The World Center for Birds of Prey:


 


http://www.peregrinefund.org/world_center.asp


 


The release of the new Idaho quarter (with a peregrine falcon on it!):


 


http://www.doi.gov/news/07_News_Releases/070803.html


 

Know Thyself

Tue, 2007-07-31 07:47

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

Pages