I also have excellent early warning systems in my backyard in Idaho. Specifically, the critters I support on my property are all – individually and collectively – quite good at alerting me when Something Is Happening. Birds, pine squirrels (more on them later) and – last but not least – my dog Thunder are all very good alarm system proxies. It took me a couple of years living away from large urban enclaves to learn how to “read” nature’s cues. Now, my ears have been retrained to the point that I listen to the birds, squirrels and my dog when they are trying to tell me something. I claim no special nature skills but I like to think that family genes (my grandfather was and my father is a consummate woodsman after years of hunting) are asserting themselves.

When I sit out in my backyard and hear the “chit-chit-chit-chit” of a pine squirrel, I know that it means “intruder at twelve o’clock.” Pine squirrels are really noisy, and thus very good at telling you when somebody or something is coming, at least 6 trees away from the action (and yes, I can tell the difference between pine squirrel alarms and pine squirrel pickup lines). The birds also get noisier, and in a different way, when there is a (fox, dog, cat, coyote, other) prowling through the sage brush that I can’t see, but I know is there because the birds have gone to Defcon 4. Thunder also has entirely different barks for “someone’s coming up the driveway I know,” “someone’s coming up the driveway I don’t know” and “a fox just ran across the porch and is hightailing it for the back yard.” The prize for alarm specificity goes to my sister’s miniature schnauzer Sneakers, whose bark (in increasing order of frenzy) refers to: a) a jogger b) a squirrel c) a fox d) the neighbor’s white dog e) deer or f) lots of deer.

My other “tenants” (the family of white-throated swifts that nests under my peaked roof) don’t warn of “incoming,” but they keep pests out of my yard. Late afternoon, there are eight to ten of them in aerial dogfights with any flying insects that darken my airspace. Watching the sparrows turn, bank, and maneuver is just about as big a thrill as watching the Blue Angels. I like to grab a glass of wine at the end of the workday, go outside and watch the swifts on evening pest patrol. It’s very soothing and lends new meaning to the phrase, “running the debugger.”

One of the things I have been doing some thinking and speaking about is the idea of synthesis. More specifically, the lessons we can learn in IT security from other disciplines, such as business, economics, history (especially military history and strategy) and biology. I confess that I felt a little nervous speaking on this topic at a university recently, because I figured any one of the professors or graduate students on the audience knew more than I did about IT security – certainly on the nerd level. On the other hand, they are all in the perfect environment to think differently about their profession via synthesis: all they have to do is walk across the quad to talk to another department. In fact, a professor of biology I met said that at her university, there was a tight synthesis between the computer science and biology departments. Each department had realized that they were kissin’ cousins, so to speak.

Of course, we IT security weenies know this intuitively. We speak of computer “viruses” because they “infect” vulnerable hosts unless the host has been “inoculated” against them. Some of the research going on focuses on making hosts just different enough that viruses are not able to infect all of them. Mirroring the arms race that biological hosts and opportunistic germs engage in, virus makers try to find ways to defeat anti-virus defenses by disguising their nasty, germy little packages so they aren’t recognized by the defense systems – just like you can’t be inoculated against the common cold because there are so many slightly different rhinoviruses, as I know all too well because I have spent two weeks and then some getting rid of a particularly rotten summer cold. And, just as in biology, computer viruses do not want to kill the host, but to use it.

A few years ago, there was an interesting paper positing that a software monoculture was a national security risk. That is, a lack of “biological diversity” in enterprises makes those enterprises more vulnerable to a cyber plague that affects the entire enterprise, not just a portion of it (just like the Irish potato famine wiped out millions of people because the strain of potatoes grown in Ireland was not resistant to the potato blight). Note that there is some happy medium here. If it is true that running only one kind of software may make the enterprise more susceptible to a cyber plague, it’s also true that running one of every type of application, database, operating system, and so on is neither economical nor easily secured, as one would have to be an expert in absolutely everything to manage such a system.

We know that biological entities use trickery to survive, thrive and propagate. Moths disguise themselves as other, more toxic moths to fool predatory birds. (What is a honey pot but a technical equivalent of a biological system designed to attract predators?)

I have read a couple of fascinating books on how companies are modifying plants to be resistant to some diseases. This is not without risk or without controversy. The University of Hawai’i, for example, just implemented a five-year ban on genetic modification of kalo (taro), in part, because for Hawaiians, kalo is not just a plant but part of their culture. I also note that genetic modification does not necessarily deliver all the promises claimed by the proponents (e.g., the so-called “golden rice,” genetically engineered to have Vitamin A in it, doesn’t have enough in it to do much good. More specifically, according to one book I read, you’d have to eat 12 pounds of the rice a day to get the minimum daily requirement and who eats 12 pounds of rice a day?)

I’ve had the same discussions over products that claim “native protection” against classes of attacks (like SQL injection – which I believe is doable) and that do “virtual patching” (which I don’t believe all the claims for). For those who are not up on “virtual patching,” it is the idea that you can replicate in a gatekeeper/cyber-Doberman function the exact equivalent of what a patch does. You can’t. You can (in some cases) have a good workaround, or you can prevent a specific exploit or exploits, which may buy customers needed time to patch. That is very useful, I agree. Unfortunately, “virtual patch” as a term is indiscriminate: “preventing known exploits” is more accurate but doesn’t reel in the gullible, so we have “virtual patching” as an industry term and not “can’t replace patching but gives you some protection, maybe, so might be worth a shot.” To my point, shilling “virtual patching” as a replacement for patching is as irresponsible and potentially harmful to customers as parents skipping inoculations for DPT is to their children: someone, some time is going to get hit by something horrible.

As I look at my backyard, I wonder what bright technoid will look at a white-throated swift and think, “I can build that. I can build a cyber patrolling predator so swift (no pun intended) and agile that it can dive bomb pests before they reach my cyberbackyard.” Instead of staying on the telephone wire and hoping a pest drives by (like static defenses people deploy now), the cyber swifts could circulate freely on perpetual pest patrol. I think about early warning systems as sophisticated, yet recognizable as my sister’s Schnauzer or the neighborhood pine squirrels. One frenzied bark or one “chit-chit-chit” and I have a pretty good idea what is out there and how worried I should be about it. I wish most of the cyber defenses we had now were as good, as recognizable, as accurate and descriptive. Of course, foxes, coyotes and cats aren’t constantly changing their guise to be unrecognizable to Neighborhood Crime Stopper Pine Squirrels, either.

There are other disciplines that have applicability to the world of IT security, if we choose to explore them. For example, when I was in graduate business school, one of the financial market theories I learned pertained to whether companies should diversify given that investors can do it themselves. For example, conglomerates (companies that have a lot of diverse, not-necessarily-complementary lines of business), the theory goes, are not necessarily valued correctly by the marketplace. And in fact, since investors can diversify their own investments (by buying, say, automobile stock and pharmaceutical company stock separately, if that’s what they want to own), there is no reason – per se – for conglomerates to have multiple lines of disparate businesses. The big idea then (and now to a certain extent) is to focus on core competencies (we see this today in discussions about outsourcing or software as a service: if IT is not a core competency, why do it yourself?)

A number of these business trends/theories, for better or worse and sometimes both, are extended to the global marketplace. For example, the idea that if they can produce sugar more cheaply in Foobaria, then the Snafu Republic should not subsidize their domestic sugar farmers but should happily import sugar from Foobaria. Over time, the Snafu Republic’s farmers will find something else to grow that they can grow better, cheaper or faster than Foobaria (or another country). (Note: You may be less enthused about this idea if you are a sugar farmer* in Foobaria than a policy wonk in Foobaria, because no policy wonk’s job has ever moved overseas that I know of.)

Another argument, more along the lines of industrial policy, is that the people of the Snafu Republic – instead of being subsistence farmers, barely eking out enough food to feed their families – should go work in factories or someplace that will give them a higher wage so they can buy food (and more besides). In a happy dappy world, everyone (or every country) will focus on his or its core competencies and outsource everything else. Globalization facilitates everyone doing what he does best and the rising tide lifts all economies.

I am not here to argue for or against globalization as a general policy or construct (it’s a lot more complicated than one can describe in a blog entry and I think it is dangerous to reduce complex ideas to sound bytes). But I do note that there are a number of interesting – if disturbing – discussions taking place recently about the limits of globalization as a result of spiraling food prices. Food prices, of course, are spiraling for a number of reasons: increased transportation costs, the “crowding out” effect of biofuels, higher demand for high quality food as a result of growing economies, crop failures in some key areas, and so on.

Some countries have acted to ban exports of key staples (rice, for example), wanting to ensure that they can feed their own people. As a result, have-not countries are potentially rethinking that policy that said “get the subsistence farmers into higher wage jobs,” because at least a subsistence farmer might have been able to feed his own family. If you can no longer import food because exporters hoard it, you can’t always eat what the factory is producing unless they are refining sugar. You can eat potato chips but not microchips.

In short, we’ve recently had a lesson that the theory of “everyone (read “every country”) does what it does best, and we all trade for what ever else we want” does not necessarily work when you have a shock to the system, like the transportation costs going through the roof, a result of which is that sugar schlepped from Foobaria is now really, really expensive to Snafuians. It also assumes that no country is ever going to use exports as a competitive weapon. Not only is that assumption a bigger stretch than most economists typically posit (“investors are rational” – they aren’t – otherwise how we do explain how breakfast cereal portal companies got funded in the DotCom days?), but we know from history it is not true. It’s never been true, in fact.

The second mistake a lot of policy wonks make is assuming peace, love and happiness in perpetuity. That’s not true, either. Natural resources such as food water, minerals, spices (yes, spices – salt and cloves being two that immediately come to mind – the British empire enforced a monopoly on salt within their empire, and the Portuguese dominated the spice trade for years) are often used as competitive weapons and the fight over them causes wars. Japan (prior to World War II) felt that they could never be a great empire without controlling their own supply of key resources and a proximate trigger of the Pacific War was the US cutting off the supply of scrap metal to Japan. Japan did not go on a territory-acquiring binge just to have more places for rice paddies, but to acquire natural resources that went with the territory. (And ultimately they lost the war because the US destroyed so much of their merchant shipping that they could no longer ship oil to where they needed it – their ships and planes.)

