« June 2006 | Main | August 2006 »

July 2006 Archives

July 7, 2006

Let Us Now Praise (Not So) Famous Men and Women

In regards to a matter of both procedure and etiquette (I hate the word "Netiquette," because good manners are timeless and are only diminished by the Internet, not enhanced by it), one of our stellar marketing kahunas emailed me a week or so ago to say that a lot of responses to my blog had not gotten posted through a technical snafu (a word of military origins, from the acronym "situation normal: all fouled up"). She apologized to me and said the issue had been fixed and would not—fingers crossed—occur again. Katheryn now also knows the Hawaiian for "bummer about that" (Auwē noho'i e!) for future reference. So, first of all, thanks to those of you who posted in response to my blog—particularly those who liked it—and my apologies that your comments did not appear sooner. I hope to get back to some of you individually over the next few weeks.



I was pleasantly surprised to read postings from several old friends, including someone who served with me at my last active duty Navy command. Still another poster (who knew me from a previous life at Oracle) wondered in conjunction with the blog entry on military history why I have not talked about my military background more extensively.



As I write this, it's the 4th of July (I joke with my UK employees that, though they do not get the day off, they can recognize this as "Thank Heavens, We Got Rid of Those Troublesome Colonials Day.") While there are many patriots who do not wear a uniform, it's also true that those who have served in the military literally have laid their lives on the line for their country. As such, it is a good day to reflect upon the nature of military service, and the way my military service influences my thoughts on security to this day.



I spent a fair bit of my late childhood and adolescence living at the United States Naval Academy, where my father was the academic dean (a civilian position, but he was in the Air Force Reserve at the time—more on that later). I grew up around a number of military people and was privileged to meet some extraordinary individuals who had real places in history; e.g., one of the die-hard fans I used to sit next to at Navy sporting events was a retired rear admiral who had been the berthing officer at Pearl Harbor the day the Japanese struck (in short, he had decided where the ships were parked that day). Another individual I met had been ADM "Bull" Halsey's chief of staff and later, was Chief of Naval Operations during the Korean War. The headmaster of my school set up the Cuban Missile Blockade. My algebra teacher was a defender of Midway (BGEN "Barbed-Wire Bob" Hommel). These individuals continue to exercise an influence on me for reasons as diverse as the opportunities that they helped make available to me in the Navy, and the content of their character, which I hope I emulate half as well as they did.



My military career was short and nowhere near as illustrious as that of so many people I met growing up. I joined the Navy directly after I graduated from the University of Virginia. I was given a direct commission in the US Navy Civil Engineer Corps (CEC); that is, I did not go through Reserve Officer Training Corps (ROTC) or Officer Candidate School (OCS) to secure a commission, because I already had my "Navy trade" (I was an engineer). For those who do not know what the CEC does, I recommend the old John Wayne movie, The Fighting Seabees, which is still used as a training film at CEC Officers' School. I served three years on active duty and multiple years in the reserves, several of them with a Reserve Naval Mobile Construction Battalion (RNMCB).



I should explain that, at the time I was in an RNCMB, women were not, technically, supposed to have those jobs. Women, in fact, were not supposed to be in anything like a "combatant unit," despite the fact that in war, bullets do not discriminate and typically, the military wants to use the very best people they have for the job, regardless of gender. My sister and I were technically assigned to the staff of a Naval Construction Regiment (in paper-pushing jobs), while in reality—and cleverly—we were "cross-assigned" to naval construction battalions by a reserve Navy Captain who believed in bending the rules in a good cause. I should also add that the men we actually served with in the RNCMBs were almost universally supportive, respectful, and treated us fair and square, which is all that we wanted: a chance to prove ourselves as leaders.



I learned an important life lesson vicariously from my sister in the course of a field exercise she participated in with her RNMCB. Field exercises typically are designed to help you prepare for war by having "attackers" and "defenders" execute a battle plan. There are—also, typically—rules of engagement about what is allowed and not allowed in these field exercises.



My sister had done a lot of the work to set up the field exercise, which included active duty members of the US Marine Corps as the attackers. I believe there may have been an element of "active duty" vs. "reservists"—aka "weekend warriors"—rivalry going on, as well as the fact that many men do not want to lose to women—in anything. All this notwithstanding, my sister managed to—I believe the correct word is "annihilate"—members of the US Marine Corps in this field exercise, in no small part because she violated the rules of engagement and smuggled in night vision scopes, which were relatively new and just beginning to be fielded. In short, she could see in the dark and the Marines could not. They targeted her unit, perhaps to "teach the female officer a lesson," and she used that against them. As she says to this day when I remind her of the story, "Rules? There are no rules. This is war!" The Romans would say: Sid sibi pacem, para bellum (If you would have peace, prepare for war). The Marines may have smarted in losing to a bunch of reserve Seabees, but they will not underestimate them again, nor did anybody underestimate my sister again. (I had learned at the ripe old age of 5 not to underestimate my sister.) I venture to say that underestimating the enemy is a cardinal sin in war. She taught a number of people a very good lesson, indeed.



I was reminded of this incident recently when a colleague at Oracle I respect immensely wanted my ethical hacking team to do a security assessment of his product. He was explaining the functionality the product is designed to support, and initially requested that my team conduct their ethical hack within the boundaries of what the product was supposed to do. I agree that testing "does the product perform within configured boundaries and configured security policies as applicable" was an important part of the ethical hack. However, "no holds barred, throw the rule book out" hacking I also wanted to be part of this assessment, since unethical hackers aren't going to care (or, as we say in security parlance, "give a rat's tuches") what our stated security policies are. Furthermore, our customer may not always configure or use the product within the bounds of our assumptions. As my sister would say, "Rules? There are no rules! This is war!" Field exercises and "ethical hacks" are good opportunities to prepare for the worst in a controlled environment, but to get the most out of them, you need to consider what happens if the rule book is not followed by a real opponent, which it almost surely will not be.



One individual who looms large among those who influenced me is a not-so-famous woman who probably did more than anybody to open up opportunities for women in the Navy, CAPT Winnie Q. Collins. When Winnie joined the Navy in WWII as an officer, she was among the first to do so. She was among the first group of women to be stationed in Pearl Harbor; she designed training programs for other Navy women (even designing women's uniforms, some of which are still worn today and still look great). There was a time when there could only be a single female CAPT in the Navy, and Winnie was it.



Winnie had better sea stories than almost anybody else I knew, like the time she inadvertently blew a kiss to ADM Nimitz (only Winnie could pull that off, I have to say), and the time she met ADM "Bull" Halsey. Winnie pushed the bounds of what women were allowed to do; she did it with style, with diplomacy, but nonetheless, with fortitude and persistence. Years later, when the so-called combat exclusion came down and more opportunities opened for women to be pilots, to be stationed on ships, and other critical jobs in national defense, nobody was more pleased than Winnie and nobody deserved a bigger round of applause for working for decades to see it happen. Winnie died several years ago and was buried at Arlington Cemetery after a military funeral with full honors, which she would have loved, and which she richly deserved. I appreciate that there were opportunities I never would have had if it were not for her and other "forward-thinkers." I miss her to this day.



One influence I alluded to earlier deserves his own paragraph: my Dad. OK, this is, in a way, a throwaway, because everybody's Dad is a big influence on them (sometimes, alas, a negative one). My father fought in two wars (WWII, where he served in the Pacific Theater with the 20th Air Force in the Marianas and finished the war as a 21-year-old Army Air Corps Captain) and Korea. (He also has great war stories I am still listening to. I only found out a few years ago that he had met both GEN Douglas MacArthur and GEN Curtis LeMay. How cool is that?) He stayed in the Air Force Reserves and retired as a Major General. As I mentioned, he was in civilian life the dean at the US Naval Academy, where he made many positive changes to the academic program. (Any former "boat schoolers" reading this, my dad was the one who instituted the reading of every graduate's name at graduation, not just the honor grads, because he felt every midshipman deserved his or her minute in the sun.) One of my happiest moments in life was the day my dad swore me into the Navy (I still have a picture of the event on my piano: my Dad in his Air Force blues, and me in Navy dress whites, looking as ecstatic as I felt at that moment).



My father is the most high-integrity person I know and his is the standard I try to emulate. As my Mom says, my father has never let her down on an issue of moral principle or integrity: he always does and always has done the right thing. Integrity and honor now seem like "quaint" or even "archaic" concepts in a world where so many operate based on what they can get away with and what everybody else is allegedly getting away with, but my belief is that at the end of the day, all you really have is your honor and integrity to recommend you. (The military, I might add, still values these attributes; consider the motto of West Point: "Duty, Honor, Country" continues to be enshrined upon every heart on the Hudson.)



Integrity I think is particularly important to the practice of security because the consequences for shading the truth can be so drastic. Your job is to provide your very best professional opinion about the state of your product, or your "operational defenses," to the very best of your ability. You can be ignored, or your advice can be overruled (sometimes for good reasons, sometimes for bad reasons), but your job as a security professional is to state the truth as you see it, as best you can. (Putting it differently, do you want your networks to be breached because you "positioned" a hole big enough to drive the QEII through as "flexible security")?



I take it for granted—and I shouldn't—that I work for a company that values those attributes in me and in the other wonderful security professionals I work with (e.g., my peers who look after operational security and physical security—you rock, Todd and Bob!). I feel fortunate that I've never been asked to compromise my integrity for Oracle (one if the biggest reasons I've been here for 17 years).



To this day, when I meet someone who has been in the armed forces, there is a common bond between us. Part of that is due to shared experiences that seem to be the same no matter when or where you served (e.g., the Navy was and is always futzing with the uniforms so you have to buy all new ones—argh!). We now live in an age—unlike, say, the 1940s and 1950s—in which most people have never served in the military and many do not know anyone who has. Frequently, we who have served are asked why we did so ("Why would a smart guy like you go to West Point?" "Why did you join the Navy when you didn't go through ROTC?" "Why did you become a Marine now?") Why, in short, did you do something like this—where your life could be put at risk—when you weren't forced to do so?"



I didn't join the military for the experience, the leadership opportunities, or the life lessons I got that cling to me still, though those are all benefits I continue to appreciate. Freedom isn't free: our history shows that. There are people today who, like the Founding Fathers, still pledge their lives, their fortunes and their sacred honor to defend this country. I joined the Navy because I wanted to serve my country, which has done so much for me, and I wanted to be part of something bigger than myself. I was proud to have served, and I would do it again in a minute. There are lots of flags flying today in the little town in which I live in Idaho, but no fluttering flag has ever meant as much as the ones I saluted when I wore a uniform. If you are a veteran, you will understand, and if you aren't, I can't explain it to you.



In a way, the reason I work in computer security reflects the reasons I joined the military. Much of what I do at Oracle involves working with others in industry, and with those in the government, to try to make security better for everybody. To be part, in short, of something bigger than myself, which involves defending my country—and others—from attackers. I tell the developers I work with that all of our customers have secrets that they are counting on us to help defend, but that some of those secrets are national secrets. And that is the standard of security we must meet: defense of national secrets.



Today is a good day to praise the many not-so-famous men and women who have served in the military, and those who serve today, who continue to believe that freedom is worth defending and worth personal sacrifice. Thank you all.



Ua mau ke ea o ka ‘āina i ka pono. (The life of the land is perpetuated in righteousness.)

—Kamehameha III



Among the men who fought on Iwo Jima, uncommon valor was a common virtue.

—Fleet Admiral Chester W. Nimitz, USN, 16 March 1945.



Random good reads on US military history:



We Were Soldiers Once, and Young by Harold G. Moore

Patton: A Genius for War by Carlo D'Este

American Caesar by William Manchester

Goodbye, Darkness by William Manchester

More than a Uniform: A Navy Woman in a Navy Man's World by Winifred Quick Collins



Really excellent quotes about the US Marines (bless them!): millennium.fortunecity.com/redwood/352/usmc4.htm



For those who have never been, it's well worth a trip to Arlington National Cemetery.



A couple of my favorite places to honor those who served are the War Memorial of the Pacific (the Punchbowl) in Honolulu, Hawai'i, and the USS Arizona Memorial.

July 21, 2006

Don't Build There

I live part time in San Francisco, California and part time in Ketchum, Idaho. It's a great place to live if you love the outdoors, as I do. Ketchum is in the Sawtooth Mountains of Idaho and has great hiking, flyfishing, kayaking, hunting (in season) and skiing (alpine and Nordic). Actually, Ketchum has pretty much everything in the way of outdoor activity but decent surf. (Oh, well.) As an added attraction, Ernest Hemingway is a neighbor. (Well, technically, he is dead, but he is buried right around the corner from me, in the Ketchum Cemetery.)


 


One of the things I love about Sun Valley is that -- unlike a lot of other western ski resorts -- the area is still largely pristine and beautiful. In part, this is due to several city ordinances (specifically, the so-called "Hillside Ordinance") that prohibit people from building monstrously large houses on the hills -- or actually, any houses on any hills -- including the slopes of Sun Valley. You look across the valley at the Sun Valley ski resort and you see ski runs, not big ugly houses. With apologies to Vail and Aspen aficionados, I don't find those areas beautiful, because all I see are big overblown houses on the mountain, not the beauty of the mountain itself. A few got "their dream" at the expense of the view of everyone else that lives there. Not in Idaho!


 


There are multiple such ordinances in Ketchum that not only preclude people from building on the hills and, as we locals say, "ruining the place for everyone else," but that also preclude people from creating hazards or messes that other people will have to clean up. If you can't get an emergency vehicle (like a fire truck) up a hill (because it is too steep), you can't build there. If your property is in an avalanche zone, you can't build there.  The Ketchum Planning and Zoning Commission no longer grants waivers, either, (doubtless because you can't waiver an avalanche after it has happened). Not surprisingly, we don't have problems of people's houses getting wiped out in an avalanche, or cases where a grass fire (and we have them) wipes out someone's house because the fire trucks could not get up the hill. The ordinances are there to preserve life - and the quality of life - in Ketchum.


 


In the technology world, we really don't have any such ordinances. You can build anything however and mostly wherever you want, technologically-speaking. On the one hand, this has given us explosive technology that transforms the way we work and play and brings us a lot of benefits that we get hooked on pretty quickly. (I am what marketers call a "late adopter" of technology. I just bought my first iTune last week and it was an epiphany. You hear a great tune, you can go buy it lickety-split without searching through 25 physical stores to find it. I got a most excellent recording of Mauna Loa -- the one by the Hawaiian Style Band.)


 


On the other hand, because there are no "don't build there" ordinances in the tech world, you just know there are some messes waiting to happen. Avalanches. Brush fires that can't be put out. Things that put other people in harm's way, because someone thought that "a great view" was worth building on no matter what the risk to themselves or to others. 


 


Most developers I work with actually appreciate the "ordinances" Oracle provides in the way of secure coding standards, security release criteria and other "building codes." The purpose of these "ordinances" is to provide a way for developers to be creative without creating a design or "structural defect" that will become an expensive mess to clean up later. That's the point, actually: we don't dream up secure development processes to make development harder, but to make it easier. Just as most contractors or architects would much rather drop by something they've built to admire their handiwork than to "do maintenance" or "fix a problem," most developers would rather work on cool new code than fix bugs in old code. Making it easy for them to code things the right way the first time makes everybody happy, including, of course, the homeowners (our customers), who are much happier living in a house that does what it was designed to do and lasts for years, to mix a metaphor.


 


I once had a discussion with a developer (thankfully, these types of negative conversations are rare) who complained that the secure coding standards we have were "stifling his creativity." I told him that nobody in a business environment has unfettered creativity. Architects, for example, are tremendously creative but only within the bounds of cost, location, customer preferences, structural engineering, and their professional licensing. Oh, and building codes -- including city ordinances. Architects still manage to build stupendously beautiful and creative buildings, within those bounds.


 


Aside: in Hawaiian mythology, major building projects are often ascribed to menehune, little people who are sort of like Hawaiian leprechaun contractors. The menehune could build almost anything overnight, completing their work and vanishing before the sun rose.  Everything from heiaus (temples) to fish ponds have been ascribed to their building prowess. Mythical builders always finish on time and below cost.


 


One of my neighbors in Ketchum built an architecturally impressive house a few years ago (I believe it's been featured in some high end house/garden/"edifice complex" magazine or other.) He chose to build a "statement house" that has a flat roof. Generally speaking, most people don't build flat-roofed houses in ski areas for the reason that, when you get in excess of 250 inches of snow a year, as we do in Ketchum, you want the snow to roll off the roof and not sit there, contributing a heavy load to the structure (lest the roof fail). When the snow starts to melt, you also want the water to drop off the roof, not pool (lest all that pooled water find a way into your house).


 


My neighbor now has severe roof leaks and some structural cracks and it is all I can do not to say, "What were you thinking, building a flat-roofed house in a ski area?" Lest everyone think badly of me for "I-told-you-so-itis," that neighbor has been anything but neighborly in a number of respects. He recently and condescendingly referred to another neighbor's (charming, in my opinion) house as "a teardown rancher," at which point, the second neighbor said, "Yes, but my house doesn't leak, does it?" He has also tried (in a run roughshod sort of way) to get his property rezoned so he can do more things that the city has prohibited people from doing. My schadenfreude in this is that he arrogantly ignored both common sense and conventional wisdom to Make a Statement and is now living with the consequences of New and Cool instead of Tried and True.


 


As a security person, I am sometimes reluctant to embrace the "new and cool" when it does not incorporate a healthy respect for the conventional wisdom of Don't Build There or Don't Built Like That.


 


For example, in a previous life at Oracle, I worked closely with developers who were embracing Internet standards. The average meeting sounded like alphabet soup, with terms like "SSL," "SOAP," "OCSP" and "S-HTTP" being bandied about. I joked that I thought we needed an "ITP story." In fact, I said, we need an "S-ITP" story. "Yes, yes, we need that," said one of the developers. "What is it?" he added. "The Internet Toaster Protocol," I said.


 


Come to find out, there really are people thinking of new and -- dare I say useless -- applications of technology, such as putting household appliances on a network.  These people think that it would be a great idea to have a self-ordering refrigerator. Sensors will determine when your milk is past its sell-by date (doubtless by scanning a frigid RFID tag), and automagically place a Web order with your local store for a fresh quart or two. Someone is probably working on BPEL implementation of the sour milk detection protocol as I write this.  Personally, I think the low tech approach works perfectly well, has fewer moving parts and doesn't require upgrades: you open the refrigerator, sniff the milk, toss it if it smells funny, and write a reminder note on the refrigerator to get milk.  Other than not being able to read your own writing to decipher that "qt cowjuice" means "buy milk," there are few things that can go wrong here.


 


I realize that I shouldn't rain on everyone's parade just because I am a techno-Luddite, or automatically dismiss the "new and improved ITP" just because I didn't think of it first.  However, as a security professional, I am almost always skeptical of the "newer and more technical is always better" mentality, because I see so few people who consistently either perform a business analysis of new vs. old or have adequate consideration of security risks in the new. As far as business analysis goes, a prudent consideration of New and Cool would be determining whether the net present value of New and Cool Technology is substantially better than that of Old Luddite Way. In short, what's the total cost of doing it the new way, and is it better enough to be worth doing?  (For example, I think my implementation of the spoiled milk protocol works acceptably well and cheaply that replacing it with BPEL and RFID seems pointless.)


 


Alas, there is often no security analysis in the rush to new and cool, either. Should we proceed to "ITP-enable" our homes, I fear that someday we will have headlines that a family of four starved to death because they forgot the password for the refrigerator. Or that some neighborhood kid will hack into your kitchen and revoke your bagel privileges from the toaster. Or, the unkindest cut of all to a confirmed morning-challenged person like me, "You can't get coffee; the network is down due to a virus." In truth, I don't fear technology, but I do resist "technology in search of a problem to solve," that takes what is simple, low tech, cheap, and works well, and makes it complex, overly technical, expensive and buggy.  And -- most importantly for a security weenie like me -- creates unacceptable security risks where there were none before. (It's not that no risk is always a good thing, either. The same business school class where I learned about Net Present Value also emphasized that business is about risks and returns. No risk = no return. Business is about assuming  (taking) acceptable risk, including acceptable security risk.


 


My hope is to strike the right balance in all that we do -- coding standards, training, tools, secure development processes -- between preventing catastrophe and enabling "award-winning design," all with a healthy dose of common sense. There is a happy tension between having enough "structure" that people do not hang themselves, and so much structure that you do indeed stifle creativity and prevent progress. Ultimately, none of us want to still be living in caves just because that was good enough for Mr. and Mrs. Ugg several thousand years ago (though in Idaho, people do like backcountry skiing out to yurts, which are pretty much like canvas caves -- go figure). By the same token, I want developers to be able and willing to recognize when not to do something at all, because the risks -- in particular, the security risks -- are disproportionate to the returns and are not mitigateable.


 


If I had to sum up the importance of "ordinances" in keeping people on the right track, this would be it:


 


"Therefore everyone who hears these words of mine and puts them into practice is like a wise man who built his house on the rock. The rain came down, the streams rose, and the winds blew and beat against that house; yet it did not fall, because it had its foundation on the rock. But everyone who hears these words of mine and does not put them into practice is like a foolish man who built his house on sand. The rain came down, the streams rose, and the winds blew and beat against that house, and it fell with a great crash." Matthew 7:24-27


 


In other words: "Sometimes, you just shouldn't build there."


 


For more information:


 


Sun Valley (Note the picture of the mountain at the top -- no big, overblown houses on the hill!)


http://www.sunvalleyonline.com/


 


For information about backcountry skiing (yurt skiing) in the Sawtooth Mountains:


http://sawtoothguides.com/yurt.html


 


Read more about menehune at http://www.mythicalrealm.com/creatures/menehune.html


 


Lyrics of Moana Loa at:


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


 


My favorite book by Ernest Hemingway is probably A Moveable Feast (OK, I know it's not one of his macho books, but if you have ever been to Paris, you will know exactly where he is standing when he describes some of the views. If he didn't spend so much time sniping at F. Scott Fitzgerald, it would be an even better book.)

About July 2006

This page contains all entries posted to Mary Ann Davidson Blog in July 2006. They are listed from oldest to newest.

June 2006 is the previous archive.

August 2006 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type and Oracle