« February 2008 | Main | April 2008 »

March 2008 Archives

March 6, 2008

Do-Gooderitis

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/

 

March 18, 2008

Forces for Good in the Universe

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/

 




 

About March 2008

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

February 2008 is the previous archive.

April 2008 is the next archive.

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

Powered by
Movable Type and Oracle