What’s the security issue? The security issue is that people need to think about their supply chain when formulating national security policies. Where are food, water, energy, spare parts, computer software and hardware coming from? Are any of those critical to national security, to the point where we need multiple suppliers or a “home grown” supplier because it is in one’s national security interests to do so? (For example, the Defense Science Board looked at this issue in relation to having a Trusted Foundry Program – domestic suppliers of integrated circuits for critical defense applications.) Do we actually trust non-domestic suppliers? (News flash: yes, other nation states would, too act to put malware or backdoors in software. A shock, I know, but some countries do act to advance their national interests at the expense of – gasp, horror – other nations. Been going on as long as recorded history.)

We should assume that this is happening and deal with it instead of worrying about Hurting Other Country’s Feelings by calling them on it (the international relations equivalent of telling a country We Are On To You, Knock That &^^%$ Off Right This Minute). I recently participated in a meeting where the debate was whether the group should issue guidance on how to protect your electronics (e.g., cel phone, laptop) when you travel overseas from being co-opted by Bad Guys (bad guys here could be bad guys working for the foreign government). The guidance was all good guidance and not aimed at any country in particular, but the discussion devolved to topics as diverse as “shouldn’t the State Department be the one issuing this guidance?” and “what are the political issues around upsetting some country or another if this guidance goes out?”

(It almost boggles the mind. We know this is happening, so why are people worried about making any country already engaged in industrial espionage, breaking into critical infrastructure and so on Feel Bad About It? It’s like wondering if the grizzly bear had a bad childhood as he is gnawing on your leg. Do I really care if you were an unwanted cub? Stop chewing on my leg!)

In short, the theory of competitive advantage as applied to nation-states sounds great on paper, and may even work great to a point, but it does not take national security needs into account. A nation that is dependent upon others for key materials – like spare parts for their aircraft or microchips or food – can easily be at the mercy of others unless they have an alternate supply (and in fact, a secure supply).

I am not advocating buying everything from inside one country or (getting back to a corporate example) avoiding outsourcing at all cost. Rather, the issue is that while you can outsource services and offshore production/services/sourcing, you can't outsource risk. Even financial markets tell us that you can diversify some kinds of risks, but not market risk – the risk that the entire market will tank. For example, I “outsource” medical care in that I go to see a doctor regularly since I am not an MD. However, I have a responsibility to take care of myself (e.g., to avoid high risk behaviors that are potentially damaging to my health like excessive drinking, using illegal drugs or abusing legal ones). I can’t outsource that risk and I can’t pass along 100% of my health responsibility to a doctor.

Accordingly, whether you are a company looking at service or product providers, or a nation-state contemplating industrial policy, you need to consider risk with steely-eyed objectivity and act appropriately. You could even say that, while there is no one easy set of answers, a non-exhaustive list of potential solutions includes: thinking about country of origin in light of political, social and economic factors, as well as the state of law and law enforcement in the country, using proven suppliers; keeping better handles on your supply chain; keeping attuned to political and governmental actions in countries where you operate; and so on. Hoping geopolitical or business conditions never change, and that everyone you deal with in business has the ethics of the Boy Scouts is not risk management or even optimism, it’s fantasy.

I have had many occasions recently to recount – as a cautionary tale – the story of Wake Island’s defenders in December 1941, one of many fine moments in the history of the US Marine Corps. The Marines managed to sink a Japanese ship from a shore battery (yes, really) but ultimately, the Japanese prevailed. Among other ironies, where did the metal come from for the armaments the Japanese used to shell the shore installations on Wake Island? Scrap metal the US had sold to Japan. If we need reminding, the lesson is that you should never, ever, ever arm your enemies.

* Yes, I realize you don’t actually grow sugar but something sugar is refined from, like sugar beets, sugar cane, even corn (high fructose corn syrup).

For more information:

Book(s) of the Week:

The Omnivore’s Dilemma is one of the most thoughtful and thought-provoking books about food, where it comes from and the implications of how your food is grown. It will change the way you look at what’s on your plate. It’s well researched and yet deeply personal. The second, The Botany of Desire, is really fascinating look at four plants and their impact on the world. The ethical implications of “licensing plants” alone are worth the read (yes, the potato is one of the four plants).

You can find both of them and other works by Michael Pollan at:

http://www.amazon.com/exec/obidos/search-handle-url?%5Fencoding=UTF8&search-type=ss&index=books&field-author=Michael%20Pollan

A great book on the defense of Wake Island is Given Up For Dead:

http://www.amazon.com/Given-Up-Dead-Americas-Heroic/dp/0553803026

A book on salt that includes a discussion of the British empire’s inter-empire monopoly on salt: Salt: A World History by Mark Kurlansky:

http://www.amazon.com/Salt-World-History-Mark-Kurlansky/dp/0142001619/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1216764946&sr=1-1

More on the Salt Tax:

http://thenagain.info/webchron/India/SaltMarch.html

A book about the history of the spice trade (who would think nations could be so combative over cloves?) is The Scents of Eden: A History of the Spice Trade:

http://www.amazon.com/gp/product/1568362498

A web site on Idaho birds:

http://www.idahobirds.net/

And a picture of the white-throated swift:

http://identify.whatbird.com/obj/187/_/White-throated_Swift.aspx

http://www.birds.cornell.edu/AllAboutBirds/BirdGuide/White-throated_Swift_dtl.html

About the Trusted Foundry Program:

http://www.manufacturingnews.com/news/05/0422/art1.html

The original paper on software monoculture that created such a stir

http://www.ccianet.org/papers/cyberinsecurity.pdf

A really (really, really) good book on issues around genetic modification of food (it mentions the hubbub over kalo (taro)) is Uncertain Peril: Genetic Engineering and the Future of Seeds by Claire Hope Cummings:

http://www.amazon.com/Uncertain-Peril-Genetic-Engineering-Future/dp/0807085804/ref=sr_1_36?ie=UTF8&s=books&qid=1216757776&sr=1-36

More on the genetic modification of kalo (taro):

http://news.moneycentral.msn.com/provider/providerarticle.aspx?feed=AP&date=20080407&id=4162601

Absolutely nothing to do with any of the above topics, but a great video of one of my favorite Hawaiian groups (‘Ike Pono) doing one of my favorite songs (Ua Noho Au A Kupa). It is just really happy music:

http://www.youtube.com/watch?v=nLqNn0CzJ5o

If that doesn’t make you want to hula, there is no hope for you.

OK, and Bobby Moderow, Jr. of Moanalua doing "Koke’e" (which I just love):

http://www.youtube.com/watch?v=lFDdAOys7PQ

At any rate, global warming is nowhere in evidence in Idaho. It was a record cold winter and an above average snow pack; we were still getting snow flurries as late as May 20th. The rivers are so full from runoff that the outfitters (river raft guides) are having their best season in years. Technically, you can still ski in the backcountry if you are willing to climb for the thrill of doing so. Needless to say, spring has also been late: my lilacs have only just popped, though here we are in late June.

It may seem strange to be talking about Nordic skiing instead of, say, a summer sport like mountain biking but a) I don’t know anybody who has ended up in the emergency room from Nordic skiing (whereas I know a lot of post-traction mountain bikers) and b) if you aren’t doing your sport, and you are serious about it, you are always training or thinking about what you can do to improve.

I switched from “traditional” Nordic skiing to “skate skiing” a few years ago, mostly to keep up with my Siberian husky. For those who are not Nordic (aka cross-country) skiing fiends, if you go out on a Nordic trail, they are often groomed so that both skate skiers and traditional Nordic skiers can use the same trail. Special snow cats cut grooves in the snow so that the traditional (aka “kick and glide”) Nordic skiers can move easily. The snow cats also flatten the trail so that we skate skiers can glide merrily along (passing the generally slower traditional Nordic skiers). I like skate skiing because it is fast and more aerobic than traditional Nordic skiing and because on a good day, it is like surfing a long board. (Glide: it’s all about the glide.)

Nordic skiing, especially skate skiing, is not about being the strongest or the even the fastest skier – it’s about technique. Most particularly, it is about efficiency. The more distance you can travel with the least effort, the longer you can go. Endurance is important, of course, but endurance is facilitated by good technique. For example, an extra 2 inches in your glide per step adds up over the 5K, 10K, or 15K you are out there. If you cover the same territory with 500 fewer “steps” than your equally fit competitor, you win. It’s the skiing equivalent of “do more with less.” (Only in Nordic skiing, you actually can do more with less; in fact, it is preferable.)

If you love to ski, as I do, you get good at learning not only ways to be more efficient as you ski (lengthen that glide!) but ways to “cheat” and rest (instead of powering through every step). The more efficient you are, the longer you can stay out on a beautiful day when the sky is slate gray, the snow covers all the hills, and the only spot of color is the burnt orange of dormant Arctic willows awaiting spring.

One of the ways I cheat is to use the traditional Nordic ruts when I am skate skiing. That is, when my legs get tired and I don’t feel like skating, I get in the ruts and push myself along, especially when going downhill – it is easier than skating. More control, less effort, your upper body does all the work and your legs just – rest. To be honest, my regular “workout run” in winter is between the 7K and 11K markers on the Harriman Trail. On the way back, it is almost all downhill so I get in the ruts and pole myself along. Whee!

In short, ruts are good. Ruts are your friends. Ruts help you go farther and faster if you use them properly: to rest, glide and do the distance the easy way instead of the hard way.

