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.)

Comments:

Hello Mary Ann! I discovered your blog a couple of weeks ago. I enjoyed reading the above and about surfing in HI. You know, people have been killed by their garage door openers, (reference your line about the hazards of possible web enabled house above). There is a place for everything, including security or the lack thereof. My brother is visiting me in the City (from a very small town in NH). When I get home in the evening the door is always unlocked. He just is not in the habit of locking doors. So I take my chances leaving him there the last couple of days... I warned him of the risks. The odds are it will work out, and I'm ok with that, for the few days of his visit. -- Fred

Posted by Fred Vogt on July 28, 2006 at 12:27 AM PDT #

Came across your blog when I googled Housman's poem "The Oracle" (The Spartans on the seawet rocks etc). Amazed that someone knows so much about computer stuff and likes Housman. And "Law and Order" too! I am in awe of your dedication to reading and to Hawaiian. BUT I think you tend to ignore the West European/African theatre in WW2: I find the Battle of Britain, El-Alamein, D-Day and The Ardennes more interesting than the other major events of that war. And I apologize for hinting that your Latin may be rusty: it's "Si vis pacem...". (OCR error?) Beannacht De ort. Maurice Neligan

Posted by M Neligan on January 12, 2010 at 04:00 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

bocadmin_ww

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today