Now, the idea of ruts being good goes against received wisdom. Most people use ruts in the pejorative sense. For example, “I’m in a rut.” My is in a rut. If you think about it, “in a rut” in some cases is just a negative spin on “in the groove.” Surfers would say, “I got it wired.” “Got it wired” is surf lingo for knowing a surf spot really well: whether the waves breaks best on a high or low tide (and on what swell direction), and where the strike zone is: where, exactly the wave is going to break, so you know where to sit. The surfer who has it wired can (all things being equal) catch the most waves with the least amount of work.

Even though “ruts” can make things easy, even a generally useful rut can in some cases hold you back (hence, the expression “being in a rut”). For example, I can do the same 8K loop (from the 7K to the 11K marker on the Harriman Trail and back) and I did it often this winter. However, even if the terrain is the same, it is sometimes useful to ski from the 11K marker to the 7K marker and back. Why? Because I am skiing downhill on the way out and uphill on the way back. Which means I am pushing myself when I am tired, instead of coasting when I am tired. And I build endurance by “getting out of the ruts” literally, since I can’t use them going uphill. Getting out of your ruts from time to time is very useful. Even a good rut can hold you back.

One of the personal rut-breaking moments I have experienced lately came courtesy of a good friend who – like me – shares a deep love for nā mea ‘apau Hawai’i (all things Hawaiian). We like to get together and “talk story.” On one recent such occasions, Palani gave me an eye-opening rut buster. He noticed that, at a conference we had both attended, I was besieged by people wanting “just a minute of my time to talk about X.” Palani told me he thought I had an ‘opihi problem. I laughed because I knew what ‘opihi are. They are mollusks: limpets, actually. More specifically, ‘opihi are opportunistic mollusks – they wait until a moving object goes by in the water, they latch onto it, and can only be removed with a crowbar. (They are actually considered a delicacy by Hawaiians and nice lū’au food.)

After I was done laughing myself sick, I realized that Palani had highlighted A Truth. The world is full of people who want to “network” (which actually is a noun, but ‘opihi use it as a verb) where the specific definition of “network” means “asking for a favor that will be a lot of work for the askee, not taking no for an answer and then sucking all the oxygen out of the room, leaving the askee gasping for air.”

The Truth is that one’s reward for being helpful is too often a big ‘opihi infestation. I note emphatically that helping a friend through a bad period (e.g., dissolving marriage, health crisis) does not fall into the categorization of “‘opihi infestation.” One of the blessings of friendship includes “bearing one another’s burdens.” You do that gladly for people you love. Neither does being helpful and kind when you can (also known as “living aloha”) count toward becoming a future member of ‘Opihi Anonymous.

That said, after my discussion with Palani, I started thinking about how my tendency to be helpful had allowed a lot of ‘opihi to barnacle my ride, to the point that things I want to do get pushed aside to make room for more ‘opihi. I found myself becoming quite cranky, and whose fault was it, really? I should have painted myself with ‘opihi repellant and sailed on by those opportunistic mollusks.

For example, recently, an acquaintance asked me for a favor that was not in my professional area of expertise. I said I’d pass his interest in FOO along to someone I know (BAR) who might be able to help him (and I was at a meeting with BAR a few weeks ago so it was a convenient discussion to have). What was a favor – and a stretch for me – turned into “I really need you to do this because it is my PhD dissertation and I need people to fill out my questionnaire.” (“Gee, maybe you should have picked a research topic that was not so difficult to get people to work with you on. And did I mention for the 15th time that This is Not My Area of Expertise?”) I got emails, I got phone calls, I not nagged on weekends, until (fairly quickly) I said, “I will do one thing for you, then you are on your own.”

Most of us (me included) are willing to be helpful to others if we can. There is a big difference between doing a favor as you can, and allowing ‘opihi to attach to your ship as you sail by, thereby reducing your aerodynamics, clogging your intake valves and requiring expensive ‘opihi removal services. It crowds out other things you could be doing that would be more productive, bring you more pleasure or that would lengthen your stride, so to speak. To quote my buddy Palani, “Eh Sistah, No Mo’ ‘Opihi.” * I am getting out of the ‘opihi rut and not feeling guilty about it one li’ili’i (eensy) bit.

My second example is a “rut breaker” who changed not only his sphere of influence but whose ideas percolated into other arenas. In fact, he is one of the most influential people you’ve probably never heard of. His name was John Boyd and he changed the art of war.

Major John Boyd was an Air Force fighter pilot, whose energy maneuverability (E-M) theory encapsulated how and why fighter pilots win in aerial combat. His street creds came from his days as “40 second Boyd,” whose bet that he could defeat any opponent in aerial combat in 40 seconds or less went uncollected by any and all challengers. He was also - and infamously - a pain in the ‘ōkole of the United States Air Force, who thought they could banish Boyd to the basement of the Pentagon, only to have him become an insistent gadfly in the procurement arena. In part, Boyd’s intransigence resulted from his desire to have his E-M knowledge manifested in actual aircraft designs (e.g., the F-15).

What Boyd came up with (to simplify his legacy) is called the OODA loop. His idea was that what makes one warrior prevail over another in a dogfight – or, by extension – one group of warriors prevail over another – is agility. He categorized agility via the acronym by which his work is recognized: OODA – observe, orient, decide and act. His theory, briefly, is that one of the ways you can prevail against an enemy is to get within his decision-making and response capability. Getting inside the enemy’s OODA loop disrupts his ability to react and gives you the advantage. (His work on quantifying and describing qualities of agility were also embedded within the design for the F-15 which he fought for relentlessly.)

Boyd’s theories have been tremendously influential and not just within the Air Force (to whom he – unfortunately – remained a problem child and who therefore did not really accord Boyd the recognition he deserved). Marines love him, to the point that when he died and was buried in Arlington Cemetery, the story goes that nobody from the Air Force showed up, but the Marines did. One of them took the globe-and-anchor device off his uniform and placed it on Boyd’s grave (probably the highest tribute a Marine can pay to another individual). Boyd’s theories were applied to battlefield maneuvers in the first Gulf War with spectacular results. They’ve also been applied to the business world.

John Boyd’s work was and is a rut-breaker – some of the most innovative and influential ideas to change the art of war. If and as applied to security, it could also be a rut breaker in ways I leave it to better minds than mine to contemplate. For example, suppose system components were clever enough to dynamically reconfigure themselves under attack? More specifically, what if networks could self defend by “observing” what was happening on the network, “orienting” themselves in the larger network battle space “deciding” on a defensive posture, and “adapting” to a different configuration (that is, get “inside” an attackers’ OODA loop)? Static defenses are hard-pressed to prevail over dynamic ones, and as we know, many attacks are already automated and dynamic. Attackers often win because they are inside the enterprise’s OODA loop so that – it stands to reason - static defenses (and for that matter, passive defenses) will never prevail. If it is not already obvious, cyberspace is a battlefield, and no battle is ever won on the defensive.

I recently did a couple of talks at a university, one of which focused on the idea of synthesis: looking for templates or knowledge that can be applied to cybersecurity in other disciplines (economics, history, biology and military strategy were several areas I mentioned). Looking for answers in other disciplines is, paradoxically, both embracing a rut, because you realize there are very few truly “new” problems (“There is nothing new under the sun” – Ecclesiastes) and busting the security rut, by expanding the venues in which we look for answers.

My last rut example is more personal. I went to Hawai’i for two weeks to surf and recharge. My ruts included surfing my favorite surf break (“Pops”) every day but one, to listening to my new favorite Hawaiian music group (Maunalua - who just won another Nā Hōkū (Hawaiian music) award for best group) no less than six times when I was there. Bless their hearts, they played "Koke’e" for me every evening, too. I could go someplace else, but no place else relaxes or recharges me quite the way Hawai’i does. Just like gliding downhill on those winter ski ruts, I am in the groove, joyful and renewed.

*This is pidgin, not Hawaiian. You will hear both in Hawai’i and both are da kine.

For more information:

More on ‘opihi:

http://hawaii.gov/dlnr/dar/pubs/sawcs/mi_limpets.pdf

There’s a Hawaiian music group called the ‘Opihi Pickers:

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

More on Maunalua (support Hawaiian music!):

http://www.maunalua.com

You can find "Koke’e" recorded at:

http://www.mele.com/music/artist/maunalua/ho%60okanaka/

A great book on John Boyd by Robert Coram:

http://www.robertcoram.com/boyd.html

More on Boyd:

http://en.wikipedia.org/wiki/John_Boyd_(military_strategist)

More on OODA loops:

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

Robert Coram has also written another book on Col. Bud Day, the most decorated living veteran and whose story ought to be required reading for every American:

http://www.amazon.com/American-Patriot-Life-Wars-Colonel/dp/0316758477

The incredibly expensive but probably worth it (I have not read it) book about Boyd’s theories:

http://www.amazon.com/Science-Strategy-War-Strategic-History/dp/0415371031

I recently participated in a Defense Science Board study that examined foreign influence over the supply chain of software. The study noted that, even as vendors need worldwide access to technological talent to enable them to create commercial software solutions benefiting the US Department of Defense, there is an increased risk that the supply chain of software may be compromised by adversaries, such as hostile nation states. Working on that task force brought supply chain issues front and center in my thinking for a number of months.

Supply chain security issues are on many people's minds these days.  More and more regulations impact IT operations either directly or indirectly, such as the Sarbanes-Oxley Act, the Gramm-Leach-Bliley Act, the Health Insurance Portability and Accountability Act (HIPAA), various breach disclosure laws such as California SB1386, and information security laws like Minnesota's adoption of some of the payment card industry (PCI) standards. (And these are just the US laws.) Customers are being pressured to establish (from documentation to demonstration) they are "more secure" and are in turn pressuring their supply chain - software vendors -  to prove that the enterprise software they provide is secure. Vendors are being asked everything from "What features and functions do you have to help meet regulatory requirements?" to "How do you embed security within your software development lifecycle?"  This is a good thing, and how markets are supposed to work.

In the vendor community, there is a low rumble of discontent about our supply chain's current lack of a "secure development lifecycle." I'm not talking about other software suppliers (for example, vendors who supply toolkits or components we embed) though at Oracle, we do vet these suppliers' security practices before we incorporate their technologies into our code. 

What I mean by supply chain is the universities who supply CS graduates to IT vendors. There is no "secure development lifecycle" in the vast majority of universities' degree programs - that is, security is not "baked into" graduates of relevant programs (e.g., computer science) throughout their degree programs. And that is a problem, perhaps the problem plaguing the software industry. All the other security remediation taking place in the software supply chain (such as multiple security point solutions, vulnerability analysis services, and patch management offerings) largely stems from the fact that most software was neither designed nor built to be secure. And to that point, developers don't code software from the perspective of an attacker. Many believe security is a task for someone else ("it's behind the firewall so we don't have to worry!"); but their code is a target and will only be more of one in the future.

CS majors graduate from long, labor-intensive degree programs without, in most cases, knowing even first principles of secure coding and secure engineering practice. They are not stupid, but ignorant.  They aren't being taught secure development practice because in many cases, their professors do not know it, or do not know the material well enough to teach it, or do not view it as a priority; I've heard a number of professors admit as much. Also, many professors are tenured and thus non-responsive to market forces. They don't have to change because they have the ultimate job security, which means that many can continue to teach Buggy Whip Design 101 instead of moving into the 21^st century.  I can say this because I spent the first 18 years of my life living in university towns: my dad was a department chair, associate dean, and then dean of the faculty. I think "tenured" was one of the first words I learned to spell.

Last year, I got fed up enough with Oracle having to train otherwise bright and capable CS grads in secure coding 101 that I sent letters to the top 10 or so universities we recruit from (my boss came up with the idea and someone on my team executed on it - teamwork is a wonderful thing). Specifically, we sent the letters to the chairmen of the department of computer science (or equivalent) and copied the deans of the schools with oversight of the CS departments. In the letter, we stated that Oracle expends significant resources training CS graduates in secure coding practices. We described the impact to us and to our customers of avoidable, preventable security defects, and why the insecurity of commercial software is a national security problem. We also pointed out that SANS has developed an assessment for secure coding practice. And we stated that in the future, Oracle would give preference in hiring to those universities that emphasize secure coding practices.

I am sorry to state that only one of those universities we wrote to responded to my letter (specifically, one department chairman responded), and the one that did (while stating that they did have courseware pertaining to security practice) wanted funding from Oracle to develop a more robust class. Having grown up at universities, I know very well that universities as a group tend to be really well endowed. In English, this means they have all the money in the world to do things like "teach better" except that as a group, professors' fortunes rise or fall with getting money to Do More Research (quite often, much of which has already been done before, or better).

While I appreciate the University of X's CS department chairman getting back to me (and the fact that they had at least some material on secure coding practice), I see no reason to pay them to do work they should be doing, anyway. In particular, paying a university to develop a class on secure coding that only they teach is not going to solve this problem. Nor - despite excellent intentions - are the NSA's Centers of Excellence in Information Assurance going to solve the problem.

We need a revolution - an upending of the way we think about security -and that means upsetting the supply chain of software developers.  I suppose I am revolutionary-minded because I am finishing reading a book on the American Revolution (Liberty, by Thomas Fleming), but there is a point beyond which tinkering with existing structures of government is not enough. There is a principle at stake (like "taxation without representation is tyranny").  If the powers that be don't grasp the principle, the only choice is to "secede."  Maybe the principle that I want universities to grasp is the one the Marine Corps has: "Every Marine is a rifleman." Every Marine can fight - they don't "outsource" rifle handling to others if they are attacked. (Imagine how different the IT space would be if every developer thought and coded defensively and every product could self-defend. I bet the average Marine gunny sergeant could whip universities into shape in about 16 weeks or less.)

Like some of the publications circulated by the Sons of Liberty in the buildup to the American Revolution, I found my "letter to universities" idea struck a responsive chord. A fellow vendor asked for a copy of the letter. Someone in a quasi-government organization (who was keenly interested in the assurance problem) wanted a copy of the letter to go back to universities to prove to them that their "customers" needed them to change. Two people armed with my letter is a start, but it's not enough to start a revolution.

Forthwith, I have taken the liberty (after expunging the name of the university to which it was originally addressed) of PDFing one of my letters to universities from last year, and publishing it on the Oracle web site at: http://www.oracle.com/security/docs/mary-ann-letter.pdf

In so doing, I consider this to be both an open letter to my fellow vendors, and an open letter to universities.

To the vendor community, just as customers are demanding more of us in security (and rightly so), we must demand more of our suppliers. It is inefficient and wasteful for each of us to train CS graduates in secure coding practice - yet Oracle and many other vendors expect secure coding practice as part of our development processes (and if we aren't doing that, then we need to do it). More to the point, the cultural transformation - that CS graduates are responsible for the security and safety of the code they write - must happen in universities. Take my letter, modify it as you will, and start holding university CS programs' feet to the fire to improve. To quote Ben Franklin after signing the Declaration of Independence: "We must all hang together, or most assuredly we will all hang separately."

Also, vendors, if you have secure coding class material, work with the organizations that are trying to fix the problem. SANS, for example, is working on material for faculty members to use in teaching secure coding practice (Oracle is participating in this).  The Department of Homeland Security's Software Assurance Forum (next meeting in early May) has people working on a Common Body of Software Knowledge, as well as other training work. As I write this, I am working through the details of getting a tutorial Oracle developed on SQL injection prevention released to universities gratis. Those who have done it tell me that if you make secure coding courseware available, at least some CS professors will teach it.

Vendors can also express their concerns to the Association for Computing Machinery (ACM) - the accreditation body for CS degree programs. (Mahalo nui loa to Scott Charney of Microsoft, who did just that a couple of years ago and got a number of us in industry to sign the letter.) I note that the sooner we can get to a basic secure coding class everyone can use (phase 1), the harder it will be for ACM to refuse to change their accreditation program, especially if enough vendors complain to them. Let's make it easy to say "yes" and hard to say "no."

To universities, I cannot but contrast the education of engineers with that of computer science majors. Engineers know that their work product must above all be safe, secure and reliable. They are trained to think this way (not pawn off "safety" on "testers") and their curricula builds and reinforces the techniques and mindset of safe, secure and reliable product. (A civil engineer who ignores the principles of basic structures - a core course - in an upper level class is not going to graduate, and can't dismiss structures as a "legacy problem.")

Universities, you must start with a basic secure coding/secure development practice class that is required for all CS majors.* You must then revamp the fabric of every single class so that security becomes part and parcel of each class. If a student's "elegant technical solution" in an upper level class is hackable, the student shouldn't get a great grade: in fact, maybe hackable homework should be grounds for failure - kind of like a bridge design that would collapse under loading would get a failing grade in the Civil Engineering Department. I knew a professor at Stanford who routinely had his students "red team" and "blue team" each other's homework (and his class wasn't even a security class). I'd thank him if I could remember his name. Secure development practice needs to be embedded within the fabric of every class, not just in a single class that students file and forget.

Universities, think more broadly about the application of security to your classes. (I have learned more about this problem just since I sent the original letters.) For example, think about all the process engineers designing control systems for pharmaceutical companies, chemical plants, utilities, and more. Do you think that security is embedded within the fabric of each and every course that they take? No, it isn't. (True and scary story from a colleague about a guy who insisted that his PC - which had a control system interface on it - was not Internet accessible. Oh really, what is that instant messaging window doing open on your desktop?) 

I also offer a personal anecdote about the difference between "taking a class" and immersing yourself in a language in support of my argument. Many readers (well, the 5 people who read my blog regularly, which includes my parents) know that I love the Hawaiian language. Something delightful happened when I moved beyond reading the Hawaiian language textbook and started making Hawaiian part of my daily life. I read the Bible in Hawaiian instead of English. I read Hawaiian-language books (like the story of Kamapua'a, the Hawaiian pig-god, and the Kumulipo -  the Hawaiian creation chant). I sing along to Hawaiian songs. I found that once I moved beyond "conversational exercises" and immersed more of my life in the language, I started thinking in Hawaiian. (For example, I can form a sentence without stopping to think, "does that noun take an a-form possessive or an o-form possessive?"**) Immersion in a subject or language works because it changes the way you think. Single classes do not work - at least, they don't work if you want to develop fluency or change your mindset.

I am hopeful that working together, vendors and universities can help create a revolution from within, for the benefit of all.

If change is slow to happen, or there is resistance to change, vendors can also help create an impetus behind this effort by going to legislators - such as those who serve on the House of Representatives Science and Technology Committee - and ask them to consider tying research money (for example, funds dispensed through the National Science Foundation (NSF)) to computer science curricula reform. Perhaps universities' CS departments would have the time and motivation to fix their curricula if they weren't (and I am not making this up) wasting time and grant money on how to wave a cell phone in front of a professor's door to get access to the room.  If all else fails, "money talks." The power of the purse can effect positive change (ask any kid whose allowance is withheld until he learns to clean up his messy room).

Since I am on a history kick anyway, I should point out that the US Federal Government has had a significant role in the development of the software industry. The government, especially the Defense Department, successfully used the "power of the purse" to rapidly develop the computer industry in its early stages, and can continue to use its positive influence to change the way universities develop curricula. So anybody who thinks that the entity handing out money (the government) shouldn't help use that lever to help make us more secure (by insisting that universities they fund fix a root cause of IT insecurity) needs a history refresher.

Universities are not evil but they are generally not responsive to market forces, due to a) an endless source of research money often not tied to anything approaching pragmatic results and b) tenured faculty that do not have to change because there is no impetus to change nor penalties if they don't change. We as vendors should help them change through both the "carrot" of donating our time, expertise and support for changing the curricula, so that relevant degree programs have the "secure development lifecycle" in producing graduates that we as vendors are expected to have as suppliers, and the "stick" of using accreditation and funding (or funding cutoff) to help force needed change. When Great Britain refused to accede to the principle of "taxation without representation is tyranny," the colonies seceded. We did not get our independence from Great Britain by asking more nicely for it.

Our world is more technologically based than ever before. All customers rely on IT as infrastructure, and are being driven by regulation to insist on a "secure software supply chain." Producing secure software does indeed require a secure supply chain, not limited to but including university graduates whose computer-related degree programs have security principles and practices embedded within every element of their degree programs. Perhaps what I have said above is harsh, but I offer it as Tough Love. We simply - and collectively -  must evolve to defensive mindsets delivering defensible code lest none of us survive in a hostile world.

"We must all hang together, or most assuredly we will all hang separately."

Disclaimer: Large portions of the above blog were originally written for an Oracle Magazine column I do regularly, "All Secure." The elegant journalistic term for "self-plagiarism" is "repurposing," and anyway, it's not plagiarism if you steal from yourself.

* I'd be remiss in not mentioning a few (among many) bright spots working on the supply chain problem at the university end: Gene Spafford at Purdue (always on anyone's bright spot list and has been for years), Samuel Redwine at James Madison University (who has labored long and mightily on a software security body of knowledge), and Neil Daswani at Stanford (who has published a book Foundations of Security: What Every Programmer Needs To Know available at http://tinyurl.com/33xs6g and who graciously sought me out to give me a copy). I am barely giving these fine gentleman credit for a lot of hard work to improve university curricula in this area, and I know there are others who are also similarly engaged whom I have not credited. Thank you, all.

** If you really want to know, o-form possessives are used for things that are inalienable or are your birthright. Emotions, for example (like aloha - love), means of conveyance (like papa he'e nalu - surfboard), parents, gods, are all inalienable and thus take an o-form possessive: He makuahine maika'i ko'u. (I have a good mother.) Things that are alienable or that you acquire (spouse, children) take a-form possessives: He ipo 'olu'olu ka'u. (I have a nice sweetheart.) It was a big day in my life when I could start rattling off sentences without thinking about what kind of possessive to use.

For More Information:

Book of the Week:

Aircraft Carriers at War: A Personal Retrospective of Korea, Vietnam, and the Soviet Confrontation  By Admiral James L. Holloway III, USN (Ret.)

http://www.usni.org/store/item.asp?ITEM_ID=1320

ADM Holloway (disclaimer: a family friend, so I am justifiably prejudiced in his favor) has had an amazing career: an officer during WWII (present at the Battle of Surigao Straight outlined in Last Stand of the Tin Can Sailors) he then qualified as a naval aviator, serving throughout the Korean and Vietnam Wars.  He also served as Chief of Naval Operations. He is fine leader, a fine person and a long time contributor to naval history and thought. There has been so little written about the Cold War from a military perspective that this book is doubly welcome: written by a great leader and warrior who was there. (Hey, all the reviews are glowing - I am just gilding the lily.)

Another true hero has died: Jacob DeShazer, who was one of the Doolittle Raiders who "struck back" at Japan after Pearl Harbor by bombing Tokyo on April 18, 1942. (Japan subsequently decided to "finish" the Pacific fleet at Midway, where they lost the war.)  DeShazer endured unbelievable hardships - torture and deprivation - as a POW of the Japanese but forgave his captors after becoming a Christian, and returned to Japan to serve as a missionary for 30-odd years. Rest in peace, faithful warrior.

http://www.nytimes.com/2008/03/23/us/23deshazer.html

The Defense Science Board Task Force Report on Mission Impact of Foreign Influence on DoD Software:

http://www.acq.osd.mil/dsb/reports/2007-09-Mission_Impact_of_Foreign_Influence_on_DoD_Software.pdf

Web site for the House Science and Technology Committee (express yourself!):

http://science.house.gov/

The educational board of ACM (complain to them!) can be found at:

http://www.acm.org/education/panel?pageIndex=1

More on the Hawaiian language (including a-form and o-form possessives):

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

The SQL injection tutorial I mentioned (anyone can take it):

http://st-curriculum.oracle.com/tutorial/SQLInjection/index.htm 

Last - but far from least - the SANS organization web site:

http://www.sans.org/

Between prime time television and the newspapers, the average person could be forgiven for thinking that most of life in America is sordid, self-serving and sensationalistic. If you go by news and TV, businessmen are always greedy exploiters of the poor/despoilers of the environment, veterans are always crazed gunmen, and hardly anybody takes marital vows seriously, if at all.

The negative emphasis of some media is all the more reason to enjoy those who practice excelsior living ("excelsior" is Latin for "higher" or "superior") instead of degradation and debasement.

One such event occurred for me last week when I attended the IT Security Entrepreneur's Forum. A friend of mine is the executive kahuna and founding force for good behind this event (though other organizations sponsor it, like the Department of Homeland Security and the Kaufmann Foundation). It's an opportunity for entrepreneurs in IT security to understand what security challenges the US government faces, and to learn how to work with the government. The topics covered everything from the VCs that have government involvement, like In-Q-Tel, to how to deal with system integrators and procurement programs. The idea was to get entrepreneurs' Cool New Security Ideas in front of people dealing with Large Scale National Security Challenges, for the betterment of all.  (Mahalo nui loa, Robert, for a great event.)

I was reminded several times during the week that there are people who not only want to make the world better, they are committing their lives and fortunes (or at least, investors' fortunes) to doing so. (And, unlike the target of my last entry on Do-Gooderitis, these problems all need solving, badly.)

One of my happy "better world" moments occurred in the discussion of energy security at the Forum. Truthfully, I never thought much about the IT security implications of energy. You can see that protecting information about promising new energy sources, new extraction techniques and technologies would be important. Also (while I do not intend to be polemical or political) it is pretty clear that the extent to which we are dependent on non-US oil supplies does drive our involvement in the Middle East. Ergo, finding alternative sources of energy (and making wise use of the energy we have) has important national security implications. 

We live in a country where we mostly take energy for granted: you plug in your whatever, you get power, no problem. (Though it can be expensive. It's been a cold winter in Idaho and my last two Idaho Power bills have been high enough to make me consider listing them as a dependent on my tax return.) We forget that not everyone lives in a place where there's a plug and ready access to a steady power supply. For example, soldiers and marines in war zones have an unbelievable plethora of electronic gadgets and gizmos on their person, many of which require them to carry God knows how many chargers, not to mention lots of batteries. For them, being able to eliminate unnecessary electronic chargers mean they could fight more nimbly (carrying less weight in their packs), or that they could carry an extra magazine or Ka-Bar instead of a power cord.  Most of us, though not typically getting shot at on business trips, can relate to the annoyance of schlepping a bunch of cords and adapters along wherever we go. I think I carry about four on the average business trip (camera, iPod, computer, cell phone). Probably an extra cord or two to charge things in the car. For weight reasons alone, I'd like to carry fewer chargers (and then I'd have room for more books, instead of the three or four I typically carry on a trip).

Wouldn't it be really great if you could carry one charger that charged all your devices? A charger that would be smart enough to detect when a device is charged and automatically stop sucking power? Also, although I am not always the most ecologically correct person, I hate the idea of throwing more stuff into landfills. It probably comes from having parents who grew up during the Depression: throwing things away that are perfectly good to use again just doesn't sit well with me. One thing, energy efficient, that you can reuse over and over sounds pretty darn good.

There's a company called GreenPlug that would really - is really - making it a better world, because what I just described is the GreenPlug vision. Someday soon, I hope all those electronic gadgets we love to have with us can be GreenPlug-enabled, so we only suck the power we need to charge a device - and no more - and we have one thing that charges all our gadgets instead of rebuying charger after charger after charger. Back to security, I think about "GI Joe" or "Marine Bob" (Robert or Roberta) in the field, who could take five pounds of chargers and batteries out of their packs and replace the weight with more MREs or a couple of spare magazines. (Sometimes better security is as simple as having more firepower than the other guy.)

In the near future, I want to buy my very last power hub/charger/cord/thingy - ever. (Mahalo nui loa, Palani, na honua 'apau.) (Thanks, Frank, for all the world.) Special mahalo for helping the warriors in harm's way, who will one day carry more he mau mea kaua (weapons) and fewer power cords.

Another group out in force at the IT Security Entrepreneur's Event was one of my favorite government organizations, the National Institute of Standards and Technology (NIST). I have been a huge NIST fan for a long time. In fact, the title of this blog came from comments I have made about NIST in the past: "NIST: A Force for Good in the Universe." NIST has a long record of developing standards and benchmarks for things in a highly transparent way. That's their charter. So you think, why give them credit for "just doing their job?" Because of the way they do it, the fact they are so good at it, and the individuals who work there I deal with. (I am still wearing a black armband several years after Ed Roback left NIST to go work at Treasury. I miss him.)

The fact is that industry, despite much posturing, does not always do standards well. Too many times it is Big Companies A and B teaming up against More Big Companies C and D to duel over standards. A couple of disparate standards limp along, things don't work together, the companies involved may never want or work towards a truly independent standard. What they want is a lock-in to "their way or the highway" for competitive advantage. That's business.

There is, however, a public good argument for getting plumbing to work together so we can all have nice hot showers. NIST is in the "getting everyone a nice hot shower" business by working to help create the standards that make public good activities in IT security (among other areas) happen. If standards (true open standards, not "dueling standards") do not happen, what consumers end up with is stuff that has to be spliced together with digital duct tape. Try taking a hot shower with duct taped-together pipes sometime to see how well it works.

We need a truly independent group to do standards well. I realize I am going against the nerdy grain here, but really, most consumers do not care two hoots in hell for "elegant technical solutions" half as much as things that just work together without digital duct tape. NIST's only "dog in the hunt" is to solve a problem well and with broad industry feedback. Their entire MO is to help create standards by working with industry. When they are engaged in standards development, the result is typically really good, because they get great minds working on it and listen to people. What's better than that? NIST's purview also covers technical benchmarks (like security configurations) and there, too, there is a dialogue with industry, instead of a few people locking themselves in an ivory tower and creating drawbridge specs without ever actually using a drawbridge or consulting castle defenders.

NIST does a great job at working with all stakeholders to the point where lots of vendors, including me on behalf of Oracle, are happy to traipse up to the US House of Representatives Science and Technology Committee asking for more money for NIST to continue Doing Good Things.  For all the times when you wonder where your tax dollars are going (and why), when it comes to NIST, they are doing good things with your money and if given more, will do more good things with it.

Both NIST and NSA folks graciously visited Oracle a couple of days before the Forum (as well as participating in the Forum) to talk about SCAP (Security Content Automation Protocol). Our goal for inviting them was for them to explain what issues the Defense Department is trying to address through SCAP and, on the Oracle side, what technology we have that gets at the problem space (with a view towards "can we play /talk/work with SCAP?")  I have - and probably will continue to have - issues with some of the particulars of SCAP. What I don't have an issue with is the problem space. I also appreciate that we had a productive discussion with the experts from NIST (and NSA). Bilateral. Not, "We dreamed this up and we know everything."

(For those who are nerdy enough to know that there is a linkage between Federal Desktop Core Configuration (FDCC) and SCAP, you are probably wondering why I like SCAP and (per last blog entry) am less than thrilled about (some aspects of) FDCC. The issue is that the actual configuration required by FDCC was mandated instead of first being developed in conjunction with industry. Had pretty much any vendor who is affected by FDCC gotten a chance to comment on the benchmark before it was mandated, lots of issues would have - we think - been clarified. I still do not know what a "desktop" is because there is no definition yet.  This is exactly the sort of dialogue NIST does and is good at, which is why the technical standards and benchmarks they work on are adoptable and adopted.)

The reason SCAP matters is that the lack of basic "security plumbing" puts all of us at a distinct disadvantage in protecting our systems. Can anybody answer the question, real time:

Who is on my network?

What is on my network?
What is my "mission readiness?" (my security configuration, patch level and so on)?

What is happening that I should be worried about?

You can think of the network as the battlespace (it surely is) and the answers to the above four questions are necessary to give you what the military calls "situational awareness." Nobody has it, and thus the advantage is all to the attackers. SCAP does not address all the above issues, but it does answer questions related to mission readiness (and also, "what's on my network?") Being able to get enough standardization so that you can determine whether your network components are locked down correctly, or what components you have that are subject to a particular vulnerability - in some automated way - would be really useful. Nobody adds any value by manually reading security bulletin FOO and then manually trying to figure out what they have on their network that is subject to FOO problem. No automated tool does this for everything, or does it well, or works with any other tool someone would use. Which is why everyone is using digital duct tape with predictable results: advantage to attackers.

One-off security products that do pieces of this but don't do it comprehensively are not enough. You need to know "what's my security posture?" real time, so if something is happening that you should be worried about you can "take evasive action" real time (e.g., reset a security parameter or turn off a service). Attacks are real time; defenses need to be real-time, too. 

If there is any worse example of fiddling while Rome burns than people arguing over the elegance of their individual technical solutions instead of trying to make comprehensive, universal situational awareness a reality for everyone's networks, I don't know what it is. (Get over yourselves, people, it's national security.)

So, mahalo nui loa to NIST for - whatever one's individual issues with individual standards - creating not only a dialogue, but a climate for discussion, instead of diktats. And for being a force for good in the universe, especially for DoD. That goodness will trickle down to other communities, I have no doubt of it.

For More Information:

Book of the Week: Lone Survivor by Marcus Luttrell.

It is a source of ineffable sadness and more than a little pique to me that the average American can more readily bring to mind the names of celebutantes or tartlets (sorry, I meant starlets - I think) than the names of the last three recipients of the Congressional Medal of Honor (Paul Smith, Jason Dunham, and Michael Murphy, if you want to know). This book recounts the story of SEAL Team 10's actions in Afghanistan, which led to LT Michael Murphy's death, those of two others in the squad, and 16 people on a helicopter that came to extract Luttrell's SEAL team. Marcus Luttrell was the lone survivor (and recipient of the Navy Cross).

This book should be required reading for anybody who wants to know what real heroism is (hint: it's not the ability to putt, throw or slam dunk). And, in my opinion, there is something wrong when members of the armed forces are more afraid of violating the rules of engagement than they are of the enemy. As Luttrell puts it: "...any government that thinks war is somehow fair and subject to rules like a baseball game probably should not get into one. Because nothing's fair in war, and occasionally the wrong people do get killed."

http://www.amazon.com/Lone-Survivor-Eyewitness-Account-Operation/dp/0316067601/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1205801463&sr=8-1

The citation for Michael Murphy's Medal of Honor:

http://www.history.army.mil/html/moh/afghanistan.html

The citations for Paul Smith's and Jason Dunham's Medal of Honor:

http://www.history.army.mil/html/moh/iraq.html

More on the IT Security Entrepreneur's Forum:

http://www.publicprivatepartnerships.org/

More on GreenPlug ("One Plug, One Planet"):

http://www.greenplug.us/

Marines love their Ka-Bars, and who can blame them?

http://www.geocities.com/heartland/6350/kbar.htm

Unbelievably cool that KGMB9 station in Hawai'i is doing a regular news segment in the Hawaiian language. Maika'i nui loa! (Woo hoo!) 'A'ha'i 'olelo ola (messenger of a living language).

http://kgmb9.com/main/content/view/4738/40/

You know there are too many labor-saving devices in the world when you see the sheer number of professional do-gooders trying to solve problems hardly anybody else worries about. If you have a day job, having someone with too much free time tell you why you need to be concerned about "Making the World Better Through FOO" is often just about as irritating as those old TV commercials moaning about ugly yellow wax buildup on your kitchen floors (my solution: paint your kitchen walls yellow to match the floor).

There are, of course, many people who devote time and passion to making the world a better place. I'm not talking about them here. I am talking about the people who seize on something they care about without bothering to find out if there is an actual problem that needs to be solved. Or, if there is a "problem," asking what the cost is of fixing it and what one could do with those same resources that might solve a more pressing problem (a concept known as "opportunity cost" to economists). It's all you can do, when confronted with an earnest but clueless do-gooder, not to say, "Ask me if I care."

Where I live in Idaho, there are a couple of professional Do-Gooder Projects that engender a lot of whining in the local newspapers. One of them is the Relocate the Airport lobby. The claim is that we need to 1) build a new airport 2) with longer landing strips 3) so that larger commercial planes will fly here. (Never mind the fact that commercial airlines have said repeatedly they will not land larger planes here because there isn't enough demand to support it.) There isn't actually a problem the community needs to solve via a new airport, but we'd create a bunch of new problems, like people having to drive an hour or more to get to Sun Valley instead of the current half hour from Friedman Memorial Airport.

The other local Do-Gooder Project relates to "affordable housing." Mind you, there is no actual housing shortage in town: if you want to work here, you can easily find an affordable place to rent. Many people who work here who want to own property live in another county - where they can get a lot more land for a lot less money. The idea that anyone who works here - regardless of income - should be entitled to own a free-standing home isn't reasonable given market (and geographic) realities (e.g., the land around us is Bureau of Land Management land and cannot be developed). As one of my friends put it to a local Affordable Housing Do-Gooder: "You didn't live next door to your gardener in Marin, either."

My personal opinion is that a lot of these do-gooders retired early, miss running something and want to run everyone else in town by solving problems that don't exist.

There are Do-Gooder Initiatives in the IT industry, too, a number of which are in security.  Security Do-Gooder Initiatives sometimes come under the guise of a laundry list of 5,000 things that everyone should do to be more secure. Even if all 5,000 of those things are somewhat useful, just like New Year's Resolutions, they are likely to be more actionable and "accomplishable" if the list is shorter. Putting it differently, I know very well that I should eat less, exercise more, eat more nutritious food, read better books, improve my skate skiing technique by lengthening my glide and so on. I can't actually process 5,000 "should dos" so I try to parse them down to a smaller list of things that I can actually do that will also make the most difference to my health, my skate skiing, or whatever it is I am trying to improve upon. Many Do-Gooder Initiatives do not have any sense of "nobody can do everything all at once, so maybe doing something now and doing more later is a better way to slice the pie." The initiatives fail due to the expectations - and failure to prioritize - that they entail. You might actually just give up from the frustration of trying to comply with 5,000 "shoulds." 

(It turns out that the people who actually do make good on their New Year's Resolutions start with a small, actionable list instead of a 30-page life plan. A small list of things you can do and will do is better than a much larger list of things that you are never going to get to. Less really is more.)

The reality is that some things matter more than others if you are trying to make constructive change. If I drink a bottle of wine a night (I don't) and have 40 "better health things" I want to do, saving my liver might be among the most important ones. So maybe, trying to cut down to a glass or so a night would be the biggest payoff on my better health things list and I can skip the other 39 items or relegate them to next year. Unfortunately, there are a lot of Do-Gooder Initiatives that not only have too many things on the list; the list is not weighted at all for where the value is in making change. (Opportunity cost again: what could I do with the same resources that would have a bigger payoff?)

I wonder if a lot of Do-Gooders get out enough in the real world. Maybe they are academics who think "theory" is enough. ("Theory" of baking doesn't get you a pie.) Or think-tankers who are paid to develop secure Internet toaster protocols that they then want to standardize. (Does anybody really worry about who is accessing their bagels remotely?)

Whenever I participate in public-private partnerships where a lot of "improve security" initiatives are generated and where there is typically a broad tent of participants (a good thing, in general), I try to ask that the people putting the laundry lists together grab someone who is either a cost accountant or an economist to look at where the bang for the buck goes in what's being proposed. Because if they do not do that, these initiatives are doomed to fail. Or, they will be so expensive that nobody does them because they can't afford the entire megillah.

The one take-away lesson I got from my nerdy quantitative methods class in business school is that when you are trying to solve an optimization problem, you can't optimize on all parameters. Time is constrained. Resources are (ultimately) constrained. Answering the question, "How can do X while making best use of scarce resources?" means I need to take account of what I most want to accomplish and how valuable is it to me that I accomplish those things.

For example, there are security initiatives around "what metrics and artifacts at every stage of development you should produce to 'prove' assurance claims."  People measuring the assurance of software believe that there are things you ought to be able to produce and measure at each stage of development. However, there is a cost to producing metrics and artifacts. If the cost of producing these is greater than the value of more information, you shouldn't put the work in to produce them. Even if everything has some value, some things are more critical than others or provide greater value for the work you put into getting them. One of the way I tranche our metrics project is to look at a) what can we data mine today to give us security metrics? b) what else would we like to know (in some order)? c) what will it cost to get that information? and d) is the cost less than or greater than the benefit of the information?

If you are a small company, maybe you can't - in the beginning - do every single Best Practice Recommendation (or produce every single metric or every single artifact that anybody in a theoretically perfect world would want). But you can do something, and you'd be willing to do something if someone helped you by telling you what the most important things are to do first that make the biggest impact. Something is almost always better than nothing.

Even people who know they ought to do more in security - and are willing to improve - will fight tooth and nail if they are confronted with a "my way or the highway" mandate that takes little account of real world constraints.

For example, consider the Federal Desktop Core Configuration (FDCC), a recent initiative to mandate that US Federal agencies lock down their environments to a specific Windows configuration (which, as a matter of course, means packaged applications will need to run on those locked down Windows configurations). I have said often and publicly that I think one of the easiest things vendors can do to help improve security is to lock down default configurations - better security out-of-the-box, cheaper lifecycle cost for customers. I've also said that one of the things customers can do to be "smart buyers" is to insist that their vendors lock down default configurations: "You don't ask; you don't get." I don't have any issue with the goodness of this concept (and we have a company-wide initiative related to locking down default configurations). In that sense, FDCC is not a "Do-Gooder Initiative" the way I've defined it since it actually does address a problem that people worry about, that needs looking after.

The problem with the way FDCC has been mandated is that it did not, first of all, define what a "desktop" configuration is. Is it desktop software? Or anything installed on the Microsoft operating system (which can and is used on desktops)? There might be a huge (and legitimate) difference between the configuration of middleware or servers on Windows and the client piece of an application configured on Windows. There's certainly a big scope difference between "validating how client pieces of applications running on desktops are configured to run with FDCC" and "validating how every single component of every application that runs on Windows is configured with FDCC." What problem, exactly, is it that is being solved? "Desktops used to launch attacks?" or "locking down the Windows operating system for every single application running on it?" Nobody knows, especially since this is called a "desktop" configuration initiative, and nobody on the mandate side of this issue has yet answered that basic question.

Most vendors have product lifecycles such that they do not make configuration changes in anything other than a major product release. That is, when customers uptake patch sets, their expectation is that there won't be configuration changes that could break their existing applications. One time in almost 20 years at Oracle, I tried to change a configuration parameter in a patch set (for good security reasons). The configuration change broke all our business applications, so we backed it out before the patch set shipped and I've been apologizing to the release manager ever since. (We later made the configuration change in a major product release.) Unfortunately, FDCC was mandated without adequately taking into account vendors' product lifecycles. Some vendors simply will need more time to phase in needed configuration changes. A lot more, if your major release product lifecycle is years and not months.

Nobody was evil-minded here, but even people who support the idea of FDCC are dead in the water until they can get some basic questions answered and a dialogue going. Ideally, this dialogue should have taken place before FDCC was mandated. Industry (including Oracle) is still working to try to get clarification on the specifics of FDCC and also asking that in future these types of configuration mandates be developed with industry and with adequate phase-in that allows for product lifecycles. How you implement change is as important as what the change is if you want people to move the security ball down the field. Otherwise, even a worthy initiative like FDCC can sink into the morass of Do-Gooder Projects.

A better example (where really, "there is no there there," to quote Gertrude Stein) is the recent proposal to develop an ISO standard for vulnerability disclosure. I know of no vendor who thinks this is a good idea. For a start, what problem are we trying to solve? Does anybody think that we can come up with a one-size-fits-all standard for how long it should take to fix a security bug, the exact "rules" on how much information gets put into security advisories and the specific format of how that vulnerability information is expressed? Software vendors have different release cycles, customer bases, risk profiles, and more. (One-size-fits-all pantyhose, as any woman knows, only fits Hilda Mae Throckmorton of Muncie, Indiana.) There are plenty of industry guidelines for good practice on vulnerability disclosure already. Most of these acknowledge that you can't standardize this business practice any more than you can standardize apple-pie making ("Allspice? Death to infidels!"). There are also existing standards on vulnerability disclosure that vendors are adopting, such as the Common Vulnerability Scoring System (CVSS). Oracle was an early adopter of CVSS and customers have told us that it's really useful to them.

It is unwise (no, make that "really stupid") to try to standardize what is in effect both a business process and a set of business practices. Ira Gershwin (who knew he was a security maven?) penned the perfect lyric that applies to this Unneeded Standard Attempt: "You say po-TAY-to, I say po-TAH-to, let's call the whole thing off."

I offer one last example that isn't quite in line with Do-Gooder Initiatives but relates to what problem to solve and at what price. It's also a big pet peeve of mine: I get a lot of phone calls from vendors trying to shill their security products to Oracle. (Though I do not have operational security responsibility - wonderful, capable colleagues look after that - vendors assume that since my title is "CSO," I am the person who buys Cool Security Products for the IT department.)

I hate to mention how many cold callers do not even do basic homework before trying to sell me true love and security happiness. My favorite was the cold caller who said his firm had expertise in securing Oracle Applications deployments. I had to point out to him that, "Uh, we are Oracle, we run on Oracle Applications, and since we build the software, we'd be unlikely to hire a third party to 'securely deploy' it for us." Or, the vendors selling solutions that run on a non-Oracle database. You know, that's just a religious problem for us: we are not going to deploy a third party security solution that runs on <insert name of competitor database here>.

My basic pet peeve is the people who do not think about the customer perspective before they launch into their "cure cancer, raise the dead, protect against every attack known to mankind with zero false positive" shill. They claim this shill will only be "twenty minutes of your time" (only "twenty minutes" is measured on a calendar, not a watch).

Forthwith, here is my script for parsing through shill-meisters as quickly as possible:

1. "What problem does this solve?" (If you can't articulate that in 25 words or less, do not waste my time or anyone else's.)

2. "Is it a problem we are worried about or care about solving?" (Secure remote bagel access is not something that concerns me, so forget the 'Internet Toaster Protocol' pitch.)

3. and 4. "Does it address the problem better, cheaper or faster than what I am doing now? How much better, cheaper or faster?" (If it doesn't, why would I switch from something that may not be sexy or "a breakthrough technology" but gets the job done? I don't have an electric salad tosser, either, because the salad spinner I have - or a pair of tongs - works just fine and has fewer moving parts.)

5. "How can it be broken?"  (Especially for a security product, knowing and being honest about how it can be broken is important. A claim of "zero false positives," for example, should cause anyone to run screaming in the opposite direction.)

Do-Gooders, the next time you come up with A Cause, a small request. Please, in the interests of making it a better world without wasting everyone else's time, use your skills on a problem that really needs a solution (or on a better, faster, or cheaper way of solving an existing problem), not on a solution in search of a problem to solve.

For More Information:

Book of the week: Hog Pilots, Blue Water Grunts by Robert Kaplan (who also wrote Imperial Grunts). If you want to know what the military really does, this is a great read. Robert Kaplan was embedded with a number of different types of units, in multiple services, around the globe: special forces, marines, aviators, and submariners. A really cool read. Mahalo nui loa, all you soldiers, sailors, airmen and marines for keeping us safe.

http://www.amazon.com/Hog-Pilots-Blue-Water-Grunts/dp/1400061334

We aren't going to have "oldies" rap stations anytime in the future. If anybody has written a more clever lyric than Ira Gershwin (OK, maybe Cole Porter) I have yet to hear it. Songs with lyrics by Ira Gershwin:

http://en.wikipedia.org/wiki/Category:Songs_with_lyrics_by_Ira_Gershwin

Totally off topic, but Go! Airlines has just done a web page where you can book your next interisland trip totally in Hawaiian. E ola mau ka 'olelo Hawai'i (May the language of Hawai'i live!).

Check it out at:

http://www.lelegowau.com/

There is an aphorism famously attributed to Mark Twain (among others) to the effect that there are "lies, damn lies and statistics." The Mark Twain quotes on truth I was able to verify were almost as interesting though not quite so pithy:

A lie can travel halfway around the world while the truth is putting on its shoes. (Remember, this was before the Internet).

Get your facts first, and then you can distort them as much as you please.

I've had several reminders recently that what we think we know and take for granted is often not only wrong, but quite wrong. The ease with which we can search for things on the Internet leads us to forget that what we are finding is information, but not always expertise and almost never actual wisdom. To the extent we rely on "received wisdom" it is a good opportunity to remind ourselves that information and knowledge are two different and often diametrically opposed beasties, indeed.

For example, someone recently sent a resume of a former colleague. I use "resume" loosely, as the description of work experience (the portion I have direct knowledge of, which is the only section to which I address my comments) is better described as "fiction." Perhaps, "fiction based on actual events," if I am feeling generous, except that I am not. This was by far the worst example of resume embellishment I've seen in 20-some years.

In the interests of protecting the guilty, I will call the individual involved Fictional Resume Writer (FRW). The nature of FRW's sins were 1) claiming credit for work FRW never did 2) claiming origination of work done by others  - which I find especially reprehensible and 3) gross exaggeration of accomplishments.  I emailed FRW and said that I thought a resume rewrite was in order; especially given FRW was seeking business with Oracle. Business is personal, I said, and someone who is materially misleading in credentialing I'd be unlikely to trust or want to work with in a business setting. I also went point by point with the "issues" in the resume, just to be clear what I thought was inaccurate and why.

The response I got was the email equivalent of a shoulder shrug and a comment that the amount of hard work FRW expended "justified" claiming credit. (Is this the new world of Web 2.0, where "mashup" owners claim origination based on the "hard work" involved in taking others' work and creating something different from it?)

Perhaps I am old-fashioned, but there is a clear difference between a good idea, initiating that good idea, and carrying through on a good idea to effect positive and measurable change. And common sense if not a sense of honor should dictate how one expresses the difference among them.

For example, once upon a time, I got tired of explaining to developers for the umpteenth time what a buffer overflow was, so I wrote up a few pages - perhaps two or three - on what constituted a buffer overflow and how to avoid them. Though I did not know it at the time, this was the genesis of the Oracle Secure Coding Standards. I note at the outset, for reasons that will become all too obvious if you keep reading, that I do not claim "authorship" of these standards.

My prototype document grew over time, substantially. Someone else expanded the list to be a "top ten" list of secure coding dos and don'ts. "Top ten" then grew to be an extensive list of security vulnerabilities and how to avoid them. There are also examples of what happens if you don't write correct, secure code (drawn from actual coding errors development teams have made). All in, the document has grown to about 300 pages, to include "case law" (not just what not to do, but how to address specific technical issues the correct way). One individual (Oracle's Chief Hacking Officer) has written the bulk of the secure coding standards with input and review from others and he is clearly the author and redactor of this document. (Mahalo nui loa, Howard.)

There have been other enhancements and uses of the secure coding standards. Someone got the bright idea of tying the secure coding standards directly to our product release security checklists. A couple of people developed the secure coding class (online web-based training based on the Oracle Secure Coding Standards), while still others have watched over the rollout of this class to the development groups that need to take it (to include restructurings, new hires and acquisitions).

In theory, were I to write my resume the way FRW has, I would claim "originator," "author" or "founder" of the secure coding standards, since I wrote the first two - count them - two glorious pages. But what I wrote does not have the breadth, depth, examples, actual technical know how, proactive guidance, and utility of what now exists. My claim to "authorship" - if I were vain enough to make it - is like the person who puts the front page and inside page (the one with the ISBN number) together for a book claiming to be the "author." It's simply ridiculous, and I'd deserved to get whacked with all 300 pages, hard bound, if I made such a statement.

There is a security lesson here. One of them is the age-old one of "trust, but verify." It is not my job - and I would not do it - to tell FRW's current employer that FRW's resume in some particulars is much closer to fiction than fact. "Caveat emptor" - let the buyer beware. If you are hiring someone on the basis of credentials, it's well worth checking them.

The second security lesson is an old one. Business is still personal, and personal attributes matter, like honor and trust. Contracts, for example, cannot create trust where there is none; just specify requirements for performance and remedies for non-performance.  A person who is untrustworthy in small things is likely to be untrustworthy in large things, and if there is anything more untrustworthy than taking credit for others' work, I do not know what it is.

The second reminder of the difference between what we think we know and the truth was occasioned by a recent op-ed piece in the Wall Street Journal called "The Lies of Tet" by historian Arthur Herman (I can personally recommend his book To Rule the Waves - How the British Navy Shaped the Modern World).

For many years, I've tried a little "knowledge experiment," by asking random people if they had heard of the Tet Offensive and, if so, who they thought "won." The response (if I exclude people who have served in the armed forces who know the truth) is astonishing. Most people, when asked, believe that the Tet Offensive was a resounding defeat for the forces of the United States and the Republic of South Vietnam. In particular, those who were alive at the time and recall the media coverage are shocked to find out that what they think they know is all wrong. One hundred percent wrong, in fact.

As Arthur Herman says:

"The Tet Offensive was Hanoi's desperate throw of the dice to seize South Vietnam's northern provinces using conventional armies, while simultaneously triggering a popular uprising in support of the Viet Cong. Both failed. Americans and South Vietnamese soon put down the attacks, which began under cover of a cease-fire to celebrate the Tet lunar new year. By March 2, when U.S. Marines crushed the last North Vietnamese pockets of resistance in the northern city of Hue, the VC had lost 80,000-100,000 killed or wounded without capturing a single province. Tet was a particularly crushing defeat for the VC (emphasis mine).  It had not only failed to trigger any uprising but also cost them "our best people," as former Viet Cong doctor Duong Quyunh Hoa later admitted to reporter Stanley Karnow. Yet the very fact of the U.S. military victory -- "The North Vietnamese," noted National Security official William Bundy at the time, "fought to the last Viet Cong" -- was spun otherwise by most of the U.S. press." ("The Lies of Tet," Wall Street Journal, February 6, 2008)

There are "truths" that are so embedded in the fabric of what we think we know that we don't even bother reading broadly, from a breadth of sources (and reputable sources) to reach our own conclusions about what is true vs. what is received wisdom. We simply must do so on issues that matter to us, instead of "outsourcing" wisdom to pundits. Otherwise, "collective" wisdom substitutes for actual facts and analysis. Of all the maxims wandering loose about the Internet (and on it), the one I find the most obnoxiously untrue is "the wisdom of the crowds." Sometimes, the crowds are dead wrong, because they've been massively misinformed. As with Tet.

It is an inescapable truth that the media got Tet wrong, spectacularly wrong, and "the lies of Tet," to use Arthur Herman's phrase, continue to shape people's opinions of not only Vietnam, but warfare in general and the veracity of the armed forces decades after the actual events.

As much as I have expressed concerns about every idiot with an opinion being able to express it on the Internet (as I am doing here!), the fact remains that in some cases, bloggers have spotted untruths, exaggerations and fabrications reported by the media (doctored pictures and doctored service records, to think of a couple of prominent examples). There is an important utility in keeping professional journalists and industry analysts honest and objective that is worth something to the millions of people who expect that from mainstream media. Score one for the blogosphere.

The corollary, and cautionary note to the blogosphere, is the realization that not all truths are apparent in nanoseconds. Technologists are used to rapidity of change, and the barrage of information and the rapidity of change often consume us as we try to keep up with the latest technology trend. Often, however, it is only with the passage of time, careful analysis, and hindsight, that we can correctly weigh events. There is a reason for the phrase rendered "timeless truths" instead of "nanosecond truths."

I was on vacation recently at a venue that couldn't be more removed from Silicon Valley: Colonial Willliamsburg, Virginia, at The Williamburg  Antiques Forum. Looking at decorative objects that are between 300 and 400 years old and determining what they say to us now about the time at which they were made and the people who owned them could not be more different than what I do for a living. Yet even in the world of decorative arts, curators continue to uncover new facts that may lead them to reinterpret history. In short, even with a 350-year-old highboy, there is still much to learn, to the point that one's view of history may change.

The security issue in the above is still "trust, but verify," and I would add "from multiple sources, not merely one." Be especially wary of "received wisdom" on things that matter, and be willing to do your own research and develop your own expertise. Anything I read about military history - and history, in large part, is military history - I use at least two sources for if it is important to me, and occasionally more.

Thus far, I've talked about lies (FRW), damn lies (the media about the Tet offensive) but not about statistics. The statistics part comes with a presentation I have been doing recently (three times in Eastern Europe a couple of weeks ago) about security metrics.

I'm going to skip over a lot of what I talked about (I have already opined in a previous blog entry why "number of published vulnerabilities" is a metric very easy to "game" to achieve unintended results), to focus on a truth I stumbled upon by sheer accident. I suspect that metrics kahunas have known what I found for a long time, so I don't claim novelty, just a "eureka!" moment.

I talked in my presentation about what constitutes a good metric (objective, measurable, helps you answer basic questions like "are we doing better or worse," incents the right behavior, fosters additional questions, helps you identify positive or negative trends, and so on). I used as an example the various metrics we keep pertaining to the release of CPUs that I wanted to discuss as a group, because there is no single metric that you could use to answer "goodness questions" related to how we are doing. In fact, picking a single metric and focusing it to the absence of all others would lead to incorrect incentives.

For example, one of the metrics we keep is "number and percentage of patches that were published on the announced CPU date." That's a good one, except that you do not want people only hitting the date and ignoring quality. So, "number and percentage of patch reloads" is another one we keep, because while we want CPUs to come out on the target date, we do not want to have to reload patches because the quality was poor. Both quality and timeliness are important; hence, two metrics. We are also concerned that the issues we identify as worthy of going into a Critical Patch Update make it through the process (sometimes, issues drop out for regressions). Ideally, you'd want all critical issues you identify to actually make it into the target CPU (because there are no regressions). So, we look at number of issues that drop out through the CPU process because we are trying to make that number as low (over time) as is feasible.  I walked through all of the aforementioned metrics (and a few related to CPUs I did not discuss here) and slapped a heading on the slide: "combined metric."

My eureka moment was noting that, if security metrics are useful, and they are, the idea of a combined metric is even more useful. The goal of a metric is to be able to manage better, and just as (in the pre-GPS days) of navigation you need to take multiple "fixes" to triangulate your position, you are often better served by triangulating how you are doing by measuring and weighing several different metrics. Rarely can you manage well by measuring just one thing.

The real goal of any metric, or "statistic," to round out my theme, is to manage better. Metrics can help you allocate resources to affect the most good for the most people and to spot trends (both positive and negative) quickly. Ultimately, a good metric needs to help you answer the question, "Are we doing better or worse?" You can do a lot with metrics, and some people lie with them, but above all, you have to be honest with yourself.

As Shakespeare put it so well:

This above all: to thine own self be true,