Mary Ann Davidson

Subscribe to Mary Ann Davidson feed
Oracle Blogs
Updated: 11 hours 56 min ago

Physician, Heal Thyself

Thu, 2010-07-15 04:04

"The fault, dear Brutus, is not in our stars, But in ourselves, that we are underlings." Julius Caesar (1,ii140-141)

There is in some cases a terrible - and in some cases terrifying - disconnect between technology and our larger societal ability to understand it, in particular, to understand the risks it poses and the unintended consequences of those risks. The limitations of technology are not necessarily what we think they are, either. That is, we wouldn't solve all our technology problems if only we had - more technology. No, many of the limitations are ones we create ourselves, because of our inability to understand systemic risks, and by the way we think about and talk about technology as if it were something "new" and "different," instead of recognizing patterns that have repeated themselves in other disciplines.

One of the perspective slaps to the side of the head you get when you leave the nerdified air of Silicon Valley is that large swathes of the world are not technophiles, let alone technoacolytes. By that I mean that, regardless of the benefits of technology, once you drive past Los Gatos on highway 17, most of the people you meet don't think we'd achieve world peace if only we had a standards compliant API for it. Nor for that matter does most of the world think that the Eleventh Commandment is "thou shalt honor the Lord they God, by making thy code open source." As long as I have worked in technology, I continue to find the number of technological cults and cult members to be truly astonishing. If I were a social scientist, I might observe that, having extirpated God from so much of public life, we rush to find other ways to fill the void. The last time I checked, Deuteronomy said, "I am the Lord thy God, who led you out of Israel, out of slavery. You will have no other gods before me." Technology, it should be said, is not god. More like a golden calf.

If that sounds silly, think about the number of discussions we have all had with technocult members who speak in raptured, hushed tones about (insert all that apply): cloud computing, open source, object-oriented programming, agile development, and so on. (And my personal favorite, referring to any technology as "awesome." God and the North Shore of O´ahu in winter are awesome,* everything else is merely amazing, at best.) Note: I am not denigrating any of these technological constructs, merely observing that none of them have created world peace, cured cancer, raised the dead or helped anybody lose that last pesky 10 pounds. It's just technology. Even in my happiest moments curled up with my iPhone -- which is really nice technology and has made me more efficient -- I don't expect the iPhone GPS system to help me find real direction in life.

The first limitation of technology is one we impose ourselves: we make it a god, when it isn't, and IT people the high priests, when they aren't. The reason anybody cares is because technology has substantially altered our world and, if we admit it, not always for the better. Unfortunately, when technologists make an idol out of technology, we get all the overhead that comes with creating a new religion.

  • Non-believers may be ostracized or pressured to convert.
  • Statements of opinion - or ecstatic utterances - are treated as religious tenets and therefore, not open for discussion.
  • Instead of honest disagreements, we have (literal) religious arguments.
  • We may (figuratively) burn heretics at the stake.
The result is that in many cases technology is pushed merely because it is the next path to salvation, and without any rational discussion of whether we need it and, most importantly what risks it subjects us to - and whether they can even be understood let alone mitigated. Technologists become like the snake, telling Adam and Eve they will be as God is if they take a bite, and, like Adam and Eve, we only later realize the technological apple has rendered us naked.

I should have realized this when I first moved to Silicon Valley many moons ago. I went to a party given by a friend who happened to work for a chip company that was a competitor to the company I worked for. She introduced me to a colleague who, instead of the usual "Hi, how are you, nice to meet you," glared at me and said, "we're going to kill you in MOS technology." ("Not tonight, unless you are serving hemlock," was my response.) The "technology as god" cult has been reinforced a number of times over the interim years, most recently by an entrepreneur I recently talked to who had a hard time understanding that inventing a cool new technology was not, per se, enough to get him in my door or anybody else's. While I admire his entrepreneurial gifts, unless he is solving a problem people care about and can explain, in less than 25 words, he is not going to get past the "I only want twenty minutes of your time" barrier. It's just technology. It's not (a) god. It's not even a worthy golden calf wanna be.

Another limitation of technology is linguistic. I don't mean the difference between French and German: more like the difference between English and Martian. Many technologists might as well be speaking Martian, they are so far removed from the people who need to understand what the technology can do, what it can't do, and why anybody would want to use it. End users. Customers. Legislators. Those who are legitimate stakeholders in determining whether the risks of technology usage outweigh the benefits, but who cannot do that unless technologists can make themselves understood. By way of example, I might just possibly be understood in La Jolla if I were to say to someone in the surf lineup at Windansea, **"´Auwe, aia he mano nui loa! E ku´u hoa, e hele mai!" However, I'd be far more likely to get a response if I said "Alas! There is a really big shark. Get over here, buddy!" At any rate, if I cannot deliver a warning in English, I should not then excoriate a friend (on his way to the emergency room thanks to the man in the gray suit ***) that he really needs to learn Hawaiian to avoid future shark bites.

One of the main reasons technologists cannot or will not make themselves understood is the overuse of jargon. I've never met a group of people who were more jargon happy than technologists, unless it is teenagers -- who at least grow out of it if for no other reason than that they are forced to. (I don't care a hoot about "intergenerational communication styles," if a candidate for an open headcount insists on using "BFF" and "OMG" in an interview, he/she will experience "GFG"****.) If we are honest, we admit that we use jargon not only for the sake of efficiency but to make us feel smarter and superior than those who are not in the techno-know. Jargon becomes a means to exclude people from the club, and a means to hornswoggle others if we are fortunate enough to have an audience of either true believers or one that is too embarrassed to admit what they do not know. For our part, we reason, if they are too stupid to know what OCSP and HAML***** stand for, then they are not worth the time for us to offer our explanations. Jargon is also a means to cut yourself out of the herd. Everyone wants to be the first to either invent a new buzzword or be the first to use it. I'd only just learned what the acronym APT stands for -- Advanced Persistent Threat -- and already, I have had slimy sales reps emailing me asking about what Oracle does to combat APT and do I know that they have a product that can protect against it, not to mention slice, dice and make julienne fries? (What I'd really like is a product that protects against APSRs - Annoyingly Persistent Sales Reps. Nobody has offered to sell me one yet.)

I'm not immune to the temptation. I was once in a meeting with a bunch of developers talking about security issues. After listening to the discussion, I said with great solemnity, "as I see it, we need an ITP story. In fact, we need an S-ITP story. " Everyone nodded. Finally, someone had the courage to say, "what is S-ITP?" to which I replied, "the Secure Internet Toaster Protocol." ****** We get wrapped up in our own linguistic cleverness to the point we do not always know what we are saying. How then, can we expect our constituents to understand what technology is capable of, and what it is not capable of? True, there are many other organizations or cohorts that are almost as jargon happy as we are, but few of them are tasked with the level of responsibility we have. It's not just the Marine Corps and the Three Letter Agencies that do national security: technoids do. At least when I was in the Navy, you could always look up FAADCPAC******* or other cryptic acronyms in the DICNAVAB (Dictionary of Naval Abbreviations). Good luck with that in our industry (this is where the cloud cult members insist that all I have to do is look up my acronym in the acronym cloud). The point is: I shouldn't have to.

Even God - the real one - communicated in a language his followers could understand (and wrote the rules down on tablets). Technologists won't even do that. The other thing God (or His scribes) did was tell stories. It's easier for most people to get their minds around a creation story that begins "in the beginning, the world was formless and void..." than around the Big Bang and/or quantum physics. Phrases like "Can the Ethiopian change his skin or the leopard its spots?" speaks to the fact that some things are immutable. We get it so well that the number of people who use the phrase vastly exceed the number who know where it comes from. (Jeremiah 13:23). Analogies, stories, and using examples people understand all help make the complex more simple: God is more understandable than the average technologist. No wonder most people know that they shouldn't lie, cheat, steal but we have lots of the Clueless Faithful who think it's a good idea to allow houses to talk to power plants. (What next, wireless access to life support systems? Because it is just so expensive to send a nurse into someone's room.)

On the occasions when I have had the privilege of testifying in front of Congress, I've had 5 minutes to try to help well-intended legislators do something that will make a positive difference. How far do you think I'd get if I said, "we need to deploy IpV6 broadly to fix all our cybersecurity problems" or "insecure RNGs are the bane of network encryption?" I might actually get farther if I said, "'Auwe, eia he mano nui loa! E ku'u hoa, e hele mai!" (At least, Senators Inouye and Akaka - and the rest of the state of Hawai´i delegation - might understand.) I readily admit that I am not a technologist - I don't have the in-depth knowledge that most of my team has. What I do have is the ability to ask questions until I understand the gist of - and details of - a problem, and the ability to translate the problem into terms others can understand. Without that communication, you get people suffering from avoidable shark bites because they don't speak Hawaiian. Why is it so hard for technologists to understand that if they cannot communicate, their technological acumen is worthless, even dangerous?

Maybe the reason technologists resist the use of analogies is that it would reveal that the emperor has no clothes or, more accurately, that the emperor's clothes are the same ones everyone else is wearing. By that I mean, that if we can use analogies to explain technology and technological limits, it makes it all too obvious that we already have examples we can use to, for example, craft public policy. We might be forced to admit that technology isn't the ooh, aah, gee whiz stuff we say it is, it's just the same old problems wrapped up in shiny new bits.

For example, there are a number - no, a lot - of cybersecurity bills in draft currently. A core element of many of these bills is the degree to which the Federal government should exert "control" over private networks and what form that control should take. In my opinion, there are many reasons for thinking that the Federal government is not well suited to such a role. One of the main reasons goes to basic accountability 101. The best example I could come up with was physical security. The CEO of a company that has no door locks, no physical security of any kind, and whose company experiences massive thefts from people wandering around their buildings would not have a job for very long. The police might help investigate the break in but they would also be the first to recommend locks and a security system. They certainly would not take over building defense.

"Oh, but cyber is different." Why, precisely? Assets are increasingly stored electronically, corporate "boundaries" include electronic ones (or should). If we think there is nothing valuable to protect on corporate networks then let's skip authentication and dispense with firewalls. Clearly, we know that data is valuable and corporations do have a responsibility to protect their own resources - they owe that to shareholders. If cyber is so "complicated" that we can't possibly secure it, one has to ask why these entities knowingly continue to double down on risk they cannot mitigate. The buck stops somewhere and it is not (primarily) at the Department of Homeland Security. Business cannot realistically have it both ways - embrace the increasing use of technology ("do more with less!") and then declaim responsibility for having done so. And just as the local police department does not have keys to local businesses -- nor do they install and monitor close circuit TV in each business to detect and prevent crime -- we ought to have sensible boundaries about who secures what.

Jargon makes people feel smart and superior, but end users and key stakeholders - including, increasingly, legislators - do not speak that jargon. If we cannot learn to de-jargon ourselves and speak in languages that our audience can understand and process, technology will continue to ensnare us instead of setting us free. I'll close with an illustration that bring together several of the themes I have been talking about: responsibility, limits, and all wrapped up in a nice, de-jargoned turn of phrase:"The LORD God took the man and put him in the Garden of Eden to work it and take care of it. And the LORD God commanded the man, "You are free to eat from any tree in the garden; but you must not eat from the tree of the knowledge of good and evil, for when you eat of it you will surely die." (Genesis 2:15-17)I wish technologists were as forthright.

* Ok, I admit, I just violated the first commandment by making surfing a god. But the North Shore when it breaks is pretty awe-inspiring, at the least.

** Not that I've ever seen a shark there. But I did see a dorsal fin pop up next to me one Saturday. It was the longest three seconds of my life until I heard the exhale of - a dolphin.

*** "Man in the gray suit" is a surfing euphemism for "shark"

**** Gone for good

***** Caught you! OCSP is the Online Certificate Status Protocol, but HAML is something I made up (Hack Attack Markup Language, by which we all craft standards-compliant security vulnerabilities so it is easier for hackers to exploit them on multiple web applications, in a standards-compliant way).

****** As far as I can tell, there is no reason to put household appliances on a network and many reasons not to. Anyway, I don't really think you need special authorization to toast bagels vs. white bread.

******* Fleet Accounting and Disbursing Center, US Pacific Fleet, if you care.

Books

Matterhorn: A Novel of the Vietnam War by Karl Marlantes

http://www.amazon.com/gp/product/080211928X/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=0979528534&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1VJP13PEV1Q4RBD3F060

It's not often I get a chance to read a book that I think will become a classic, but this is one of them. The author is a decorated Vietnam-war veteran and the "authenticity" shows. The premise is that a green 2LT is sent into the bush with his team to take and hold a territory known as "the Matterhorn." It's impossible for me to describe how gripping this book is, how real the characters are, and how invested you become in them. I would never - I hope - have the hubris to say that I understand what it was like to have been in Vietnam, but after reading this book, I feel I have been a spectator. A great, magnificent book. A Dog for All Seasons: A Memoir by Patti Sherlock

http://www.amazon.com/Dog-All-Seasons-Memoir/dp/0312577923/ref=sr_1_1?ie=UTF8&s=books&qid=1273709745&sr=1-1

Personally, I am not so hot on border collies since one of them tried herding Thunder on the Nordic trail (Thunder did not want to be herded) and I had an expensive vet bill from the border collie biting him. One reason I think leash laws are critical. But I digress.

We forget that so many dogs (mine included) are working dogs. Working dogs need something to do besides sit in a dog basket and snarf dog treats. Working dogs are also indispensable to many people (you can't really herd sheep without them). The author wrote this book about a remarkable border collie named Duncan who lived with her on a sheep ranch in eastern Idaho. A dog that was more than merely a dog. Well worth the read.

Sailing in the Wake of the Ancestors: Reviving Polynesian Voyaging by Ben Finney

http://www.amazon.com/Sailing-Wake-Ancestors-Polynesian-Excellence/dp/1581780249

The resurrection of Hebrew as a popular (i.e., not merely scholarly) language is one of the great comeback stories in history. The other is the resurrection of Polynesian voyaging. This book tells the how and the why of how a dead or dying art was recreated, and the shot in the arm it gave to Polynesian peoples, who must now - largely as a result of the work of the Polynesian Voyaging Society - be acknowledged as the greatest navigators of all time. The author does not spare the infighting that almost led to the destruction of the Polynesian Voyaging Society and the means by which it was resurrected. The happy ending is the number of Polynesian peoples who are participating in wayfinding, just as their ancestors did. (It's still amazing to me that anybody can travel thousands of miles by the stars, observing ocean currents and birds.)

Physician, Heal Thyself

Thu, 2010-07-15 04:04

"The fault, dear Brutus, is not in our stars, But in ourselves, that we are underlings." Julius Caesar (1,ii140-141)

There is in some cases a terrible - and in some cases terrifying - disconnect between technology and our larger societal ability to understand it, in particular, to understand the risks it poses and the unintended consequences of those risks. The limitations of technology are not necessarily what we think they are, either. That is, we wouldn't solve all our technology problems if only we had - more technology. No, many of the limitations are ones we create ourselves, because of our inability to understand systemic risks, and by the way we think about and talk about technology as if it were something "new" and "different," instead of recognizing patterns that have repeated themselves in other disciplines.

One of the perspective slaps to the side of the head you get when you leave the nerdified air of Silicon Valley is that large swathes of the world are not technophiles, let alone technoacolytes. By that I mean that, regardless of the benefits of technology, once you drive past Los Gatos on highway 17, most of the people you meet don't think we'd achieve world peace if only we had a standards compliant API for it. Nor for that matter does most of the world think that the Eleventh Commandment is "thou shalt honor the Lord they God, by making thy code open source." As long as I have worked in technology, I continue to find the number of technological cults and cult members to be truly astonishing. If I were a social scientist, I might observe that, having extirpated God from so much of public life, we rush to find other ways to fill the void. The last time I checked, Deuteronomy said, "I am the Lord thy God, who led you out of Israel, out of slavery. You will have no other gods before me." Technology, it should be said, is not god. More like a golden calf.

If that sounds silly, think about the number of discussions we have all had with technocult members who speak in raptured, hushed tones about (insert all that apply): cloud computing, open source, object-oriented programming, agile development, and so on. (And my personal favorite, referring to any technology as "awesome." God and the North Shore of O´ahu in winter are awesome,* everything else is merely amazing, at best.) Note: I am not denigrating any of these technological constructs, merely observing that none of them have created world peace, cured cancer, raised the dead or helped anybody lose that last pesky 10 pounds. It's just technology. Even in my happiest moments curled up with my iPhone -- which is really nice technology and has made me more efficient -- I don't expect the iPhone GPS system to help me find real direction in life.

The first limitation of technology is one we impose ourselves: we make it a god, when it isn't, and IT people the high priests, when they aren't. The reason anybody cares is because technology has substantially altered our world and, if we admit it, not always for the better. Unfortunately, when technologists make an idol out of technology, we get all the overhead that comes with creating a new religion.


  • Non-believers may be ostracized or pressured to convert.

  • Statements of opinion - or ecstatic utterances - are treated as religious tenets and therefore, not open for discussion.

  • Instead of honest disagreements, we have (literal) religious arguments.

  • We may (figuratively) burn heretics at the stake.


The result is that in many cases technology is pushed merely because it is the next path to salvation, and without any rational discussion of whether we need it and, most importantly what risks it subjects us to - and whether they can even be understood let alone mitigated. Technologists become like the snake, telling Adam and Eve they will be as God is if they take a bite, and, like Adam and Eve, we only later realize the technological apple has rendered us naked.

I should have realized this when I first moved to Silicon Valley many moons ago. I went to a party given by a friend who happened to work for a chip company that was a competitor to the company I worked for. She introduced me to a colleague who, instead of the usual "Hi, how are you, nice to meet you," glared at me and said, "we're going to kill you in MOS technology." ("Not tonight, unless you are serving hemlock," was my response.) The "technology as god" cult has been reinforced a number of times over the interim years, most recently by an entrepreneur I recently talked to who had a hard time understanding that inventing a cool new technology was not, per se, enough to get him in my door or anybody else's. While I admire his entrepreneurial gifts, unless he is solving a problem people care about and can explain, in less than 25 words, he is not going to get past the "I only want twenty minutes of your time" barrier. It's just technology. It's not (a) god. It's not even a worthy golden calf wanna be.

Another limitation of technology is linguistic. I don't mean the difference between French and German: more like the difference between English and Martian. Many technologists might as well be speaking Martian, they are so far removed from the people who need to understand what the technology can do, what it can't do, and why anybody would want to use it. End users. Customers. Legislators. Those who are legitimate stakeholders in determining whether the risks of technology usage outweigh the benefits, but who cannot do that unless technologists can make themselves understood. By way of example, I might just possibly be understood in La Jolla if I were to say to someone in the surf lineup at Windansea, **"´Auwe, aia he mano nui loa! E ku´u hoa, e hele mai!" However, I'd be far more likely to get a response if I said "Alas! There is a really big shark. Get over here, buddy!" At any rate, if I cannot deliver a warning in English, I should not then excoriate a friend (on his way to the emergency room thanks to the man in the gray suit ***) that he really needs to learn Hawaiian to avoid future shark bites.

One of the main reasons technologists cannot or will not make themselves understood is the overuse of jargon. I've never met a group of people who were more jargon happy than technologists, unless it is teenagers -- who at least grow out of it if for no other reason than that they are forced to. (I don't care a hoot about "intergenerational communication styles," if a candidate for an open headcount insists on using "BFF" and "OMG" in an interview, he/she will experience "GFG"****.) If we are honest, we admit that we use jargon not only for the sake of efficiency but to make us feel smarter and superior than those who are not in the techno-know. Jargon becomes a means to exclude people from the club, and a means to hornswoggle others if we are fortunate enough to have an audience of either true believers or one that is too embarrassed to admit what they do not know. For our part, we reason, if they are too stupid to know what OCSP and HAML***** stand for, then they are not worth the time for us to offer our explanations. Jargon is also a means to cut yourself out of the herd. Everyone wants to be the first to either invent a new buzzword or be the first to use it. I'd only just learned what the acronym APT stands for -- Advanced Persistent Threat -- and already, I have had slimy sales reps emailing me asking about what Oracle does to combat APT and do I know that they have a product that can protect against it, not to mention slice, dice and make julienne fries? (What I'd really like is a product that protects against APSRs - Annoyingly Persistent Sales Reps. Nobody has offered to sell me one yet.)

I'm not immune to the temptation. I was once in a meeting with a bunch of developers talking about security issues. After listening to the discussion, I said with great solemnity, "as I see it, we need an ITP story. In fact, we need an S-ITP story. " Everyone nodded. Finally, someone had the courage to say, "what is S-ITP?" to which I replied, "the Secure Internet Toaster Protocol." ****** We get wrapped up in our own linguistic cleverness to the point we do not always know what we are saying. How then, can we expect our constituents to understand what technology is capable of, and what it is not capable of? True, there are many other organizations or cohorts that are almost as jargon happy as we are, but few of them are tasked with the level of responsibility we have. It's not just the Marine Corps and the Three Letter Agencies that do national security: technoids do. At least when I was in the Navy, you could always look up FAADCPAC******* or other cryptic acronyms in the DICNAVAB (Dictionary of Naval Abbreviations). Good luck with that in our industry (this is where the cloud cult members insist that all I have to do is look up my acronym in the acronym cloud). The point is: I shouldn't have to.

Even God - the real one - communicated in a language his followers could understand (and wrote the rules down on tablets). Technologists won't even do that. The other thing God (or His scribes) did was tell stories. It's easier for most people to get their minds around a creation story that begins "in the beginning, the world was formless and void..." than around the Big Bang and/or quantum physics. Phrases like "Can the Ethiopian change his skin or the leopard its spots?" speaks to the fact that some things are immutable. We get it so well that the number of people who use the phrase vastly exceed the number who know where it comes from. (Jeremiah 13:23). Analogies, stories, and using examples people understand all help make the complex more simple: God is more understandable than the average technologist. No wonder most people know that they shouldn't lie, cheat, steal but we have lots of the Clueless Faithful who think it's a good idea to allow houses to talk to power plants. (What next, wireless access to life support systems? Because it is just so expensive to send a nurse into someone's room.)

On the occasions when I have had the privilege of testifying in front of Congress, I've had 5 minutes to try to help well-intended legislators do something that will make a positive difference. How far do you think I'd get if I said, "we need to deploy IpV6 broadly to fix all our cybersecurity problems" or "insecure RNGs are the bane of network encryption?" I might actually get farther if I said, "'Auwe, eia he mano nui loa! E ku'u hoa, e hele mai!" (At least, Senators Inouye and Akaka - and the rest of the state of Hawai´i delegation - might understand.) I readily admit that I am not a technologist - I don't have the in-depth knowledge that most of my team has. What I do have is the ability to ask questions until I understand the gist of - and details of - a problem, and the ability to translate the problem into terms others can understand. Without that communication, you get people suffering from avoidable shark bites because they don't speak Hawaiian. Why is it so hard for technologists to understand that if they cannot communicate, their technological acumen is worthless, even dangerous?

Maybe the reason technologists resist the use of analogies is that it would reveal that the emperor has no clothes or, more accurately, that the emperor's clothes are the same ones everyone else is wearing. By that I mean, that if we can use analogies to explain technology and technological limits, it makes it all too obvious that we already have examples we can use to, for example, craft public policy. We might be forced to admit that technology isn't the ooh, aah, gee whiz stuff we say it is, it's just the same old problems wrapped up in shiny new bits.

For example, there are a number - no, a lot - of cybersecurity bills in draft currently. A core element of many of these bills is the degree to which the Federal government should exert "control" over private networks and what form that control should take. In my opinion, there are many reasons for thinking that the Federal government is not well suited to such a role. One of the main reasons goes to basic accountability 101. The best example I could come up with was physical security. The CEO of a company that has no door locks, no physical security of any kind, and whose company experiences massive thefts from people wandering around their buildings would not have a job for very long. The police might help investigate the break in but they would also be the first to recommend locks and a security system. They certainly would not take over building defense.

"Oh, but cyber is different." Why, precisely? Assets are increasingly stored electronically, corporate "boundaries" include electronic ones (or should). If we think there is nothing valuable to protect on corporate networks then let's skip authentication and dispense with firewalls. Clearly, we know that data is valuable and corporations do have a responsibility to protect their own resources - they owe that to shareholders. If cyber is so "complicated" that we can't possibly secure it, one has to ask why these entities knowingly continue to double down on risk they cannot mitigate. The buck stops somewhere and it is not (primarily) at the Department of Homeland Security. Business cannot realistically have it both ways - embrace the increasing use of technology ("do more with less!") and then declaim responsibility for having done so. And just as the local police department does not have keys to local businesses -- nor do they install and monitor close circuit TV in each business to detect and prevent crime -- we ought to have sensible boundaries about who secures what.

Jargon makes people feel smart and superior, but end users and key stakeholders - including, increasingly, legislators - do not speak that jargon. If we cannot learn to de-jargon ourselves and speak in languages that our audience can understand and process, technology will continue to ensnare us instead of setting us free. I'll close with an illustration that bring together several of the themes I have been talking about: responsibility, limits, and all wrapped up in a nice, de-jargoned turn of phrase:

"The LORD God took the man and put him in the Garden of Eden to work it and take care of it. And the LORD God commanded the man, "You are free to eat from any tree in the garden; but you must not eat from the tree of the knowledge of good and evil, for when you eat of it you will surely die." (Genesis 2:15-17)
I wish technologists were as forthright.


* Ok, I admit, I just violated the first commandment by making surfing a god. But the North Shore when it breaks is pretty awe-inspiring, at the least.

** Not that I've ever seen a shark there. But I did see a dorsal fin pop up next to me one Saturday. It was the longest three seconds of my life until I heard the exhale of - a dolphin.

*** "Man in the gray suit" is a surfing euphemism for "shark"

**** Gone for good

***** Caught you! OCSP is the Online Certificate Status Protocol, but HAML is something I made up (Hack Attack Markup Language, by which we all craft standards-compliant security vulnerabilities so it is easier for hackers to exploit them on multiple web applications, in a standards-compliant way).

****** As far as I can tell, there is no reason to put household appliances on a network and many reasons not to. Anyway, I don't really think you need special authorization to toast bagels vs. white bread.

******* Fleet Accounting and Disbursing Center, US Pacific Fleet, if you care.


Books

Matterhorn: A Novel of the Vietnam War by Karl Marlantes

http://www.amazon.com/gp/product/080211928X/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=0979528534&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1VJP13PEV1Q4RBD3F060

It's not often I get a chance to read a book that I think will become a classic, but this is one of them. The author is a decorated Vietnam-war veteran and the "authenticity" shows. The premise is that a green 2LT is sent into the bush with his team to take and hold a territory known as "the Matterhorn." It's impossible for me to describe how gripping this book is, how real the characters are, and how invested you become in them. I would never - I hope - have the hubris to say that I understand what it was like to have been in Vietnam, but after reading this book, I feel I have been a spectator. A great, magnificent book.

A Dog for All Seasons: A Memoir
by Patti Sherlock

http://www.amazon.com/Dog-All-Seasons-Memoir/dp/0312577923/ref=sr_1_1?ie=UTF8&s=books&qid=1273709745&sr=1-1

Personally, I am not so hot on border collies since one of them tried herding Thunder on the Nordic trail (Thunder did not want to be herded) and I had an expensive vet bill from the border collie biting him. One reason I think leash laws are critical. But I digress.

We forget that so many dogs (mine included) are working dogs. Working dogs need something to do besides sit in a dog basket and snarf dog treats. Working dogs are also indispensable to many people (you can't really herd sheep without them). The author wrote this book about a remarkable border collie named Duncan who lived with her on a sheep ranch in eastern Idaho. A dog that was more than merely a dog. Well worth the read.

Sailing in the Wake of the Ancestors: Reviving Polynesian Voyaging by Ben Finney

http://www.amazon.com/Sailing-Wake-Ancestors-Polynesian-Excellence/dp/1581780249

The resurrection of Hebrew as a popular (i.e., not merely scholarly) language is one of the great comeback stories in history. The other is the resurrection of Polynesian voyaging. This book tells the how and the why of how a dead or dying art was recreated, and the shot in the arm it gave to Polynesian peoples, who must now - largely as a result of the work of the Polynesian Voyaging Society - be acknowledged as the greatest navigators of all time. The author does not spare the infighting that almost led to the destruction of the Polynesian Voyaging Society and the means by which it was resurrected. The happy ending is the number of Polynesian peoples who are participating in wayfinding, just as their ancestors did. (It's still amazing to me that anybody can travel thousands of miles by the stars, observing ocean currents and birds.)

Summer R & R

Tue, 2009-09-08 07:35

Many of us take summer vacations to indulge in some R&R. Usually, we mean "rest and relaxation" by the abbreviation. R&R can also mean "reading and reruns" for those of us of the couch potato persuasion. I've done a lot of reading this summer (more on that below) and on those evenings when I can't concentrate on a demanding book, I sack out in front of the couch and watch reruns (e.g., NCIS and Law and Order. I find I am much better at figuring out whodunnit if I already know who did it. Less mental effort, too.).

There are other summer reruns materializing in Washington, in particular a revamped version of S. 773, the Cybersecurity Act of 2009 (aka the Snowe-Rockefeller Bill, after Senators Olympia Snowe (R-Maine) and Jay Rockefeller (D-WV)). First, the disclaimers: I've written a column for Oracle Magazine on this topic so I am stealing material from myself (otherwise known as "repurposing content"). Second, I always assume that members of Congress and their staff have the best of intentions when they draft a piece of legislation. So, no evil motives are assigned to them by me nor should be imputed. This disclaimer will be especially important when I explain why the Snowe-Rockefeller rerun is, despite good intentions, not an improvement from its original version.

I've reviewed a number of bills in my years working in cybersecurity and I have seen plenty that have become laws that best fit into the "what were they thinking?" category. I therefore offer a modest proposal: members of Congress should observe just four ironclad rules when drafting cybersecurity legislation, rules that would result in better, clearer and less ambiguous legislation, which is less subject to random interpretation and/or legal challenges (e.g., on Constitutional grounds). Here they are:

1)

Set limits; don't overreach. Before writing a law, determine the problem(s) the bill is trying to solve, whether legislation will actually solve the problem(s), at what cost and with what "unintended consequences." Also, determine whether there is another remedy equally or more effective at less cost and/or reach.2)

Do no harm. The legislative remedy shouldn't kill the problem by maiming the patient. 3)

Use precise language. Vague language will be misinterpreted or - worse - lead to people spending a lot of money without knowing if they are "there." In the case of cybersecurity, vague language means lawyers are more likely to be making the security decisions for companies. Worst of all are the "no auditor left behind" security bills for the amount of work they create and expenditure they require without materially improving security.4)

Uphold our current laws and values (e.g., the Constitution).

With that in mind, here are my thoughts on the Snowe-Rockefeller rerun.

First, the draft bill calls for certification of cybersecurity professionals; however, the term "cybersecurity professionals" is not defined. What, precisely does that term cover?

Someone who is a CISO? A CSO?Someone who is a security architect?Someone who applies patches, some of which are security patches? Someone who configures any product (after all, some settings are security settings)? Someone who installs AV software on mom and pop's home computer (gee, that could include their 9-year-old son Chad, the computer whiz)? Someone who administers firewalls? Someone who does forensic analysis? What about software developers - after all, if their code is flawed, it may lead to security vulnerabilities that bypass security settings?Does it mean security researchers? What about actual hackers? (It would be an interesting consequence of this bill if, in the future, someone isn't convicted for hacking (computer trespass) but is fined because (s)he does not have a CISHP (Certified Information Security Hacking Professional) certification.)

If you cannot tell based on the information in a bill to whom it applies and what "compliance" means, the likely beneficiaries are auditors, who were already given a industry boost courtesy of the Sarbanes Oxley Act, the gold standard of the "No Auditor Left Behind" bills I mentioned and the slayer of the US IPO market. More to the point, for all the money organizations could spend getting cybersecurity professional certifications for the people who don't do anything more in security than send out the "don't forget to change your password!" notices every 90 days, they could do more that actually improves security with the same funds. Getting certifications for people who don't need them crowds our more useful activity and thus could do actual harm. The lack of a clear definition in the draft bill alone runs afoul of my ironclad rules 1, 2 and 3 (and 4, as I will show later).

There is another problem with this provision: the potential for windfall profits by some (on top of not necessarily making the problem space better and possibly making it worse). Aside from product certifications (e.g., "so-and-so is a certified professional in administering product FOO"), which vendors administer, I believe that many "cyber-certification " bodies that exist now are for profit (meaning, such a bill is a mandate to spend money). The problem is made worse if the entities are effectively granted monopoly power over certifications.

To wit, a small aside here to bash ISC(2), or more correctly, a single individual within ISC(2). I and most of my team have received the new Certified Secure Software Lifecycle Professional (CSSLP) certification. I have to say, I didn't think it was that hard to get nor do you really have to demonstrate much actual expertise in development practice. The hard part of "secure software lifecycle" is doing it, not writing about it, taking exams about it, or the like. The next thing I know, I am getting a cold call from someone who I can only construe to be a sales rep for ISC(2) telling me why everybody in Oracle should take their CSSLP training classes and get the certification.

My response was what I outlined above: I did not see the value for the money. The hard part is doing secure development, not getting a CSSLP certification and anyway, for the amount of money we'd spend to do massive CSSLP training (and by the way, we actually do secure development so I don't see the need for ISC(2) training on top of what we already do in practice or the training we provide to developers), we could do more valuable things towards, oh, actually improving Oracle product security. I'd rather improve product security than line ISC(2)'s pockets. Customers would prefer I do that, too.

In response, I received what I can only construe as a "policy threat," which was Slimy Sales Guy saying that the Defense Department was going to start requiring CSSLPs as a condition of procurement so I needed to talk to him. (Gee, I bet ISC(2)'s lobbyists were busy.) My response was "hey, good to know, because that sounds like you've been handed a monopoly by DoD, which is inherently anticompetitive - who in the IT industry made you the arbiters of what constitutes 'secure development skill?'" I also said that I would work to oppose that provision - if it exists - on public policy grounds. ISC(2)'s certification wasn't broadly enough arrived at (full disclosure: I was asked about the utility of such a certification before ISC(2) developed it and I said I did not see the need for it). More to the point, you could get a CSSLP and still work for an organization that does not (technical, secure development terminology follows) give a rat's behind about actually building secure software so who the bleep cares?

I shouldn't single ISC(2) out in the sense that a lot of entities want to get legislation passed that allows them to get government-mandated money by, say, requiring someone to get their certification, or buy their product, or use their services.* If Slimy Sales Guy does not speak for ISC(2), my apologies to them, but I did not appreciate Oracle being "shaken down" as thanks for my team being an early adopter of CSSLP.

Back to the Snowe-Rockefeller rerun: it's bad enough that one out of every five people in the US has a licensing or certification requirement for his job** but if we are going to add one more requirement and license cybersecurity professionals, then at least figure out who "cybersecurity professionals" are, why we need to do that, how we will do it and constrain the problem.

The bill compounds the vague definition of "cybersecurity professional" by requiring that "3 years after the date of enactment of this Act, it shall be unlawful for an individual who is not certified under the program to represent himself or herself as a cybersecurity professional." Why does the federal government want to directly regulate cybersecurity professionals to a degree that arguably exceeds medical licensing, professional engineers' licensing, architects' licensing and so forth? Even in professions that have licensing requirements, there are state-by-state requirements that differ (e.g., California has more stringent licensing for structural engineers because there is a requirement for seismic design in CA that other, less earthquake-prone states do not have). Also, such a hands-on role for the federal government raises real constitutional concerns. Where in the Constitution is the Federal government authority as the licensing and regulatory body for all cybersecurity? (See ironclad rule number 4.)

The draft bill also would allow the president to exert control over "critical infrastructure information systems and networks" in the event of a "national emergency" - including private networks - without defining what either of those things are, which would leave the discretion to the executive branch. I read this to mean the President would be able (in an "emergency") to exert authority over private networks based on whatever criteria he/she wants to use to declare them "critical." *** If "critical infrastructure information systems and networks" are so critical, why can't we define what they are before legislating them? Are those networks pertaining to:

Utilities? Financial services? Manufacturing? (What kind of manufacturing - someone's toy making control systems or are we talking about heavy industry?) Health care?Agriculture? Other?

I have concerns - because I am a student of history - about giving anyone too much power in what we think is a good cause and watching that power turned against us. Vague terms combined with explicit presidential authority over these ill-defined terms can be a dangerous legislative formula.

There is also a provision that requires "...real time cybersecurity status and vulnerability information of all Federal Government information systems and networks managed by the Department of Commerce, including an inventory of such, vulnerabilities of such systems and networks, and corrective action plans for those vulnerabilities..." Of course, it makes sense for any owner of a network to know what's on their network and its state of "mission readiness," which in this context could include the state of its security configuration and whether security patches have been applied. However - and I made the same comment on the first draft bill - "vulnerabilities" is not defined and there is almost no such thing as "real time vulnerability information" if "vulnerability" includes defects in software that are not publicly known and for which no workaround or patch exists. Most vendors do not provide real time vulnerability information because there is nothing that increases the risk to customers like telling them of a vulnerability with no fix (or other threat mitigation) available.

"Everybody knows what we mean" is not good enough if cybersecurity is truly a national security problem, which it clearly is. At a minimum, for purposes of this bill, "vulnerability" should be explicitly defined as either a configuration weakness or a defect in software that has been publicly disclosed and for which a patch or other remediation exists. Otherwise, someone will construe this draft bill to require vendors to notify customers about security problems with no solutions as soon as they find the problems - real time, no less. Uh, no, not going to happen.

We do not need legislation or regulation for the sake of regulation, especially when it is not clear what and who is being "regulated" and what "compliance" means and at what cost. And, most importantly, I need to be convinced that the cost of regulation - the all in cost - is worth a clear benefit and that benefit could not be derived in a better or more economical or less draconian way. Most importantly, I want this bill - or any bill - to uphold our values and specifically the values enumerated in the Constitution. Good motives are not enough to create good public policy. I truly hope the next remake of Snowe-Rockefeller is worthy of its intentions, and advances our nation's cybersecurity posture.

* Here's mine: I would like a bill passed called the Hawaiian Language Preservation Act. As part of that act, I'd like to require musicians to (in addition to paying authors of works their royalties if the work is performed in public) obtain a certification that they pronounce the lyrics of the song correctly. You won't be able to perform in public (or at least, sing Hawaiian music) unless you have a Correct Hawaiian Lyrics Pronunciation (CHLP) certification. This is a bigger problem than you would think, according to my 'ukulele teacher, Saichi (who insists we pronounce the language correctly as we sing and "good on him"). Because I am a straight up gal, I won't even be greedy - I'll just require CHLP certification for anyone publicly performing any of the Rev. Dennis Kamakahi's songs (he's written about 400 or so songs, as far as I can tell he has never written a bad song, they are very popular and often played). Now, everybody will have to come to me to get a piece of paper that asserts they can pronounce "hāwanawana" correctly (it shows up in the second verse of Koke'e). See how easy that was? I figure I can use the proceeds of my CHLP certification program to buy a house in Honolulu (and improve everyone's Hawaiian pronunciation, too).

** Source: The Dirty Dozen, more about which below.

*** A colleague who reviewed this blog entry for me raised some even scarier concerns I thought were spot-on. Consider that some elements of our country have been at "heightened alert status" since 9/11/01 (e.g., air transportation). Some networks (e.g., DoD) are being probed daily so it's conceivable that a similar "heightened alert status" for cyber could be put in place in some sectors and left "on." Would the government be able to search any records, at any time, in a sector once a (semi-permanent) cyberalert exists? It's sometimes happened that a company that works with a law enforcement entity after a cyberincident is asked for "everything": logs, machines, access to people. Perhaps an experienced person knows how to ask for the minimum information needed to investigate an incident, but the law can't require that an "experienced, reasonable person with judgment" would be the enforcement mechanism. No company wants to face having to hand over all their data, their servers and their people because of an "alert." What would the government really accomplish if every company in that sector flooded them with records? Also, would companies receive some immunity or could data obtained under an "alert" be used for another purpose by the government?

Books of the Month

I have not blogged in awhile so I am overloading the following section. I have been doing a lot of summer reading and it is hard to recommend just one book:Huckleberry Finn by Mark Twain

Ernest Hemingway declared that "All modern American literature comes from one book by Mark Twain called Huckleberry Finn." It is a classic, and that is all the more reason to read it if you haven't already and reread it if you haven't read it in awhile. It's ineffably sad and short-sighted that a lot of schools either don't have a copy or don't teach this book anymore due to the prevalence of the "n word" in the text. That is political correctness run amok, especially since Twain was an expert satirist and the most heroic character in the book is the runaway slave, Jim. If you think Twain condones slavery, you didn't read the book closely enough: no, not at all.On Wings of Trust: The Quest of Pilot Carole Leigh by Maynard D. Poland

http://www.amazon.com/Wings-Trust-Quest-Pilot-Carole/dp/1419637800

I am particularly partial to this book because it is about a friend of mine. No, she's more than that, she is a great friend of long standing (we were Navy buddies) and she was a pioneer - a P3 pilot in the Navy and then a commercial airline pilot. Carole is one of the highest integrity people I know and that shines throughout the book, never more so than in her dealing with scary emergencies in-flight - and in her not turning a blind eye when something Is Not Right. The highest compliment I could pay someone is that I would trust her with my life, and I would trust Carole with mine. It's a great (true) story about a great person.

A Moveable Feast: The Restored Edition by Ernest Hemingway

http://www.amazon.com/Moveable-Feast-Restored-Ernest-Hemingway/dp/1416591311/ref=sr_1_1?ie=UTF8&s=books&qid=1252113968&sr=1-1

A Moveable Feast has been in print for some time (and is one of my favorite books by Hemingway), but this is a new version: since the book was published posthumously and there was no "definitive manuscript," it is hard in some sections to know what Hemingway intended to write. The expanded version gives in some cases an entirely differently flavor: Hemingway comes across as much less - literary criticism term - "snotty" towards F. Scott Fitzgerald in this version. The book gives a real flavor both of Paris and the Lost Generation's place in it in the 1920s.

Baking Cakes in Kigali by Gaile Parkin

http://www.amazon.com/dp/0385343434/?tag=googhydr-20&hvadid=4024611209&ref=pd_sl_45rnacbtln_e

People who like the gentle humor of the No. 1 Ladies' Detective Agency will like this. People in Kigali come to Angel, an expert cake baker, to order cakes and as they do, they tell their stories. The book does not spare the real challenges faced in Rwanda - the devastation wrought by AIDS, for example, and yet it's a lovely, redemptive story.

The Blue Notebook by James Levine

http://www.amazon.com/Blue-Notebook-James-Levine-M-D/dp/038552871X/ref=sr_1_1?ie=UTF8&s=books&qid=1251937532&sr=1-1This is the story of a young Indian girl sold into child prostitution despite which, her spirit prevails. It is a disturbing and tragic book - and yet, extremely moving, all the more so when you realize that the author is donating the US proceeds of the book to the Center for Missing and Exploited children. A wonderful read.

The Dirty Dozen: How Twelve Supreme Court Cases Radically Expanded Government and Eroded Freedom by Robert A. Levy and William Mellor

http://www.amazon.com/Blue-Notebook-James-Levine-M-D/dp/038552871X/ref=sr_1_1?ie=UTF8&s=books&qid=1251937532&sr=1-1

This book analyzes the twelve worst decisions by the US Supreme Court and how they have affected our freedoms. You will need Maalox or a stiff gin and tonic after reading it. The concept of limited government envisioned by our founding fathers is not what we have now, and this book explains why. The erosion of freedom/expansion of government began for the most part under Franklin Roosevelt but there are some recent cases highlighted such as Kelo vs. New London, that upheld government abuse of eminent domain. At the time the book went to print DC vs. Heller (an important 2nd amendment case) had not been decided but it is mentioned in the book. I finished the book four days ago and I am still aghast at what I learned.

The Art of Racing in the Rain - by Garth Stein

http://www.amazon.com/Art-Racing-Rain/dp/B0017SWPXY

I picked this up because someone recommended it to me and I was going to spend the day on planes and in the airport. After I opened it, I could not put it down, and when I finished it, I felt I had read something wondrous. The book is about the travails in a family, told from the dog's point of view. It sounds too strange to work, but it does work, and the character Enzo (the dog) is unforgettable. He puke kapu (a sacred book).

Summer R & R

Tue, 2009-09-08 07:35


Many of us take summer vacations to indulge in some R&R. Usually, we mean "rest and relaxation" by the abbreviation. R&R can also mean "reading and reruns" for those of us of the couch potato persuasion. I've done a lot of reading this summer (more on that below) and on those evenings when I can't concentrate on a demanding book, I sack out in front of the couch and watch reruns (e.g., NCIS and Law and Order. I find I am much better at figuring out whodunnit if I already know who did it. Less mental effort, too.).

There are other summer reruns materializing in Washington, in particular a revamped version of S. 773, the Cybersecurity Act of 2009 (aka the Snowe-Rockefeller Bill, after Senators Olympia Snowe (R-Maine) and Jay Rockefeller (D-WV)). First, the disclaimers: I've written a column for Oracle Magazine on this topic so I am stealing material from myself (otherwise known as "repurposing content"). Second, I always assume that members of Congress and their staff have the best of intentions when they draft a piece of legislation. So, no evil motives are assigned to them by me nor should be imputed. This disclaimer will be especially important when I explain why the Snowe-Rockefeller rerun is, despite good intentions, not an improvement from its original version.

I've reviewed a number of bills in my years working in cybersecurity and I have seen plenty that have become laws that best fit into the "what were they thinking?" category. I therefore offer a modest proposal: members of Congress should observe just four ironclad rules when drafting cybersecurity legislation, rules that would result in better, clearer and less ambiguous legislation, which is less subject to random interpretation and/or legal challenges (e.g., on Constitutional grounds). Here they are:

1) Set limits; don't overreach. Before writing a law, determine the problem(s) the bill is trying to solve, whether legislation will actually solve the problem(s), at what cost and with what "unintended consequences." Also, determine whether there is another remedy equally or more effective at less cost and/or reach.
2) Do no harm. The legislative remedy shouldn't kill the problem by maiming the patient.
3) Use precise language. Vague language will be misinterpreted or - worse - lead to people spending a lot of money without knowing if they are "there." In the case of cybersecurity, vague language means lawyers are more likely to be making the security decisions for companies. Worst of all are the "no auditor left behind" security bills for the amount of work they create and expenditure they require without materially improving security.
4) Uphold our current laws and values (e.g., the Constitution).

With that in mind, here are my thoughts on the Snowe-Rockefeller rerun.

First, the draft bill calls for certification of cybersecurity professionals; however, the term "cybersecurity professionals" is not defined. What, precisely does that term cover?

Someone who is a CISO? A CSO?
Someone who is a security architect?
Someone who applies patches, some of which are security patches?
Someone who configures any product (after all, some settings are security settings)?
Someone who installs AV software on mom and pop's home computer (gee, that could include their 9-year-old son Chad, the computer whiz)?
Someone who administers firewalls?
Someone who does forensic analysis?
What about software developers - after all, if their code is flawed, it may lead to security vulnerabilities that bypass security settings?
Does it mean security researchers? What about actual hackers? (It would be an interesting consequence of this bill if, in the future, someone isn't convicted for hacking (computer trespass) but is fined because (s)he does not have a CISHP (Certified Information Security Hacking Professional) certification.)

If you cannot tell based on the information in a bill to whom it applies and what "compliance" means, the likely beneficiaries are auditors, who were already given a industry boost courtesy of the Sarbanes Oxley Act, the gold standard of the "No Auditor Left Behind" bills I mentioned and the slayer of the US IPO market. More to the point, for all the money organizations could spend getting cybersecurity professional certifications for the people who don't do anything more in security than send out the "don't forget to change your password!" notices every 90 days, they could do more that actually improves security with the same funds. Getting certifications for people who don't need them crowds our more useful activity and thus could do actual harm. The lack of a clear definition in the draft bill alone runs afoul of my ironclad rules 1, 2 and 3 (and 4, as I will show later).

There is another problem with this provision: the potential for windfall profits by some (on top of not necessarily making the problem space better and possibly making it worse). Aside from product certifications (e.g., "so-and-so is a certified professional in administering product FOO"), which vendors administer, I believe that many "cyber-certification " bodies that exist now are for profit (meaning, such a bill is a mandate to spend money). The problem is made worse if the entities are effectively granted monopoly power over certifications.

To wit, a small aside here to bash ISC(2), or more correctly, a single individual within ISC(2). I and most of my team have received the new Certified Secure Software Lifecycle Professional (CSSLP) certification. I have to say, I didn't think it was that hard to get nor do you really have to demonstrate much actual expertise in development practice. The hard part of "secure software lifecycle" is doing it, not writing about it, taking exams about it, or the like. The next thing I know, I am getting a cold call from someone who I can only construe to be a sales rep for ISC(2) telling me why everybody in Oracle should take their CSSLP training classes and get the certification.

My response was what I outlined above: I did not see the value for the money. The hard part is doing secure development, not getting a CSSLP certification and anyway, for the amount of money we'd spend to do massive CSSLP training (and by the way, we actually do secure development so I don't see the need for ISC(2) training on top of what we already do in practice or the training we provide to developers), we could do more valuable things towards, oh, actually improving Oracle product security. I'd rather improve product security than line ISC(2)'s pockets. Customers would prefer I do that, too.

In response, I received what I can only construe as a "policy threat," which was Slimy Sales Guy saying that the Defense Department was going to start requiring CSSLPs as a condition of procurement so I needed to talk to him. (Gee, I bet ISC(2)'s lobbyists were busy.) My response was "hey, good to know, because that sounds like you've been handed a monopoly by DoD, which is inherently anticompetitive - who in the IT industry made you the arbiters of what constitutes 'secure development skill?'" I also said that I would work to oppose that provision - if it exists - on public policy grounds. ISC(2)'s certification wasn't broadly enough arrived at (full disclosure: I was asked about the utility of such a certification before ISC(2) developed it and I said I did not see the need for it). More to the point, you could get a CSSLP and still work for an organization that does not (technical, secure development terminology follows) give a rat's behind about actually building secure software so who the bleep cares?

I shouldn't single ISC(2) out in the sense that a lot of entities want to get legislation passed that allows them to get government-mandated money by, say, requiring someone to get their certification, or buy their product, or use their services.* If Slimy Sales Guy does not speak for ISC(2), my apologies to them, but I did not appreciate Oracle being "shaken down" as thanks for my team being an early adopter of CSSLP.

Back to the Snowe-Rockefeller rerun: it's bad enough that one out of every five people in the US has a licensing or certification requirement for his job** but if we are going to add one more requirement and license cybersecurity professionals, then at least figure out who "cybersecurity professionals" are, why we need to do that, how we will do it and constrain the problem.

The bill compounds the vague definition of "cybersecurity professional" by requiring that "3 years after the date of enactment of this Act, it shall be unlawful for an individual who is not certified under the program to represent himself or herself as a cybersecurity professional." Why does the federal government want to directly regulate cybersecurity professionals to a degree that arguably exceeds medical licensing, professional engineers' licensing, architects' licensing and so forth? Even in professions that have licensing requirements, there are state-by-state requirements that differ (e.g., California has more stringent licensing for structural engineers because there is a requirement for seismic design in CA that other, less earthquake-prone states do not have). Also, such a hands-on role for the federal government raises real constitutional concerns. Where in the Constitution is the Federal government authority as the licensing and regulatory body for all cybersecurity? (See ironclad rule number 4.)

The draft bill also would allow the president to exert control over "critical infrastructure information systems and networks" in the event of a "national emergency" - including private networks - without defining what either of those things are, which would leave the discretion to the executive branch. I read this to mean the President would be able (in an "emergency") to exert authority over private networks based on whatever criteria he/she wants to use to declare them "critical." *** If "critical infrastructure information systems and networks" are so critical, why can't we define what they are before legislating them? Are those networks pertaining to:

Utilities?
Financial services?
Manufacturing? (What kind of manufacturing - someone's toy making control systems or are we talking about heavy industry?)
Health care?
Agriculture?
Other?

I have concerns - because I am a student of history - about giving anyone too much power in what we think is a good cause and watching that power turned against us. Vague terms combined with explicit presidential authority over these ill-defined terms can be a dangerous legislative formula.

There is also a provision that requires "...real time cybersecurity status and vulnerability information of all Federal Government information systems and networks managed by the Department of Commerce, including an inventory of such, vulnerabilities of such systems and networks, and corrective action plans for those vulnerabilities..." Of course, it makes sense for any owner of a network to know what's on their network and its state of "mission readiness," which in this context could include the state of its security configuration and whether security patches have been applied. However - and I made the same comment on the first draft bill - "vulnerabilities" is not defined and there is almost no such thing as "real time vulnerability information" if "vulnerability" includes defects in software that are not publicly known and for which no workaround or patch exists. Most vendors do not provide real time vulnerability information because there is nothing that increases the risk to customers like telling them of a vulnerability with no fix (or other threat mitigation) available.

"Everybody knows what we mean" is not good enough if cybersecurity is truly a national security problem, which it clearly is. At a minimum, for purposes of this bill, "vulnerability" should be explicitly defined as either a configuration weakness or a defect in software that has been publicly disclosed and for which a patch or other remediation exists. Otherwise, someone will construe this draft bill to require vendors to notify customers about security problems with no solutions as soon as they find the problems - real time, no less. Uh, no, not going to happen.

We do not need legislation or regulation for the sake of regulation, especially when it is not clear what and who is being "regulated" and what "compliance" means and at what cost. And, most importantly, I need to be convinced that the cost of regulation - the all in cost - is worth a clear benefit and that benefit could not be derived in a better or more economical or less draconian way. Most importantly, I want this bill - or any bill - to uphold our values and specifically the values enumerated in the Constitution. Good motives are not enough to create good public policy. I truly hope the next remake of Snowe-Rockefeller is worthy of its intentions, and advances our nation's cybersecurity posture.

* Here's mine: I would like a bill passed called the Hawaiian Language Preservation Act. As part of that act, I'd like to require musicians to (in addition to paying authors of works their royalties if the work is performed in public) obtain a certification that they pronounce the lyrics of the song correctly. You won't be able to perform in public (or at least, sing Hawaiian music) unless you have a Correct Hawaiian Lyrics Pronunciation (CHLP) certification. This is a bigger problem than you would think, according to my 'ukulele teacher, Saichi (who insists we pronounce the language correctly as we sing and "good on him"). Because I am a straight up gal, I won't even be greedy - I'll just require CHLP certification for anyone publicly performing any of the Rev. Dennis Kamakahi's songs (he's written about 400 or so songs, as far as I can tell he has never written a bad song, they are very popular and often played). Now, everybody will have to come to me to get a piece of paper that asserts they can pronounce "hāwanawana" correctly (it shows up in the second verse of Koke'e). See how easy that was? I figure I can use the proceeds of my CHLP certification program to buy a house in Honolulu (and improve everyone's Hawaiian pronunciation, too).

** Source: The Dirty Dozen, more about which below.

*** A colleague who reviewed this blog entry for me raised some even scarier concerns I thought were spot-on. Consider that some elements of our country have been at "heightened alert status" since 9/11/01 (e.g., air transportation). Some networks (e.g., DoD) are being probed daily so it's conceivable that a similar "heightened alert status" for cyber could be put in place in some sectors and left "on." Would the government be able to search any records, at any time, in a sector once a (semi-permanent) cyberalert exists? It's sometimes happened that a company that works with a law enforcement entity after a cyberincident is asked for "everything": logs, machines, access to people. Perhaps an experienced person knows how to ask for the minimum information needed to investigate an incident, but the law can't require that an "experienced, reasonable person with judgment" would be the enforcement mechanism. No company wants to face having to hand over all their data, their servers and their people because of an "alert." What would the government really accomplish if every company in that sector flooded them with records? Also, would companies receive some immunity or could data obtained under an "alert" be used for another purpose by the government?

Books of the Month

I have not blogged in awhile so I am overloading the following section. I have been doing a lot of summer reading and it is hard to recommend just one book:

Huckleberry Finn
by Mark Twain

Ernest Hemingway declared that "All modern American literature comes from one book by Mark Twain called Huckleberry Finn." It is a classic, and that is all the more reason to read it if you haven't already and reread it if you haven't read it in awhile. It's ineffably sad and short-sighted that a lot of schools either don't have a copy or don't teach this book anymore due to the prevalence of the "n word" in the text. That is political correctness run amok, especially since Twain was an expert satirist and the most heroic character in the book is the runaway slave, Jim. If you think Twain condones slavery, you didn't read the book closely enough: no, not at all.

On Wings of Trust: The Quest of Pilot Carole Leigh
by Maynard D. Poland

http://www.amazon.com/Wings-Trust-Quest-Pilot-Carole/dp/1419637800

I am particularly partial to this book because it is about a friend of mine. No, she's more than that, she is a great friend of long standing (we were Navy buddies) and she was a pioneer - a P3 pilot in the Navy and then a commercial airline pilot. Carole is one of the highest integrity people I know and that shines throughout the book, never more so than in her dealing with scary emergencies in-flight - and in her not turning a blind eye when something Is Not Right. The highest compliment I could pay someone is that I would trust her with my life, and I would trust Carole with mine. It's a great (true) story about a great person.

A Moveable Feast: The Restored Edition by Ernest Hemingway

http://www.amazon.com/Moveable-Feast-Restored-Ernest-Hemingway/dp/1416591311/ref=sr_1_1?ie=UTF8&s=books&qid=1252113968&sr=1-1

A Moveable Feast has been in print for some time (and is one of my favorite books by Hemingway), but this is a new version: since the book was published posthumously and there was no "definitive manuscript," it is hard in some sections to know what Hemingway intended to write. The expanded version gives in some cases an entirely differently flavor: Hemingway comes across as much less - literary criticism term - "snotty" towards F. Scott Fitzgerald in this version. The book gives a real flavor both of Paris and the Lost Generation's place in it in the 1920s.

Baking Cakes in Kigali by Gaile Parkin

http://www.amazon.com/dp/0385343434/?tag=googhydr-20&hvadid=4024611209&ref=pd_sl_45rnacbtln_e

People who like the gentle humor of the No. 1 Ladies' Detective Agency will like this. People in Kigali come to Angel, an expert cake baker, to order cakes and as they do, they tell their stories. The book does not spare the real challenges faced in Rwanda - the devastation wrought by AIDS, for example, and yet it's a lovely, redemptive story.

The Blue Notebook by James Levine

http://www.amazon.com/Blue-Notebook-James-Levine-M-D/dp/038552871X/ref=sr_1_1?ie=UTF8&s=books&qid=1251937532&sr=1-1
This is the story of a young Indian girl sold into child prostitution despite which, her spirit prevails. It is a disturbing and tragic book - and yet, extremely moving, all the more so when you realize that the author is donating the US proceeds of the book to the Center for Missing and Exploited children. A wonderful read.

The Dirty Dozen: How Twelve Supreme Court Cases Radically Expanded Government and Eroded Freedom by Robert A. Levy and William Mellor

http://www.amazon.com/Blue-Notebook-James-Levine-M-D/dp/038552871X/ref=sr_1_1?ie=UTF8&s=books&qid=1251937532&sr=1-1

This book analyzes the twelve worst decisions by the US Supreme Court and how they have affected our freedoms. You will need Maalox or a stiff gin and tonic after reading it. The concept of limited government envisioned by our founding fathers is not what we have now, and this book explains why. The erosion of freedom/expansion of government began for the most part under Franklin Roosevelt but there are some recent cases highlighted such as Kelo vs. New London, that upheld government abuse of eminent domain. At the time the book went to print DC vs. Heller (an important 2nd amendment case) had not been decided but it is mentioned in the book. I finished the book four days ago and I am still aghast at what I learned.

The Art of Racing in the Rain - by Garth Stein

http://www.amazon.com/Art-Racing-Rain/dp/B0017SWPXY

I picked this up because someone recommended it to me and I was going to spend the day on planes and in the airport. After I opened it, I could not put it down, and when I finished it, I felt I had read something wondrous. The book is about the travails in a family, told from the dog's point of view. It sounds too strange to work, but it does work, and the character Enzo (the dog) is unforgettable. He puke kapu (a sacred book).

What’s Mine Is Mine

Mon, 2009-05-11 05:15

The 2009 RSA Conference is over and it was, as always, a good chance to catch up with old friends and new trends. I was on four panels (including the Executive Security Action Forum on the Monday before RSA) and it was a pleasure to be able to discuss interesting issues with esteemed colleagues. One such panel was on the topic of cloud computing security (ours was not the only panel on that topic, needless to say). One of the biggest issues in getting the panel together was manifest at the outset when, like the famous story of 6 blind men and the elephant, everyone had a different “feel” for what cloud computing actually is.

The “what the heck is cloud computing, anyway?” definitional problem is what makes discussions of cloud computing so thorny. Some proponents of cloud computing are almost pantheists in their pronouncements. “The cloud is everything; everything is the cloud. I’m a cloud, you’re a cloud, we’re a cloud, it’s all the cloud; are in you in touch with your inner cloud?” It’s hard to even discuss cloud computing with them because you need to know what faction of the radical cult you are with to understand how they even approach the topic.

One of the reasons it is hard to debunk cloud computing theology is that the term itself is so nebulous. If by cloud computing, one means software as a service, this is nothing new (so what’s all the fuss about?). Almost as long as there have been computers, there have been people paying other people to manage the equipment and software for them using a variety of different business models. When I was in college, students got “cloud services,” in a way. You got so many computer hours at the university computer center. You’d punch out your program on a card deck, drop it off at the university computer center, someone would load the deck, and later you’d stop by, pick up your card deck and your output. Someone else managed running the program for you (loading the deck) and debited your account for the amount of computing time it took to run the program. (I know, I know, given all the power on a mere desktop these days, this reminiscence is the computing equivalent of “I walked 20 miles to school through snow drifts.” But people who remember those days also remember dropping a card deck, which was the equivalent of “the dog ate my homework” if you couldn’t literally get your cards lined up in time to turn your homework in. Ah, the good old days.)

Today, many companies run hosted applications for their customers through a variety of business models. In some cases, the servers and software are managed at a data center the service provider owns and manages (the @myplace model); in other cases, the service provider manages the software remotely, where the servers and software remain at the customer site (the @yourplace model). What both of these models have in common is knowing “what’s mine is mine.” That is, where the servers are located is not as important as the principle that a customer knows where the data is, what is being done to secure it and that “what’s mine is mine.” If you are not actually managing your own data center, you still will do due diligence – and have a well-written contract, with oversight provisions – to ensure that someone else is securing your data to your satisfaction. If it is not done to your satisfaction you either needed to write a better contract or to terminate the service contract you have for cause.

I therefore find some of the pronouncements about cloud computing to be completely ludicrous if you are talking about anything important, because you want to know a) where something is that is of value to you and b) that it is being secured appropriately. “Being secured” is not just a matter of using secure smoke and mirrors – oops, I mean, a secure cloud protocol – but a bunch of things (kind of like the famous newspaper reporting example – who, what, when, how, why and where). Maybe “whatever” also begins with a W, but nobody would accept that as an answer to the question, “It’s 11PM, do you know where your data is and who is accessing it?”

I’ve used the following example before, most recently at the 2009 RSA Conference, but it’s worth repeating here. Suppose you have a daughter named Janie, who is the light of your life. Can you imagine the following conversation when you call her day care provider at 2pm.?

You: “Where is Janie?”DCP: “Well, we aren’t really sure right now. Janie is off in the day care cloud. Somewhere. But we are sure she’ll be at the door by 5 when you come to pick her up.”

The answer is, you wouldn’t tolerate such “wherever, whatever” answers and you’d yank Janie out of there ASAP. Similarly, if your data is important, you aren’t going to be happy with a “secure like, wherever” cloud protocol.

There is another reason “the cloud is everything, everywhere” mantra is nonsense. The reality is that if the cloud is everything and everywhere, then you have to protect everything, which is simply not possible (basic military strategy 101, courtesy of Frederick II: “He who defends everything defends nothing”). It’s not even worth trying to do that. If everything is in the cloud then one of two things will happen. Either security will have to rise to that digital equivalent of Ft. Knox everywhere: if not all data is gold, some of it is and you have to protect the gold above all else. Or, security devolves to the lowest common denominator, and we are back to little Janie – nobody is going to drop off their precious jewels in some cloud where nobody is sure where they are or how they are being protected. (You might drop off the neighbor’s kid into an insecure day care cloud because he keeps teasing your cat, but not little Janie.)

One of the reasons the grandiose claims about cloud computing don’t sit well is that most people have an intuitive defensiveness about “what’s mine.” You want to know “what’s mine is mine, what’s yours is yours” and most of us don’t have megalomaniacal tendencies to claim what’s yours as mine. Nor frankly, do we generally care about “what’s yours” unless you happen to be a friend or there are commons that affect both of us (e.g., if three houses in the neighborhood get burgled, I’m more likely to join neighborhood watch since what affects my neighbor is likely to affect me, too).

I buy the idea of having someone else manage your applications because I learned at an early age you could pay people to do unpleasant things you don’t want to do for yourself. My mother reminded me of this only last weekend. When I was a 21-year-old ensign stationed in San Diego, my command had a uniform inspection in khakis. I did not like khakis and had not ever had to wear them (the particular shade of khaki the uniforms were made of at that time made everyone look as if he/she had malaria, and the material was a particularly yucky double knit). I was moaning and groaning about having to hem my khaki uniform skirt when my mother reminded me that the Navy Exchange had a tailor shop and they’d probably hem my skirt for a nominal fee (the best five dollars I ever spent, as it happens). If you don’t want to manage your applications (in business parlance, because it is not your “core competence”), you can pay someone else to do it for you. You’re not completely off the hook in that you have to substitute due diligence and contract management skills for hands-on IT skills, but this model works for a lot of people.

What I don’t buy is the idea that – for anything of value – grabbing storage or computing on the fly is a model anybody is going to want to use. A pharmaceutical company running clinical trials isn’t going to store their latest test results “somewhere, out there.” They aren’t necessarily going to rent computing power on the fly, either if the raw data itself is sensitive (how valuable would it be to a competitor to learn that new Killer Drug isn’t doing so well in clinical trials?) You want to know “what’s mine is mine, and is being protected to my verifiable satisfaction.” If it’s not terribly valuable – or, more precisely, if it is not something you mind sharing broadly - then the cloud is fine. A lot of people store their photographs on some web site somewhere which means a) if their hard drive is corrupted, they have a copy somewhere and b) it’s easier to share with lots of people – easier than emailing .JPG files around. I heard one presenter at RSA describe how his company crunched big numbers using “the power of the cloud” but he admitted that the data being crunched was already public data. So, the model that worked was “this is mine; I am happy to share,” or “this is already being shared, and is not really mine.”

Speaking of “what’s mine is mine,” I mentioned in my previous blog entry that I’d had the privilege of testifying in front of Congress in mid-March (the Homeland Security Subcommittee on Emerging Threats, Cybersecurity, Science and Technology). As I only had five minutes for my remarks, I wanted to make a few strong recommendations that I hoped would have an impact. The third of the three recommendations was that the US should invoke the Monroe Doctrine in cyberspace. (One of my co-panelists then started referring to this idea as the Davidson Doctrine, which I certainly cringe at using myself. James Monroe was the president who first invoked the doctrine that bears his name – he gets to have a major doohickey in foreign policy named after him since he was – well, The President. I am clearly not the president or even not a president, unless it is president of the Ketchum, Idaho Maunalua Fan Club.)

For those who have forgotten their history, the Monroe Doctrine – created in 1823 – was a basic enumeration that the United States had a declared sphere of influence in the Western Hemisphere, that further efforts by European governments to colonize or interfere with states in the Western Hemisphere would be viewed by the US as aggressive acts requiring US intervention. The Monroe Doctrine is one of the United States’ oldest foreign policy constructs, it has been invoked multiple times by multiple presidents (well into the 20th century), and has morphed to include other areas of intervention (the so-called Roosevelt Corollary).* In short, the Monroe Doctrine was a declared line in the sand: the United States’ way of saying “what’s mine is mine.”

My principle reason for recommending invocation of the Monroe Doctrine is that we already have foreign powers stealing intellectual property, invading our networks, probing our critical defense systems (and other critical infrastructure systems). Nobody wants to say it, but there is a war going on in cyberspace. Putting it differently, if a hostile foreign power bombed our power plants, would that be considered an act of war? If a group of (non-US) actors systemically denied us the use of critical systems by physically taking control of them, would that be considered an act of war? I am certainly not suggesting that the Monroe Doctrine should govern (if it is invoked in cyberspace) the entire doctrine of cyberwar. But it is the case that before great powers can develop doctrines of cyberwar, they need to declare what is important. “What’s mine is mine: stay out or face the consequences.”

Another incident from the RSA Conference brought this home to me. In the Q and A session after a panel I was on: a woman mentioned she had grown up during the Cold War, when it was obvious who the enemy was. Who, she asked, is the enemy now? My response was, “We aren’t actually allowed to have enemies now. Wanting to annihilate western civilization is a different, equally valid value system that needs to be respected in the interests of diversity.” This sarcastic remark went right over her head for no reason that I can fathom. It is, however, true, that a lot of people don’t want to use the term “enemy” anymore, in part because they don’t even want to acknowledge that we are at war. From what is already public knowledge, we can state honestly that we have numerous enemies attacking our interests in cyber space – from individual actors to criminal organizations to nation states – part of our problem is that because we have not developed a common understanding of what “cyber war” is, we are unable to map these enemies to appropriate responders in the same way we pair street crime up with local cops and attacks on military supply lines with the armed forces.

We need to at least begin to elucidate a larger cyberwar doctrine by declaring a sphere of influence and that messing with that will lead to retribution. Like the Monroe Doctrine, we do not need to publicly elucidate exact responses, but our planning must include specific exercises such as “if A did B, what would our likely response be, where ‘response’ could include signaling and other activities in the non-cyber world?” Nations and others do “signal” each other of intentions, which often allows others to gracefully avoid conflict escalation by reading the signals correctly and backing off.

Slight aside: there are parents more worried about their children’s self esteem than stopping their obnoxious behavior Right This Second. My mother had a great escalation protocol using signaling that I wish all the Gen-Xers, Gen-Yers and Millennials would adopt instead of “we want Johnny to feel good about being a rude brat.” Mom has not had to invoke this on the Davidson kids in several decades because she invoked it so well before we were 10:

Defcon 5 - (Child behaves himself or herself)Defcon 4 - The “look” (narrowed eyes, direct eye contact, tense body language)Defcon 3 - The hiss through clenched teethDefcon 2 - “Stop That Right This Minute Or We Are Leaving. I Mean It.” Defcon 1 - The arm pinch and premise-vacating

This was, my siblings and I can attest to, a well-established escalation protocol with predictable “payoffs” at each level. As a result, we only rarely made it to Defcon 1 (and, in defense of my mother, I richly deserved it when we did).

So, below are some thoughts I wrote up as a later expansion on my remarks to the subcommittee. Invoking the Monroe Doctrine in cyberspace is, I believe, a useful construct for approaching how we think about cybersecurity as the critical national security interest I believe it is.

Applicability of the Monroe Doctrine to Cyberspace

1. The essential truth of invoking a Cyber Monroe Doctrine is that what we are seeing in cyberspace is no different from the kinds of real-world activities and threats our nation (and all nations) have been dealing with for years; we must stop thinking cyberspace falls outside of the existing system of how we currently deal with threats, aggressive acts and appropriate responses.

Referencing the Monroe Doctrine is meant to simplify the debate while highlighting its importance. The Monroe Doctrine became an organizing principle of US foreign policy. Through the concept of the Americas sphere of influence, it publicly identified an area of national interest for the US and clearly indicated a right to defend those interests without limiting the response. Today cyberspace requires such an organizing principle to assist in prioritization of US interest. While cyberspace by its name connotes virtual worlds, we should recall that cyberspace maps to places and physical assets we care about that are clearly within the US government's remit and interest.

Conceptually, how we manage the cyber threat should be no different than how we manage various real-world threats (from domestic crime to global terrorism and acts of aggression by hostile nation-states). Just as the Monroe Doctrine compelled the US government to prioritize intercontinental threats, a Cyber Monroe Doctrine also forces the US government to prioritize: simply put, some cyber-assets are more important than others and we should prioritize protection of them accordingly. We do not treat the robbery of a corner liquor store with the same response (or same responders) as we treat an attempt to release a dirty bomb into a population center, for example. With this approach, policy makers also benefit from existing legal systems and frameworks that ensure actions are appropriate and that protect our civil liberties.

Similarly, not all European incursions into the Western hemisphere have warranted a response under the Monroe Doctrine. For example in 1831, Argentina, which claimed sovereignty over the Falkland Islands, seized three American schooners in a dispute over fishing rights. The US reacted by sending the USS Lexington, whose captain, Silas Duncan, “seized property taken from the American ships, released the American seamen, spiked the fort’s cannon, captured a number of Argentine colonists, and posted a decree that anyone interfering with American fishing rights would be considered a pirate”(The Savage Wars of Peace, Max Boot, page 46).

The territorial dispute ended in 1833 when Great Britain sent a landing party of Royal Marines to seize the Falklands. In this instance the US specifically did not respond by invoking the Monroe Doctrine; the Falklands were deemed of insufficient importance to risk a crisis with London.2. The initial and longstanding value of the Monroe Doctrine was that it sent a signal to foreign powers that the US had a territorial sphere of influence and that incursions would be met with a response. Precisely because we did not specify all possible responses in advance, the Monroe Doctrine proved very flexible (e.g., it was later modified to support other objectives).

It is understandable that the United States would have concerns about ensuring the safety of the 85% of US critical (cyber) infrastructure that is in private hands given that much of this critical infrastructure (if attacked or brought down) has a direct link to the economic well-being of the United States in addition to other damage that might result. That said, declaring a national security interest in such critical infrastructure should not mean militarizing all of it or placing it under military or other governmental control any more than the Monroe Doctrine led to colonization (“planting the flag”) or militarization (military occupation and/or permanent bases) of all of the Western hemisphere. Similarly, the US should not make a cyberspace “land grab” for the Western hemisphere, or even our domestic cyber-infrastructure.

A 21st century Cyber Monroe Doctrine would have the same primary value as the original Monroe Doctrine - a signal to others of our national interests and a readiness to action in defense of those interests. Importantly, any consideration of our cyber interests must be evaluated within the larger view of our national security concerns and our freedoms. For example, it is clear where the defacement of a government website ranks in comparison to a weapons of mass destruction (WMD) attack on a major city. All cyber-risks are not created equal nor should they have a precisely “equal” response.

Another reason to embrace a Cyber Monroe Doctrine (and the innate flexibility it engendered) is the fact that cyberspace represents a potentially “liquid battlefield.” Traditionally, wars have been fought for fixed territory whose battlefields did not dramatically expand overnight (e.g., the attack by Imperial Japan on Pearl Harbor did not overnight morph into an attack on San Francisco, Kansas City and New York City). By contrast, in cyberspace there is no “fixed” territory and thus the boundaries of what is attacked are fluid. For a hostile entity, almost any potential cybertarget is 20 microseconds away.

A Cyber Monroe Doctrine must also accommodate the fundamental architecture of the Internet. Since the value of the Internet is driven by network effects, policies that decrease the value of the Internet through (real or perceived) balkanization will harm all participants. While a Cyber Monroe Doctrine can identify specific critical cyber infrastructure of interest to the U.S., parts of the cyber infrastructure are critical to all global stakeholders. In short, even as the United States may have a cybersphere of influence, there are nonetheless cybercommons. This is all the more true as attacks or attackers move through or use the infrastructure of those cybercommons. Therefore, the US must find mechanisms to be inclusive rather than exclusive when it comes to stewardship and defense of our cybercommons.

3. Placing the critical assets we care about within a framework that maps to existing legal, policy and social structures/institutions is the shortest path to success.

For example, military bases are protected by the military, and a nation-state attack (physical or cyber) against a military base or military cyberassets should fit within a framework that can offer appropriate and proportionate responses (ranging from State Department harassment of the local embassy official, to application of kinetic force). Critical national assets (power plants, financial systems) require similar flexibility, but through engagement of the respective front-line institutions in a manner that permits escalation appropriate to the nature of the attack. Challenges

There are a number of challenges in applying a Cyber Monroe Doctrine. Below is a representative but by no means exhaustive list of them.

1. Credibility

A deterrence strategy needs teeth in it to be credible. Merely telling attackers “we are drawing a line in the sand, step over it at your peril,” without being able to back it up with an actual and proportionate response is the equivalent of moving the line in the sand repeatedly in an attempt to appear fierce while actually doing nothing. (The Chinese would rightly call such posturers “paper tigers.”) Mere words without at least the possibility of a full range of supporting actions is no deterrent at all. A credible deterrent can be established through non-military options as well - for some a sharply worded public rebuke may change behavior as much as if we were sending in the Marines.

Because the Monroe Doctrine did not detail all potential responses to provocation in advance, the United States was able to respond as it saw fit to perceived infractions of the Monroe Doctrine on multiple occasions and over much of our history. The response was measured and flexible, but there was a response.

2. Invocation Scenarios

To bolster credibility, the “teeth” part of a cyber doctrine should include a potential escalation framework and some “for instances” in which a Cyber Monroe Doctrine would be invoked. This planning activity can take place in the think tank realm, the cyber exercise realm, or a combination thereof.

We know how to do this. Specifically, military strategists routinely look at possible future war scenarios. In fact, it is not possible to do adequate military planning by waiting for an incident and only then deciding if you have the right tools, war plans, and defense capabilities to meet it, if for no other reason than military training and procurement take years and not days to implement.

Similarly, “changing the battlefield” could be one supporting activity for a Cyber Monroe Doctrine. For example, it has been argued (by Michael Oren in Power, Faith and Fantasy: America in The Middle East 1776 to the Present) that the United States only developed a strong Navy (and the centralized government that enabled it) as a result of the wars of the Barbary pirates. Similarly, the fabric of our military may change and likely will change in support of a Cyber Monroe Doctrine and that could include not only fielding new “troops” – the Marines first made a name for themselves by invading Tripoli – but new technologies to support a changed mission. One would similarly expect that a Cyber Monroe Doctrine as a policy construct would be supported by specific planning exercises instead of “shoot from the hip” responses.

3. Attribution

A complicating factor in cybersecurity is that an attack - especially if it involves infiltration/exfiltration and not a “frontal assault” (e.g., denial of service attack) - and the perpetrator of it may not be obvious. Thus two of the many challenges of cybersecurity are detecting attacks or breaches in the first place, and attributing them correctly in the second place. No one would want to initiate a response to a cyber attack if one cannot correctly target the adversary. In particular, highly reliable attribution is critical in cyberoffense, since the goal is to take out attackers or stop the attacks, not necessarily to create collateral damage by taking down systems being hijacked by attackers. Notwithstanding this challenge, “just enough attribution” may be sufficient for purposes of “shot over the bow warnings,” even if it would be insufficient for escalated forms of retaliation.

For example, in cybersecurity circles last year there were a number of discussions about the types of activities that occur when one takes electronic devices overseas (e.g., hard drives being imaged, cell phones being remotely turned on an used as listening devices) and the precautions that one should take to minimize risk. While specific countries were not singled out on one such draft document (outlining the risks and the potential mitigation of those risks), the discussion included whether such warnings should be released in advance of the Beijing Olympics. Some expressed a reluctance to issue such warnings because of the concern that it would cause China to “lose face.”

Ultimately, the concern was rendered moot since Joel Brenner, a national counterintelligence executive in the Bush Administration, otherwise made the topic public (http://blogs.computerworld.com/slurping_and_other_cyberspying_expected_at_olympics). It seems ludicrous in hindsight that the concern over making a government “feel bad” about activities that they were widely acknowledged to be doing should be greater than protecting people who did not know about those risks. (Do we warn people against walking through high crime areas at night, or are we worried that criminals might be offended if we did so?) Even when we choose to exercise diplomacy instead of countermeasures, diplomacy inevitably includes some element of “you are doing X, we’d prefer that you not do so,” if not an actual “cease and desist” signal.

The difficulty of proper attribution of non-state actors deserves specific attention because of the need for multi-stakeholder cooperation in order to identify and eliminate the threat. When an attacker resides in one location, uses resources distributed around the world, and targets a victim in yet another country, the authorities and individuals responsible for finding out who (or what) is behind the attack may only have portions of the information or resources needed to properly carry out their job. Taking a unilateral approach will at times be simply impossible, and may not offer the quickest path to success. However, working collaboratively with other governments and stakeholders not only builds our collective capacity to defend critical infrastructures around the world, but also ensures that our weakest links do not become havens for cyber criminals or terrorists.

While it can be at times harder in cyberspace to distinguish what kind of foe we face, a Cyber Monroe Doctrine will work best when we can clearly distinguish who is conducting an attack so that we can deliver the appropriate response. This is not an easy task, and will require new skill sets across the entire government to ensure cyber threats are properly categorized.

* The government of the Dominican Republic stopped payment on debts of more than $32 million to various nations, which caused President Theodore Roosevelt to invoke (and expand upon) the Monroe Doctrine to avoid having European powers come to the Western Hemisphere for the purpose of collecting debts. This expansion of the Monroe Doctrine became known as the Roosevelt Corollary

For More InformationBook of the Week

The Forgotten Man by Amity Shlaes

http://www.amazon.com/Forgotten-Man-History-Great-Depression/dp/0066211700

This is a fascinating economic history of the Depression and why Hoover’s and Roosevelt’s economic policies made the Depression worse – much worse. It’s worth reading for such gems as (quoting philosopher Wiliam Graham Sumner): "The type and formula of most schemes of philanthropy or humanitarianism is this: A and B put their heads together to decide what C shall be made to do for D. The radical vice of all these schemes, from a sociological point of view, is that C is not allowed a voice in the matter, and his position, character, and interests, as well as the ultimate effects on society through C's interests, are entirely overlooked. I call C the Forgotten Man." Roosevelt, of course, twisted this to make D the Forgotten Man. Very well written and a reminder of what disastrous government intervention in the economy looks like.

More Useful Hawaiian:Na´u keia mea. Nou kēlā mea. (This is mine. That is yours.)

More on the Monroe Doctrine:

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

About DEFCON:

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

About William Graham Sumner:

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

What’s Mine Is Mine

Mon, 2009-05-11 05:15

The 2009 RSA Conference is over and it was, as always, a good chance to catch up with old friends and new trends. I was on four panels (including the Executive Security Action Forum on the Monday before RSA) and it was a pleasure to be able to discuss interesting issues with esteemed colleagues. One such panel was on the topic of cloud computing security (ours was not the only panel on that topic, needless to say). One of the biggest issues in getting the panel together was manifest at the outset when, like the famous story of 6 blind men and the elephant, everyone had a different “feel” for what cloud computing actually is.

The “what the heck is cloud computing, anyway?” definitional problem is what makes discussions of cloud computing so thorny. Some proponents of cloud computing are almost pantheists in their pronouncements. “The cloud is everything; everything is the cloud. I’m a cloud, you’re a cloud, we’re a cloud, it’s all the cloud; are in you in touch with your inner cloud?” It’s hard to even discuss cloud computing with them because you need to know what faction of the radical cult you are with to understand how they even approach the topic.

One of the reasons it is hard to debunk cloud computing theology is that the term itself is so nebulous. If by cloud computing, one means software as a service, this is nothing new (so what’s all the fuss about?). Almost as long as there have been computers, there have been people paying other people to manage the equipment and software for them using a variety of different business models. When I was in college, students got “cloud services,” in a way. You got so many computer hours at the university computer center. You’d punch out your program on a card deck, drop it off at the university computer center, someone would load the deck, and later you’d stop by, pick up your card deck and your output. Someone else managed running the program for you (loading the deck) and debited your account for the amount of computing time it took to run the program. (I know, I know, given all the power on a mere desktop these days, this reminiscence is the computing equivalent of “I walked 20 miles to school through snow drifts.” But people who remember those days also remember dropping a card deck, which was the equivalent of “the dog ate my homework” if you couldn’t literally get your cards lined up in time to turn your homework in. Ah, the good old days.)

Today, many companies run hosted applications for their customers through a variety of business models. In some cases, the servers and software are managed at a data center the service provider owns and manages (the @myplace model); in other cases, the service provider manages the software remotely, where the servers and software remain at the customer site (the @yourplace model). What both of these models have in common is knowing “what’s mine is mine.” That is, where the servers are located is not as important as the principle that a customer knows where the data is, what is being done to secure it and that “what’s mine is mine.” If you are not actually managing your own data center, you still will do due diligence – and have a well-written contract, with oversight provisions – to ensure that someone else is securing your data to your satisfaction. If it is not done to your satisfaction you either needed to write a better contract or to terminate the service contract you have for cause.

I therefore find some of the pronouncements about cloud computing to be completely ludicrous if you are talking about anything important, because you want to know a) where something is that is of value to you and b) that it is being secured appropriately. “Being secured” is not just a matter of using secure smoke and mirrors – oops, I mean, a secure cloud protocol – but a bunch of things (kind of like the famous newspaper reporting example – who, what, when, how, why and where). Maybe “whatever” also begins with a W, but nobody would accept that as an answer to the question, “It’s 11PM, do you know where your data is and who is accessing it?”

I’ve used the following example before, most recently at the 2009 RSA Conference, but it’s worth repeating here. Suppose you have a daughter named Janie, who is the light of your life. Can you imagine the following conversation when you call her day care provider at 2pm.?

You: “Where is Janie?”
DCP: “Well, we aren’t really sure right now. Janie is off in the day care cloud. Somewhere. But we are sure she’ll be at the door by 5 when you come to pick her up.”

The answer is, you wouldn’t tolerate such “wherever, whatever” answers and you’d yank Janie out of there ASAP. Similarly, if your data is important, you aren’t going to be happy with a “secure like, wherever” cloud protocol.

There is another reason “the cloud is everything, everywhere” mantra is nonsense. The reality is that if the cloud is everything and everywhere, then you have to protect everything, which is simply not possible (basic military strategy 101, courtesy of Frederick II: “He who defends everything defends nothing”). It’s not even worth trying to do that. If everything is in the cloud then one of two things will happen. Either security will have to rise to that digital equivalent of Ft. Knox everywhere: if not all data is gold, some of it is and you have to protect the gold above all else. Or, security devolves to the lowest common denominator, and we are back to little Janie – nobody is going to drop off their precious jewels in some cloud where nobody is sure where they are or how they are being protected. (You might drop off the neighbor’s kid into an insecure day care cloud because he keeps teasing your cat, but not little Janie.)

One of the reasons the grandiose claims about cloud computing don’t sit well is that most people have an intuitive defensiveness about “what’s mine.” You want to know “what’s mine is mine, what’s yours is yours” and most of us don’t have megalomaniacal tendencies to claim what’s yours as mine. Nor frankly, do we generally care about “what’s yours” unless you happen to be a friend or there are commons that affect both of us (e.g., if three houses in the neighborhood get burgled, I’m more likely to join neighborhood watch since what affects my neighbor is likely to affect me, too).

I buy the idea of having someone else manage your applications because I learned at an early age you could pay people to do unpleasant things you don’t want to do for yourself. My mother reminded me of this only last weekend. When I was a 21-year-old ensign stationed in San Diego, my command had a uniform inspection in khakis. I did not like khakis and had not ever had to wear them (the particular shade of khaki the uniforms were made of at that time made everyone look as if he/she had malaria, and the material was a particularly yucky double knit). I was moaning and groaning about having to hem my khaki uniform skirt when my mother reminded me that the Navy Exchange had a tailor shop and they’d probably hem my skirt for a nominal fee (the best five dollars I ever spent, as it happens). If you don’t want to manage your applications (in business parlance, because it is not your “core competence”), you can pay someone else to do it for you. You’re not completely off the hook in that you have to substitute due diligence and contract management skills for hands-on IT skills, but this model works for a lot of people.

What I don’t buy is the idea that – for anything of value – grabbing storage or computing on the fly is a model anybody is going to want to use. A pharmaceutical company running clinical trials isn’t going to store their latest test results “somewhere, out there.” They aren’t necessarily going to rent computing power on the fly, either if the raw data itself is sensitive (how valuable would it be to a competitor to learn that new Killer Drug isn’t doing so well in clinical trials?) You want to know “what’s mine is mine, and is being protected to my verifiable satisfaction.” If it’s not terribly valuable – or, more precisely, if it is not something you mind sharing broadly - then the cloud is fine. A lot of people store their photographs on some web site somewhere which means a) if their hard drive is corrupted, they have a copy somewhere and b) it’s easier to share with lots of people – easier than emailing .JPG files around. I heard one presenter at RSA describe how his company crunched big numbers using “the power of the cloud” but he admitted that the data being crunched was already public data. So, the model that worked was “this is mine; I am happy to share,” or “this is already being shared, and is not really mine.”

Speaking of “what’s mine is mine,” I mentioned in my previous blog entry that I’d had the privilege of testifying in front of Congress in mid-March (the Homeland Security Subcommittee on Emerging Threats, Cybersecurity, Science and Technology). As I only had five minutes for my remarks, I wanted to make a few strong recommendations that I hoped would have an impact. The third of the three recommendations was that the US should invoke the Monroe Doctrine in cyberspace. (One of my co-panelists then started referring to this idea as the Davidson Doctrine, which I certainly cringe at using myself. James Monroe was the president who first invoked the doctrine that bears his name – he gets to have a major doohickey in foreign policy named after him since he was – well, The President. I am clearly not the president or even not a president, unless it is president of the Ketchum, Idaho Maunalua Fan Club.)

For those who have forgotten their history, the Monroe Doctrine – created in 1823 – was a basic enumeration that the United States had a declared sphere of influence in the Western Hemisphere, that further efforts by European governments to colonize or interfere with states in the Western Hemisphere would be viewed by the US as aggressive acts requiring US intervention. The Monroe Doctrine is one of the United States’ oldest foreign policy constructs, it has been invoked multiple times by multiple presidents (well into the 20th century), and has morphed to include other areas of intervention (the so-called Roosevelt Corollary).* In short, the Monroe Doctrine was a declared line in the sand: the United States’ way of saying “what’s mine is mine.”

My principle reason for recommending invocation of the Monroe Doctrine is that we already have foreign powers stealing intellectual property, invading our networks, probing our critical defense systems (and other critical infrastructure systems). Nobody wants to say it, but there is a war going on in cyberspace. Putting it differently, if a hostile foreign power bombed our power plants, would that be considered an act of war? If a group of (non-US) actors systemically denied us the use of critical systems by physically taking control of them, would that be considered an act of war? I am certainly not suggesting that the Monroe Doctrine should govern (if it is invoked in cyberspace) the entire doctrine of cyberwar. But it is the case that before great powers can develop doctrines of cyberwar, they need to declare what is important. “What’s mine is mine: stay out or face the consequences.”

Another incident from the RSA Conference brought this home to me. In the Q and A session after a panel I was on: a woman mentioned she had grown up during the Cold War, when it was obvious who the enemy was. Who, she asked, is the enemy now? My response was, “We aren’t actually allowed to have enemies now. Wanting to annihilate western civilization is a different, equally valid value system that needs to be respected in the interests of diversity.” This sarcastic remark went right over her head for no reason that I can fathom. It is, however, true, that a lot of people don’t want to use the term “enemy” anymore, in part because they don’t even want to acknowledge that we are at war. From what is already public knowledge, we can state honestly that we have numerous enemies attacking our interests in cyber space – from individual actors to criminal organizations to nation states – part of our problem is that because we have not developed a common understanding of what “cyber war” is, we are unable to map these enemies to appropriate responders in the same way we pair street crime up with local cops and attacks on military supply lines with the armed forces.

We need to at least begin to elucidate a larger cyberwar doctrine by declaring a sphere of influence and that messing with that will lead to retribution. Like the Monroe Doctrine, we do not need to publicly elucidate exact responses, but our planning must include specific exercises such as “if A did B, what would our likely response be, where ‘response’ could include signaling and other activities in the non-cyber world?” Nations and others do “signal” each other of intentions, which often allows others to gracefully avoid conflict escalation by reading the signals correctly and backing off.

Slight aside: there are parents more worried about their children’s self esteem than stopping their obnoxious behavior Right This Second. My mother had a great escalation protocol using signaling that I wish all the Gen-Xers, Gen-Yers and Millennials would adopt instead of “we want Johnny to feel good about being a rude brat.” Mom has not had to invoke this on the Davidson kids in several decades because she invoked it so well before we were 10:

Defcon 5 - (Child behaves himself or herself)
Defcon 4 - The “look” (narrowed eyes, direct eye contact, tense body language)
Defcon 3 - The hiss through clenched teeth
Defcon 2 - “Stop That Right This Minute Or We Are Leaving. I Mean It.”
Defcon 1 - The arm pinch and premise-vacating

This was, my siblings and I can attest to, a well-established escalation protocol with predictable “payoffs” at each level. As a result, we only rarely made it to Defcon 1 (and, in defense of my mother, I richly deserved it when we did).

So, below are some thoughts I wrote up as a later expansion on my remarks to the subcommittee. Invoking the Monroe Doctrine in cyberspace is, I believe, a useful construct for approaching how we think about cybersecurity as the critical national security interest I believe it is.

Applicability of the Monroe Doctrine to Cyberspace

1. The essential truth of invoking a Cyber Monroe Doctrine is that what we are seeing in cyberspace is no different from the kinds of real-world activities and threats our nation (and all nations) have been dealing with for years; we must stop thinking cyberspace falls outside of the existing system of how we currently deal with threats, aggressive acts and appropriate responses.

Referencing the Monroe Doctrine is meant to simplify the debate while highlighting its importance. The Monroe Doctrine became an organizing principle of US foreign policy. Through the concept of the Americas sphere of influence, it publicly identified an area of national interest for the US and clearly indicated a right to defend those interests without limiting the response. Today cyberspace requires such an organizing principle to assist in prioritization of US interest. While cyberspace by its name connotes virtual worlds, we should recall that cyberspace maps to places and physical assets we care about that are clearly within the US government's remit and interest.

Conceptually, how we manage the cyber threat should be no different than how we manage various real-world threats (from domestic crime to global terrorism and acts of aggression by hostile nation-states). Just as the Monroe Doctrine compelled the US government to prioritize intercontinental threats, a Cyber Monroe Doctrine also forces the US government to prioritize: simply put, some cyber-assets are more important than others and we should prioritize protection of them accordingly. We do not treat the robbery of a corner liquor store with the same response (or same responders) as we treat an attempt to release a dirty bomb into a population center, for example. With this approach, policy makers also benefit from existing legal systems and frameworks that ensure actions are appropriate and that protect our civil liberties.

Similarly, not all European incursions into the Western hemisphere have warranted a response under the Monroe Doctrine. For example in 1831, Argentina, which claimed sovereignty over the Falkland Islands, seized three American schooners in a dispute over fishing rights. The US reacted by sending the USS Lexington, whose captain, Silas Duncan, “seized property taken from the American ships, released the American seamen, spiked the fort’s cannon, captured a number of Argentine colonists, and posted a decree that anyone interfering with American fishing rights would be considered a pirate”(The Savage Wars of Peace, Max Boot, page 46).

The territorial dispute ended in 1833 when Great Britain sent a landing party of Royal Marines to seize the Falklands. In this instance the US specifically did not respond by invoking the Monroe Doctrine; the Falklands were deemed of insufficient importance to risk a crisis with London.

2. The initial and longstanding value of the Monroe Doctrine was that it sent a signal to foreign powers that the US had a territorial sphere of influence and that incursions would be met with a response. Precisely because we did not specify all possible responses in advance, the Monroe Doctrine proved very flexible (e.g., it was later modified to support other objectives).

It is understandable that the United States would have concerns about ensuring the safety of the 85% of US critical (cyber) infrastructure that is in private hands given that much of this critical infrastructure (if attacked or brought down) has a direct link to the economic well-being of the United States in addition to other damage that might result. That said, declaring a national security interest in such critical infrastructure should not mean militarizing all of it or placing it under military or other governmental control any more than the Monroe Doctrine led to colonization (“planting the flag”) or militarization (military occupation and/or permanent bases) of all of the Western hemisphere. Similarly, the US should not make a cyberspace “land grab” for the Western hemisphere, or even our domestic cyber-infrastructure.

A 21st century Cyber Monroe Doctrine would have the same primary value as the original Monroe Doctrine - a signal to others of our national interests and a readiness to action in defense of those interests. Importantly, any consideration of our cyber interests must be evaluated within the larger view of our national security concerns and our freedoms. For example, it is clear where the defacement of a government website ranks in comparison to a weapons of mass destruction (WMD) attack on a major city. All cyber-risks are not created equal nor should they have a precisely “equal” response.

Another reason to embrace a Cyber Monroe Doctrine (and the innate flexibility it engendered) is the fact that cyberspace represents a potentially “liquid battlefield.” Traditionally, wars have been fought for fixed territory whose battlefields did not dramatically expand overnight (e.g., the attack by Imperial Japan on Pearl Harbor did not overnight morph into an attack on San Francisco, Kansas City and New York City). By contrast, in cyberspace there is no “fixed” territory and thus the boundaries of what is attacked are fluid. For a hostile entity, almost any potential cybertarget is 20 microseconds away.

A Cyber Monroe Doctrine must also accommodate the fundamental architecture of the Internet. Since the value of the Internet is driven by network effects, policies that decrease the value of the Internet through (real or perceived) balkanization will harm all participants. While a Cyber Monroe Doctrine can identify specific critical cyber infrastructure of interest to the U.S., parts of the cyber infrastructure are critical to all global stakeholders. In short, even as the United States may have a cybersphere of influence, there are nonetheless cybercommons. This is all the more true as attacks or attackers move through or use the infrastructure of those cybercommons. Therefore, the US must find mechanisms to be inclusive rather than exclusive when it comes to stewardship and defense of our cybercommons.

3. Placing the critical assets we care about within a framework that maps to existing legal, policy and social structures/institutions is the shortest path to success.

For example, military bases are protected by the military, and a nation-state attack (physical or cyber) against a military base or military cyberassets should fit within a framework that can offer appropriate and proportionate responses (ranging from State Department harassment of the local embassy official, to application of kinetic force). Critical national assets (power plants, financial systems) require similar flexibility, but through engagement of the respective front-line institutions in a manner that permits escalation appropriate to the nature of the attack.

Challenges

There are a number of challenges in applying a Cyber Monroe Doctrine. Below is a representative but by no means exhaustive list of them.

1. Credibility

A deterrence strategy needs teeth in it to be credible. Merely telling attackers “we are drawing a line in the sand, step over it at your peril,” without being able to back it up with an actual and proportionate response is the equivalent of moving the line in the sand repeatedly in an attempt to appear fierce while actually doing nothing. (The Chinese would rightly call such posturers “paper tigers.”) Mere words without at least the possibility of a full range of supporting actions is no deterrent at all. A credible deterrent can be established through non-military options as well - for some a sharply worded public rebuke may change behavior as much as if we were sending in the Marines.

Because the Monroe Doctrine did not detail all potential responses to provocation in advance, the United States was able to respond as it saw fit to perceived infractions of the Monroe Doctrine on multiple occasions and over much of our history. The response was measured and flexible, but there was a response.

2. Invocation Scenarios

To bolster credibility, the “teeth” part of a cyber doctrine should include a potential escalation framework and some “for instances” in which a Cyber Monroe Doctrine would be invoked. This planning activity can take place in the think tank realm, the cyber exercise realm, or a combination thereof.

We know how to do this. Specifically, military strategists routinely look at possible future war scenarios. In fact, it is not possible to do adequate military planning by waiting for an incident and only then deciding if you have the right tools, war plans, and defense capabilities to meet it, if for no other reason than military training and procurement take years and not days to implement.

Similarly, “changing the battlefield” could be one supporting activity for a Cyber Monroe Doctrine. For example, it has been argued (by Michael Oren in Power, Faith and Fantasy: America in The Middle East 1776 to the Present) that the United States only developed a strong Navy (and the centralized government that enabled it) as a result of the wars of the Barbary pirates. Similarly, the fabric of our military may change and likely will change in support of a Cyber Monroe Doctrine and that could include not only fielding new “troops” – the Marines first made a name for themselves by invading Tripoli – but new technologies to support a changed mission. One would similarly expect that a Cyber Monroe Doctrine as a policy construct would be supported by specific planning exercises instead of “shoot from the hip” responses.

3. Attribution

A complicating factor in cybersecurity is that an attack - especially if it involves infiltration/exfiltration and not a “frontal assault” (e.g., denial of service attack) - and the perpetrator of it may not be obvious. Thus two of the many challenges of cybersecurity are detecting attacks or breaches in the first place, and attributing them correctly in the second place. No one would want to initiate a response to a cyber attack if one cannot correctly target the adversary. In particular, highly reliable attribution is critical in cyberoffense, since the goal is to take out attackers or stop the attacks, not necessarily to create collateral damage by taking down systems being hijacked by attackers. Notwithstanding this challenge, “just enough attribution” may be sufficient for purposes of “shot over the bow warnings,” even if it would be insufficient for escalated forms of retaliation.

For example, in cybersecurity circles last year there were a number of discussions about the types of activities that occur when one takes electronic devices overseas (e.g., hard drives being imaged, cell phones being remotely turned on an used as listening devices) and the precautions that one should take to minimize risk. While specific countries were not singled out on one such draft document (outlining the risks and the potential mitigation of those risks), the discussion included whether such warnings should be released in advance of the Beijing Olympics. Some expressed a reluctance to issue such warnings because of the concern that it would cause China to “lose face.”

Ultimately, the concern was rendered moot since Joel Brenner, a national counterintelligence executive in the Bush Administration, otherwise made the topic public (http://blogs.computerworld.com/slurping_and_other_cyberspying_expected_at_olympics). It seems ludicrous in hindsight that the concern over making a government “feel bad” about activities that they were widely acknowledged to be doing should be greater than protecting people who did not know about those risks. (Do we warn people against walking through high crime areas at night, or are we worried that criminals might be offended if we did so?) Even when we choose to exercise diplomacy instead of countermeasures, diplomacy inevitably includes some element of “you are doing X, we’d prefer that you not do so,” if not an actual “cease and desist” signal.

The difficulty of proper attribution of non-state actors deserves specific attention because of the need for multi-stakeholder cooperation in order to identify and eliminate the threat. When an attacker resides in one location, uses resources distributed around the world, and targets a victim in yet another country, the authorities and individuals responsible for finding out who (or what) is behind the attack may only have portions of the information or resources needed to properly carry out their job. Taking a unilateral approach will at times be simply impossible, and may not offer the quickest path to success. However, working collaboratively with other governments and stakeholders not only builds our collective capacity to defend critical infrastructures around the world, but also ensures that our weakest links do not become havens for cyber criminals or terrorists.

While it can be at times harder in cyberspace to distinguish what kind of foe we face, a Cyber Monroe Doctrine will work best when we can clearly distinguish who is conducting an attack so that we can deliver the appropriate response. This is not an easy task, and will require new skill sets across the entire government to ensure cyber threats are properly categorized.

* The government of the Dominican Republic stopped payment on debts of more than $32 million to various nations, which caused President Theodore Roosevelt to invoke (and expand upon) the Monroe Doctrine to avoid having European powers come to the Western Hemisphere for the purpose of collecting debts. This expansion of the Monroe Doctrine became known as the Roosevelt Corollary

For More Information

Book of the Week

The Forgotten Man by Amity Shlaes

http://www.amazon.com/Forgotten-Man-History-Great-Depression/dp/0066211700

This is a fascinating economic history of the Depression and why Hoover’s and Roosevelt’s economic policies made the Depression worse – much worse. It’s worth reading for such gems as (quoting philosopher Wiliam Graham Sumner): "The type and formula of most schemes of philanthropy or humanitarianism is this: A and B put their heads together to decide what C shall be made to do for D. The radical vice of all these schemes, from a sociological point of view, is that C is not allowed a voice in the matter, and his position, character, and interests, as well as the ultimate effects on society through C's interests, are entirely overlooked. I call C the Forgotten Man." Roosevelt, of course, twisted this to make D the Forgotten Man. Very well written and a reminder of what disastrous government intervention in the economy looks like.

More Useful Hawaiian:

Na´u keia mea. Nou kēlā mea
. (This is mine. That is yours.)

More on the Monroe Doctrine:

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

About DEFCON:

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

About William Graham Sumner:

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

Elk Encounters

Mon, 2009-04-27 10:55

Before I begin, e kala mai ia´u (please excuse me) for not recognizing Steve Christey of Mitre as a co-creator/co-kahuna of the SANS Top 25 Bad Programming Errors list. It was not my intent to slight Steve for his work helping get this list created, reviewed and out there. Thank you and great job, Steve!

One of the joys of living in Idaho are the number of times you have jaw dropping encounters with living creatures. One of those occasions for me occurred about six weeks ago. We’d had five inches of new snow and it was still coming down, enough so I did not want to get in the car and drive anywhere to go Nordic skiing (four wheel drive helps you get moving but does not help you stop). So I decided to just snowshoe the ridge behind my house. I hooked up the dog, “shoed” down the street and out the path between the Ketchum Cemetery and the ridge behind my house, out to the golf course. There were some large depressions that Thunder showed a particular sniffy interest in. In retrospect, I should have known what they were, coming from a family of hunters. I turned to go down to Highway 75, when what do I see peering out of the trees on the 14th green, but four large elk? The depressions were elk beds. Thunder went nuts, making noises I’ve never heard him make that I suspect was Huskynese for, “Look, meat on the hoof! Lots of it!”

I restrained Thunder from going after the elk since I know from Idaho Fish and Game that elk need to conserve their energy in winter (Fish and Game close various areas to all motorized traffic to avoid stressing the elk). But it was a stupendously sacred view, seeing these large beautiful animals tiptoeing through deep snow, with the snow coming down about them. I watched them for about a half hour and felt blessed. They hung around for about four days before moving on and I took some pictures of them. Kupaianaha (amazing).

As many critters as I see here in Idaho, I am never jaded at seeing a beautiful animal in its native habitat. (There are animals one encounters in the commute down California Highway 101, too, but they are not the kind you want to remember, being of the jerkis Californiensis driveris variety.) That said, California also has its “elk encounters.” I was once out surfing when a pod of dolphins surfaced (not really unusual; they migrate along the coast of California). A big set wave came through the surf lineup, and the dolphins decided to surf it. There were four dolphins inside the wave as it moved through the lineup. One of them leaped out of the face of the wave and over our heads. Kupaianaha (amazing).

Even if you do not live in a wilderness area, or a place where you can see beautiful creatures in their natural habitat, you can have an “elk encounter” with someone or something that leaves you reeling in amazement. I recently had the privilege of serving on the Center for Strategic and International Studies (CSIS) Cybercommission for the 44th Presidency. The commission began meeting well before the 2008 elections, with a view towards making comprehensive recommendations on what the 44th president could do to improve cybersecurity. It was a great group of people from government and industry – a number of whom are friends as well as colleagues. Among the guiding lights behind the commission were the then-chair of the Homeland Security Subcommittee for Emerging Threats, Cybersecurity and Science and Technology, Congressman Jim Langevin and the ranking subcommittee member, Congressman Mike McCaul. It was obvious from the first meeting that both men – despite being from different political parties – shared a common interest in improving cybersecurity and a genuine collegial regard for each other.

I was particular impressed by the amount of time Congressman Langevin spent with the Commission given the many other responsibilities he had as a subcommittee chair and active member of Congress. After five minutes in a room with him, you know you are dealing with someone who is a distinguished public servant – someone you’d want to represent you (not that it matters, I happen to be of the opposite political persuasion of Congressman Langevin but hey, good leadership is good leadership: he has it). I think what cemented my admiration for Congressman Langevin was his appearance on a panel the 2008 RSA conference. The moderator posed the question, what did the next president need to do to improve cybersecurity? Some other panelists (who were also members of Congress) used the opportunity not to answer the question, but as a political platform to lambaste the other party. Congressman Langevin was a notable exception. He not only maintained a professional demeanor, he went beyond the question in his response by not only talking about what the 44th president should do but added, “and here is what I think we in Congress should do.” Bravo. That experience was as amazing an elk encounter as I had in Idaho.

I was asked recently to testify in front of the Subcommittee on Emerging Threats, Cybersecurity and Science and Technology. Congressman Langevin no longer chairs the subcommittee but has moved on to other areas of interest. I mentioned to one of the subcommittee staff – who had invited me to testify - how much I admired Congressman Langevin, to which the staff member replied: “Congressman Langevin is what every American should expect from his Congressional representative: he is smart, he is fair, he wants things to be better. He is a true leader.” Amene (amen).

I contrast my experience dealing with people such as Congressman Langevin - who are true leaders of note - with what can only be construed as the self indulgent time sink known as Twitter. The best adjective I have heard to describe people who think their every waking moment worthy of a following is “narcissistic attention deficit disorder.” (Credit to Ted Tanner for that.) Twitter is merely the latest incarnation of “look at me” exhibitionism that constitutes so much of social networking. Disclosure: I am on Facebook (which I did primarily as market research for the book my sister and I wrote*) and I am – ugh – considering joining Twitter for the same reason. Our protagonist is a twenty something techie which means I need to know about what twenty something techies are up to. That said, my definition of Twitter success will be that I have no stalkers…er…followers.

It’s hard to characterize just what I find so noxious about Twitter but I think it has a lot to do with the escalation of the trivial over the timeless (or at least, the trivial over the time-worthy). Aside from everything else, constantly telling your friends what you are up to (or obsessively checking in the activities of others) leads to what economists call a “crowding out effect.” Anybody who has spent hours on the Internet and wondered what they had to show for it afterwards knows exactly what I am talking about. For those who proudly brag about how much they can do at once, the reality is, we actually can’t multitask (reference: Why We Make Mistakes: How We Look Without Seeing, Forget Things in Seconds, and Are All Pretty Sure We Are Way Above Average by Joseph Hallinan) “Multitasking” should be better renamed “multimistaking” since the more you try to do two or more things at once, the greater the chances that you will get all of them wrong. Try playing a musical instrument and watching the news at the same time – you won’t learn Ahe Lau Makani and you will not be able to tell anybody what the headline news was, either. I know this from extensive market research. It’s true if you are trying to learn Wai O Ke Aniani and watching NCIS reruns, too. So, trying to do anything meaningful while acting like a twit – er, sending or reading tweets – is a waste of time.

Not to mention, how interesting is all this information, really? Try writing down what you really do most of the day and ask yourself, “Who else could possibly be interested in this?” To quote the title of a current movie, He’s Just Not That Into You. Actually, you shouldn’t be that into you, either.

I do occasional update my Facebook entry (which is pretty Spartan and I intend to keep it that way). Very rarely do I put an entry in “What are you doing now?” for the reason that most of what I am doing right now – in fact, most of what most of us are doing right now - is just not that interesting. Who really wants to read:

I’m changing the toilet paper roll.I’m defragmenting my hard drive.I’m writing a thank you note that is two weeks overdue. (OK, my mom would want to know that; she brought us up to write thank you notes, but who else cares?)I’m cleaning the tile grout in my kitchen.I’m trying to clean the beams in my living room because it looks like I am running a spider sanctuary.I’m sewing up one of Thunder’s many destroyed toys right now. (AWWWW. I mean, of course that is not interesting to anybody except me and the pooch. I was almost seduced by the Dark Side there for a minute.)

Who cares?

A surprising amount of most of our days are taken up with activities that we find boring and repetitive, and most sane people would, too. The only thing worse than updating your Facebook What Are You Doing Now? With such drivel is blasting it out to a bunch of groupies who breathlessly await your pronouncement on what grout cleaner to use. Oh wait, that’s Twitter.

To give an example of crowding out and why we should care, consider the recent stimulus and budget bills. Regardless of what you think of them, what ought to upset anybody is the thought of members of Congress twittering away during hearings on these bills. (Let alone people who voted on them without reading the entire bill, considering the amount of money being spent.) It is just astonishing – no, disgusting to me – that anybody would vote for such critical bills without both reading them and – most importantly - paying attention during hearings. You can’t pay attention to what someone is saying if you are obsessively texting, tweeting, checking voicemail, playing solitaire, whatever.

I recently read through the proposed Snowe-Rockefeller Bill (aka Cybersecurity Act of 2009). I had seven pages of comments on it I wrote up for our government affairs group who are sharing the comments with others in industry. I had stress pains in my shoulders from reading this bill for reasons I will perhaps save for another blog entry, but I read it, all the way through. It took awhile, I admit.

Among other concerns I have was the fact that the term “vulnerability” was not defined. Why you should care is that the bill called for real time notification of “vulnerabilities” and yet it was not clear whether a vulnerability is a configuration weakness or an actual product defect. There’s a big difference. Configuration settings you can check real time. It’s not a reasonable requirement to expect real-time notification of product vulnerabilities that may or may not have been fixed yet. That is, vendors – well, at least Oracle – find the vast majority of product security defects ourselves. That’s a good thing. As for “real time notification,” we are not prepared to Tweet everybody and say, “Hey, guess what? We found a really nasty security vulnerability two seconds ago. Oops, forgot to mention, no fix for it yet. Bummer about that but stay tuned!” I can’t imagine that’s what the bill really meant to say (“notify real time when you find a product problem whether or not it is fixed yet”), but absent a definition of “vulnerability” it is not at all clear. When it comes to contracts and legislation, any ill-defined term not only can be but will be misinterpreted, which means nobody will be able to tell whether they are in compliance, despite spending (technical public policy term here, with apologies to Carl Sagan) “beelions and beelions” of dollars trying to be compliant. If someone does not (at the very least) define “vulnerability,” they might was well rename this bill the “Auditors Full Employment Act” because only people auditing such an ill-defined notion of “compliance” could be happy with it.

You really hope that the people who put legislation together – including this bill – and vote on it are going to take the time to focus on it instead of frittering or twittering away when important matters are being discussed. Similarly, those of us who review and comment on legislation should turn off our cell phones, shut down our instant messaging, take the headphones out and concentrate on what is being proposed. I might have had some Hawaiian music playing – which soothed my stress pains – but I took the phones off the hook and really read the bill. I felt something this important to industry deserved my best review efforts.Back to elk encounters, it actually isn’t that hard to tell the difference between an elk and a deer. I’d say “everybody knows that” but there are people who probably see an elk and think it’s just a biggish deer. I like seeing deer, too, but elk encounters are more rare – and somehow more – uplifting. Elk are mindblowing. Deer are – beautiful, but not jaw dropping the way an elk encounter is. Which brings me to a last thought. Someone has done a Wikipedia entry on me (the link to which I am not including here as it is entirely too self-referential). A member of my team sent me the link: I did not Google myself. I found the entire entry rather creepy on two levels. One is, I suppose someone could put all that together from things like my blog entries, but it is still creepy to see so much about yourself pieced together online. The second point is more important: I’m not that interesting. I can understand a Wikipedia entry about Larry Ellison. Maybe even a couple other kahunas at Oracle. But me – naw. To re-reference He’s Just Not That Into You: well, I’m just not that into me and nobody else should be, either. Go find an elk.

* As I blogged about earlier (Tahiti Rising), my sister and were writing - and now have written - a book together, an IT murder mystery called Outsourcing Murder. We are on our second book and looking for an agent. As part of submitting our manuscript, I obsessively went through every Hawaiian word in the book and replaced the apostrophe with the ‘ōkina (the reverse apostrophe representing a glottal stop), which is why this entry has “Hawai´i” and not “Hawai’i.”

Book of the Week

I couldn’t just pick one so I have two recommendations.

A Dawn Like Thunder: The True Story of Torpedo Squadron Eight by Robert J. Mrazek

http://www.amazon.com/exec/obidos/ASIN/0316021393/bookstorenow96-20

I thought I had read just about everything in popular print about the battle of Midway, but this is a new take on it. More specifically, it describes the story of the famed Torpedo Squadron 8 from the U.S.S. Hornet, most of whom perished in low-level torpedo bombing of the Japanese fleet. What I had not known was that some members of Torpedo 8 actually flew from Midway, and that Torpedo 8 also figured prominently in the so-called Cactus Air Force flying from Henderson Field at the battle of Guadalcanal. It’s a gripping read and I shall forever be grateful to Robert Mrajek for telling us who these men were, what they stood for, and what they lived, loved and died for. Kupaianaha (amazing).

Honolulu by Alan Brennert

http://www.amazon.com/Honolulu-Alan-Brennert/dp/0312360401/ref=sr_1_1?ie=UTF8&s=books&qid=1240068572&sr=1-1I tend not to read a lot of contemporary fiction since so much in unrelievedly dreary and lacking in any concept of redemption. I have not even finished this book, yet I am totally captivated by it. It’s the story of a Korean “picture bride” who comes to Honolulu in the early 1900s. Brennert skillfully weaves a number of real characters into the book, including May Thompson (the inspiration for Somerset Maugham’s character Sadie Thompson) and Detective Chang Apana (the real Charlie Chan). Alan Brennert also wrote Moloka´i, another great read, about the victims of Hansen’s disease (also referred to as “leprosy” but I refer to use the correct medical - and less stigmatic – term) who were forced to live at Kalaupapa: surely one of the most beautiful yet saddest places in the world.

For More Information

About Congressman Jim Langevin:

http://langevin.house.gov/

About the CSIS Cybercommission:

http://www.csis.org/tech/cyber/

About the Subcommittee on Emerging Threats, Cybersecurity and Science and Technology:

http://homeland.house.gov/about/subcommittees.asp?subcommittee=12

My testimony in front of the Subcommittee:

http://homeland.house.gov/SiteDocuments/20090310143850-78976.pdf

Why We Make Mistakes: How We Look Without Seeing, Forget Things in Seconds, and Are All Pretty Sure We Are Way Above Average by Joseph Hallinan

http://www.google.com/search?hl=en&q=black+hat+las+vegas&btnG=Google+Search&aq=0&oq=black+hat++las+veApropos of nothing except linguistically showing off. A few Hawaiian phrases for your sled dog:

Don’t pull me over! (Mai huki malalo ia´u!)

Balto never stopped to sniff. (A´ole loa ‘o Palako i pau e honi.)

That chihuahua can take you. (Hiki i kēlā chihauhua ke make iā’oe.)

Cold enough for you? (Lawa ke ‘anuanu? )

Mush! (E hele aku ‘oe!)

Stop! (E pau ‘oe!)

Right this minute! (I kēia manawa!)

Who’s a good boy? (‘O wai he keikikāne maika´i?)

Tired? (Ua māluhiluhi ‘oe?)

Want to make a doggy snow angel? (Mamake ‘oe e hana i ´anela hau ‘ilio?)

More silly Hawaiian phrases from Keola Beamer, a great Hawaiian musician (Sweet Maui Moon is one of my favorite CDs). Wonderful gems such as:

I am filled with admiration for my in-flight meal. Kahaha ko'u na'au i ke 'ano o ka mea 'ai ma keia mokulele.http://www.kbeamer.com/bent.html

One of the Hawaiian news stations has a daily broadcast segment in Hawaiian. Very cool. You find out things like one of the high school football coaches coaches his team entirely in Hawaiian. E ola mau ka ‘ōlelo Hawai´i (may the language of Hawai´i live).

http://kgmb9.com/main/content/blogcategory/41/173/

One of my all time favorite Hawaiian meles performed by one of my all time favorite groups, Maunalua (Hawaiian slack key at its best):

http://www.youtube.com/watch?v=JljKcejktRI&feature=related

Mānoa DNA performing Ka Nohona Pili Kai:

http://www.youtube.com/watch?v=5acGxkQ2qVM

And Manoa DNA doing Makee ´Ailana

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

Elk Encounters

Mon, 2009-04-27 10:55

Before I begin, e kala mai ia´u (please excuse me) for not recognizing Steve Christey of Mitre as a co-creator/co-kahuna of the SANS Top 25 Bad Programming Errors list. It was not my intent to slight Steve for his work helping get this list created, reviewed and out there. Thank you and great job, Steve!

One of the joys of living in Idaho are the number of times you have jaw dropping encounters with living creatures. One of those occasions for me occurred about six weeks ago. We’d had five inches of new snow and it was still coming down, enough so I did not want to get in the car and drive anywhere to go Nordic skiing (four wheel drive helps you get moving but does not help you stop). So I decided to just snowshoe the ridge behind my house. I hooked up the dog, “shoed” down the street and out the path between the Ketchum Cemetery and the ridge behind my house, out to the golf course. There were some large depressions that Thunder showed a particular sniffy interest in. In retrospect, I should have known what they were, coming from a family of hunters. I turned to go down to Highway 75, when what do I see peering out of the trees on the 14th green, but four large elk? The depressions were elk beds. Thunder went nuts, making noises I’ve never heard him make that I suspect was Huskynese for, “Look, meat on the hoof! Lots of it!”

I restrained Thunder from going after the elk since I know from Idaho Fish and Game that elk need to conserve their energy in winter (Fish and Game close various areas to all motorized traffic to avoid stressing the elk). But it was a stupendously sacred view, seeing these large beautiful animals tiptoeing through deep snow, with the snow coming down about them. I watched them for about a half hour and felt blessed. They hung around for about four days before moving on and I took some pictures of them. Kupaianaha (amazing).

As many critters as I see here in Idaho, I am never jaded at seeing a beautiful animal in its native habitat. (There are animals one encounters in the commute down California Highway 101, too, but they are not the kind you want to remember, being of the jerkis Californiensis driveris variety.) That said, California also has its “elk encounters.” I was once out surfing when a pod of dolphins surfaced (not really unusual; they migrate along the coast of California). A big set wave came through the surf lineup, and the dolphins decided to surf it. There were four dolphins inside the wave as it moved through the lineup. One of them leaped out of the face of the wave and over our heads. Kupaianaha (amazing).

Even if you do not live in a wilderness area, or a place where you can see beautiful creatures in their natural habitat, you can have an “elk encounter” with someone or something that leaves you reeling in amazement. I recently had the privilege of serving on the Center for Strategic and International Studies (CSIS) Cybercommission for the 44th Presidency. The commission began meeting well before the 2008 elections, with a view towards making comprehensive recommendations on what the 44th president could do to improve cybersecurity. It was a great group of people from government and industry – a number of whom are friends as well as colleagues. Among the guiding lights behind the commission were the then-chair of the Homeland Security Subcommittee for Emerging Threats, Cybersecurity and Science and Technology, Congressman Jim Langevin and the ranking subcommittee member, Congressman Mike McCaul. It was obvious from the first meeting that both men – despite being from different political parties – shared a common interest in improving cybersecurity and a genuine collegial regard for each other.

I was particular impressed by the amount of time Congressman Langevin spent with the Commission given the many other responsibilities he had as a subcommittee chair and active member of Congress. After five minutes in a room with him, you know you are dealing with someone who is a distinguished public servant – someone you’d want to represent you (not that it matters, I happen to be of the opposite political persuasion of Congressman Langevin but hey, good leadership is good leadership: he has it). I think what cemented my admiration for Congressman Langevin was his appearance on a panel the 2008 RSA conference. The moderator posed the question, what did the next president need to do to improve cybersecurity? Some other panelists (who were also members of Congress) used the opportunity not to answer the question, but as a political platform to lambaste the other party. Congressman Langevin was a notable exception. He not only maintained a professional demeanor, he went beyond the question in his response by not only talking about what the 44th president should do but added, “and here is what I think we in Congress should do.” Bravo. That experience was as amazing an elk encounter as I had in Idaho.

I was asked recently to testify in front of the Subcommittee on Emerging Threats, Cybersecurity and Science and Technology. Congressman Langevin no longer chairs the subcommittee but has moved on to other areas of interest. I mentioned to one of the subcommittee staff – who had invited me to testify - how much I admired Congressman Langevin, to which the staff member replied: “Congressman Langevin is what every American should expect from his Congressional representative: he is smart, he is fair, he wants things to be better. He is a true leader.” Amene (amen).

I contrast my experience dealing with people such as Congressman Langevin - who are true leaders of note - with what can only be construed as the self indulgent time sink known as Twitter. The best adjective I have heard to describe people who think their every waking moment worthy of a following is “narcissistic attention deficit disorder.” (Credit to Ted Tanner for that.) Twitter is merely the latest incarnation of “look at me” exhibitionism that constitutes so much of social networking. Disclosure: I am on Facebook (which I did primarily as market research for the book my sister and I wrote*) and I am – ugh – considering joining Twitter for the same reason. Our protagonist is a twenty something techie which means I need to know about what twenty something techies are up to. That said, my definition of Twitter success will be that I have no stalkers…er…followers.

It’s hard to characterize just what I find so noxious about Twitter but I think it has a lot to do with the escalation of the trivial over the timeless (or at least, the trivial over the time-worthy). Aside from everything else, constantly telling your friends what you are up to (or obsessively checking in the activities of others) leads to what economists call a “crowding out effect.” Anybody who has spent hours on the Internet and wondered what they had to show for it afterwards knows exactly what I am talking about. For those who proudly brag about how much they can do at once, the reality is, we actually can’t multitask (reference: Why We Make Mistakes: How We Look Without Seeing, Forget Things in Seconds, and Are All Pretty Sure We Are Way Above Average by Joseph Hallinan) “Multitasking” should be better renamed “multimistaking” since the more you try to do two or more things at once, the greater the chances that you will get all of them wrong. Try playing a musical instrument and watching the news at the same time – you won’t learn Ahe Lau Makani and you will not be able to tell anybody what the headline news was, either. I know this from extensive market research. It’s true if you are trying to learn Wai O Ke Aniani and watching NCIS reruns, too. So, trying to do anything meaningful while acting like a twit – er, sending or reading tweets – is a waste of time.

Not to mention, how interesting is all this information, really? Try writing down what you really do most of the day and ask yourself, “Who else could possibly be interested in this?” To quote the title of a current movie, He’s Just Not That Into You. Actually, you shouldn’t be that into you, either.

I do occasional update my Facebook entry (which is pretty Spartan and I intend to keep it that way). Very rarely do I put an entry in “What are you doing now?” for the reason that most of what I am doing right now – in fact, most of what most of us are doing right now - is just not that interesting. Who really wants to read:

I’m changing the toilet paper roll.
I’m defragmenting my hard drive.
I’m writing a thank you note that is two weeks overdue. (OK, my mom would want to know that; she brought us up to write thank you notes, but who else cares?)
I’m cleaning the tile grout in my kitchen.
I’m trying to clean the beams in my living room because it looks like I am running a spider sanctuary.
I’m sewing up one of Thunder’s many destroyed toys right now. (AWWWW. I mean, of course that is not interesting to anybody except me and the pooch. I was almost seduced by the Dark Side there for a minute.)

Who cares?

A surprising amount of most of our days are taken up with activities that we find boring and repetitive, and most sane people would, too. The only thing worse than updating your Facebook What Are You Doing Now? With such drivel is blasting it out to a bunch of groupies who breathlessly await your pronouncement on what grout cleaner to use. Oh wait, that’s Twitter.

To give an example of crowding out and why we should care, consider the recent stimulus and budget bills. Regardless of what you think of them, what ought to upset anybody is the thought of members of Congress twittering away during hearings on these bills. (Let alone people who voted on them without reading the entire bill, considering the amount of money being spent.) It is just astonishing – no, disgusting to me – that anybody would vote for such critical bills without both reading them and – most importantly - paying attention during hearings. You can’t pay attention to what someone is saying if you are obsessively texting, tweeting, checking voicemail, playing solitaire, whatever.

I recently read through the proposed Snowe-Rockefeller Bill (aka Cybersecurity Act of 2009). I had seven pages of comments on it I wrote up for our government affairs group who are sharing the comments with others in industry. I had stress pains in my shoulders from reading this bill for reasons I will perhaps save for another blog entry, but I read it, all the way through. It took awhile, I admit.

Among other concerns I have was the fact that the term “vulnerability” was not defined. Why you should care is that the bill called for real time notification of “vulnerabilities” and yet it was not clear whether a vulnerability is a configuration weakness or an actual product defect. There’s a big difference. Configuration settings you can check real time. It’s not a reasonable requirement to expect real-time notification of product vulnerabilities that may or may not have been fixed yet. That is, vendors – well, at least Oracle – find the vast majority of product security defects ourselves. That’s a good thing. As for “real time notification,” we are not prepared to Tweet everybody and say, “Hey, guess what? We found a really nasty security vulnerability two seconds ago. Oops, forgot to mention, no fix for it yet. Bummer about that but stay tuned!” I can’t imagine that’s what the bill really meant to say (“notify real time when you find a product problem whether or not it is fixed yet”), but absent a definition of “vulnerability” it is not at all clear. When it comes to contracts and legislation, any ill-defined term not only can be but will be misinterpreted, which means nobody will be able to tell whether they are in compliance, despite spending (technical public policy term here, with apologies to Carl Sagan) “beelions and beelions” of dollars trying to be compliant. If someone does not (at the very least) define “vulnerability,” they might was well rename this bill the “Auditors Full Employment Act” because only people auditing such an ill-defined notion of “compliance” could be happy with it.

You really hope that the people who put legislation together – including this bill – and vote on it are going to take the time to focus on it instead of frittering or twittering away when important matters are being discussed. Similarly, those of us who review and comment on legislation should turn off our cell phones, shut down our instant messaging, take the headphones out and concentrate on what is being proposed. I might have had some Hawaiian music playing – which soothed my stress pains – but I took the phones off the hook and really read the bill. I felt something this important to industry deserved my best review efforts.

Back to elk encounters, it actually isn’t that hard to tell the difference between an elk and a deer. I’d say “everybody knows that” but there are people who probably see an elk and think it’s just a biggish deer. I like seeing deer, too, but elk encounters are more rare – and somehow more – uplifting. Elk are mindblowing. Deer are – beautiful, but not jaw dropping the way an elk encounter is. Which brings me to a last thought. Someone has done a Wikipedia entry on me (the link to which I am not including here as it is entirely too self-referential). A member of my team sent me the link: I did not Google myself. I found the entire entry rather creepy on two levels. One is, I suppose someone could put all that together from things like my blog entries, but it is still creepy to see so much about yourself pieced together online. The second point is more important: I’m not that interesting. I can understand a Wikipedia entry about Larry Ellison. Maybe even a couple other kahunas at Oracle. But me – naw. To re-reference He’s Just Not That Into You: well, I’m just not that into me and nobody else should be, either. Go find an elk.

* As I blogged about earlier (Tahiti Rising), my sister and were writing - and now have written - a book together, an IT murder mystery called Outsourcing Murder. We are on our second book and looking for an agent. As part of submitting our manuscript, I obsessively went through every Hawaiian word in the book and replaced the apostrophe with the ‘ōkina (the reverse apostrophe representing a glottal stop), which is why this entry has “Hawai´i” and not “Hawai’i.”

Book of the Week

I couldn’t just pick one so I have two recommendations.

A Dawn Like Thunder: The True Story of Torpedo Squadron Eight by Robert J. Mrazek

http://www.amazon.com/exec/obidos/ASIN/0316021393/bookstorenow96-20

I thought I had read just about everything in popular print about the battle of Midway, but this is a new take on it. More specifically, it describes the story of the famed Torpedo Squadron 8 from the U.S.S. Hornet, most of whom perished in low-level torpedo bombing of the Japanese fleet. What I had not known was that some members of Torpedo 8 actually flew from Midway, and that Torpedo 8 also figured prominently in the so-called Cactus Air Force flying from Henderson Field at the battle of Guadalcanal. It’s a gripping read and I shall forever be grateful to Robert Mrajek for telling us who these men were, what they stood for, and what they lived, loved and died for. Kupaianaha (amazing).

Honolulu by Alan Brennert

http://www.amazon.com/Honolulu-Alan-Brennert/dp/0312360401/ref=sr_1_1?ie=UTF8&s=books&qid=1240068572&sr=1-1

I tend not to read a lot of contemporary fiction since so much in unrelievedly dreary and lacking in any concept of redemption. I have not even finished this book, yet I am totally captivated by it. It’s the story of a Korean “picture bride” who comes to Honolulu in the early 1900s. Brennert skillfully weaves a number of real characters into the book, including May Thompson (the inspiration for Somerset Maugham’s character Sadie Thompson) and Detective Chang Apana (the real Charlie Chan). Alan Brennert also wrote Moloka´i, another great read, about the victims of Hansen’s disease (also referred to as “leprosy” but I refer to use the correct medical - and less stigmatic – term) who were forced to live at Kalaupapa: surely one of the most beautiful yet saddest places in the world.

For More Information

About Congressman Jim Langevin:

http://langevin.house.gov/

About the CSIS Cybercommission:

http://www.csis.org/tech/cyber/

About the Subcommittee on Emerging Threats, Cybersecurity and Science and Technology:

http://homeland.house.gov/about/subcommittees.asp?subcommittee=12

My testimony in front of the Subcommittee:

http://homeland.house.gov/SiteDocuments/20090310143850-78976.pdf

Why We Make Mistakes: How We Look Without Seeing, Forget Things in Seconds, and Are All Pretty Sure We Are Way Above Average by Joseph Hallinan

http://www.google.com/search?hl=en&q=black+hat+las+vegas&btnG=Google+Search&aq=0&oq=black+hat++las+ve

Apropos of nothing except linguistically showing off. A few Hawaiian phrases for your sled dog:

Don’t pull me over! (Mai huki malalo ia´u!)

Balto never stopped to sniff. (A´ole loa ‘o Palako i pau e honi.)

That chihuahua can take you. (Hiki i kēlā chihauhua ke make iā’oe.)

Cold enough for you? (Lawa ke ‘anuanu? )

Mush! (E hele aku ‘oe!)

Stop! (E pau ‘oe!)

Right this minute! (I kēia manawa!)

Who’s a good boy? (‘O wai he keikikāne maika´i?)

Tired? (Ua māluhiluhi ‘oe?)

Want to make a doggy snow angel? (Mamake ‘oe e hana i ´anela hau ‘ilio?)

More silly Hawaiian phrases from Keola Beamer, a great Hawaiian musician (Sweet Maui Moon is one of my favorite CDs). Wonderful gems such as:

I am filled with admiration for my in-flight meal.
Kahaha ko'u na'au i ke 'ano o ka mea 'ai ma keia mokulele.

http://www.kbeamer.com/bent.html

One of the Hawaiian news stations has a daily broadcast segment in Hawaiian. Very cool. You find out things like one of the high school football coaches coaches his team entirely in Hawaiian. E ola mau ka ‘ōlelo Hawai´i (may the language of Hawai´i live).

http://kgmb9.com/main/content/blogcategory/41/173/

One of my all time favorite Hawaiian meles performed by one of my all time favorite groups, Maunalua (Hawaiian slack key at its best):

http://www.youtube.com/watch?v=JljKcejktRI&feature=related

Mānoa DNA performing Ka Nohona Pili Kai:

http://www.youtube.com/watch?v=5acGxkQ2qVM

And Manoa DNA doing Makee ´Ailana

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

Loose Dogs

Sat, 2009-02-07 04:50

As I write this, I am nursing a couple of bruises I incurred skijouring with my dog Thunder. Skijouring is Nordic skiing with your dog hooked up to a lead, so he pulls you. I believe the word “skijour” comes from the Norwegian word for “cheating,” judging by the dirty looks I get from other Nordic skiers when Thunder zooms past them towing me. Mind you, Thunder has two speeds: flat out and conked out. Periodically, he stops in the middle of a run to jump into a snow bank, do a “doggy snow angel” and cool off, or check out some other dog’s calling card. You get used to using the fast-braking snowplow since I know from experience it is no fun to reach the end of the tether at high speed: it leads to a Nordic skiing move known as a “face plant.”

I Nordic ski a lot, hooked up to Thunder most of the time though I typically do a few kilometers by myself because otherwise he is the only one getting aerobic exercise. The biggest hazard for me in Nordic skiing (which does not normally carry the risks alpine skiing does) is from what I call LLDS – loose, loutish dog syndrome. That is, many people around here ski with their dogs, hardly any of them are on leads, and of those, at least some percentage are big, loutish, untrammeled dogs who run up to Thunder at full tilt, causing him to either “defend” me or otherwise establish his alpha dog-dom. I have to explain to their owners that no, Thunder does not want to play: he is a working dog, pulling a sled or a skier is his “job” and he is single-minded about it. Sometimes but not often, his lunge after another dog bounding up at him pulls me over (hence, the previously alluded-to bruises). Last year, I had a $50 vet bill courtesy of a border collie who bit Thunder to herd him when he did most definitely did not want to be herded. The owner, needless to say, did not call his dog despite my repeated requests that he do so. Jerk.

I should add that most people on the Nordic trails around Sun Valley (especially when asked) call their dogs instead of letting them launch themselves at other dogs, most of the dogs are reasonably well behaved but about 20% are not and they are inevitably golden retrievers or labs. With apologies to my friends who have those breeds,* I cringe when I see labs or retrievers on the Nordic trails, because I know those dogs are going to be the ones bounding up and creating a problem. Part of this I attribute to rampant cute puppyitis (many people fall in love with an adorable puppy – and both labs and retrievers are very cute puppies – without bothering to find out anything about the breed temperament) and part to the fact that in any group, there are going to be irresponsible pet owners.

My dog, I admit, is hardly perfect, but the rules of the Blaine County Recreation District are that if dogs are off lead, they must be within 15 feet and under voice command, both of which are regularly flouted by the aforementioned irresponsible dog owners. I’ve seen dogs wandering not anywhere near visual or audible distance of their owners (labs and retrievers, almost always). Realistically, of course, it is the owner who is at fault and not the dog. I guess a side affect of cute puppyitis is thinking your dog is so adorable, every one else (and every other dog) will find him just as appealing and you don’t have to bother training him.

I’ve been reminded recently of the difference between (if I may be forgiven) bad dogs and bad owners with the release of the SANS Top 25 Most Dangerous Programming Errors list. The list describes the Top 25 programming errors that contribute to security vulnerabilities. Many people contributed to it so it represents a broad consensus that is, overall, a strength. I should also note that one of my team reviewed and contributed to the list. I further add (hastily) that on the face of it, I don’t have a problem with the list: a list is a list (like a dog, it’s not necessarily a bad dog or a good dog, it’s just a dog). To the extent that a Top 25 Most Dangerous Programming Errors list helps create a starting point for Avoiding Bad Coding, it can be very useful. I also thank various folks who spearheaded the creation of the list (Bob Martin at Mitre was the hard-working project manager) and who scrupulously attempted to get an industry consensus via multiple review cycles and multiple contributors. As I have opined previously, there are a lot of universities that don’t teach secure coding or emphasize it and a lot of developers who are looking for guidance as to where to start paying attention to What Not To Do. To that extent, the SANS list is very useful.

My issue is with the potential mischief this list can and I fear will be put to, which, like my Nordic skiing example is not the fault of the dog (the list), it’s a fault of the “owners,” in this case people who “buy” the cute little list and are enamored of it and think it can do no wrong. I meet dog owners who decide their dog who runs up at Thunder full throttle is just the cutest thing and they do not understand why Thunder does not want to play. Then, it is my fault if there is a problem (uh, my dog is on a lead, yours is not, nor does yours obey voice command, therefore, your dog is by definition out of control and it is your responsibility to control the animal). I love Nordic skiing but the LLDS problem makes me absolutely crazy and ruins my skiing experience. Similarly, I am seeing what started as a good idea – a “don’t do this” list – morph into a big, loutish dog.

For example, I have heard people exclaim that it would be a great thing to demand of commercial software vendors that the solution to all security ills is that vendors be made to attest (as part of a contract) that their code contains no programming errors in the SANS Top 25 Most Dangerous Programming Errors list. Now, even if this could be foisted on the vendor community, just like a large untrammeled Labrador, I believe, the results would be unpredictable and not universally welcome. One wants to know, is the goal to have better software, or to have someone to sue? Because making forced contractual attestations as to the degree to which one’s software is free of a class of defects has some unintended consequences.

I have opined previously on the fact that automated tools help find Dumb Things In Code that could include some or all of the SANS Top 25. But everyone who has used them knows that the available tools on the market do not find all vulnerabilities or even all types of vulnerabilities. And if your code is quadruple digits in length or more – and most commercial software is multiple million lines of code – manual code review is a) time consuming, b) unlikely to succeed, c) subject to the vagaries of the reviewer and therefore not repeatable or consistent, and d) out of date as soon as the code changes, which is daily in many development organizations. More to the point, what happens when a vendor that has done the best it can to find and eradicate the SANS Top 25 (or whatever the List Du Jour is, more on which later) finds a vulnerability on the verboten list after using the best available tools? That is, where the product is already shipping? Suppose that the vulnerability a vendor finds is a really bad one (let’s say, CVSS 10), and so easy to exploit your grandmother can do it. Does the vendor a) sit on the vulnerability and hope nobody else finds it, or b) fix the problem and find themselves in breach of contract? That, dear reader, is what is known as a Catch-22 (or, in the best classic tradition, being caught between Scylla and Charybdis). Back to my original question, are the people rubbing their hands in glee at the prospect of forcing contract provisions that are list-based down vendors’ throats actually interested in better software, or having someone to blame?

I believe there is another problem with enshrining anything like a SANS Top 25 list into a contractual or regulatory straightjacket. First of all, the SANS Top 25 list is a general list with both the utility and limitations of that. If one’s code is (based on one’s development practice, development framework and deployment scenario of the software) more at risk from another kind of vulnerability that did not make the Top 25 (or, if new threats are discovered, and they are all the time), what should a vendor focus on? The theoretical Top 25 or the issues based on one’s own experience? The very nature of a Top 25 list is that it is likely to be overtaken by events (actually, in the general sense, it would be a very nice problem to have, because it might mean everyone had eradicated the Top 25 issues or at least made a really good dent in them, which we all want). However, that does not mean contractual language would change fast enough to maintain relevancy. It never does.

By way of example, when I was in the Navy, it was (at that time) part of the uniform regulations that females wearing dress uniforms (service dress blue or service dress white) were required to wear or carry white gloves and a purse. (If you carried white gloves instead of wearing them, they had to be folded lengthwise with “fingers out” – in front of your hand. If you care.) In short, white gloves and a purse were “part of the uniform” and if you did not wear or carry gloves and carry a purse that meant you were technically, “out of uniform,” one of the seven deadly sins in the Navy. Did I mention that part of your annual fitness report (think “employee performance review”) is “military bearing” and you get graded on things like how well you wear the uniform and observe military etiquette? Now, as a member of the Civil Engineer Corps, my job as a contracting officer entailed going on construction sites. The safety “rules” of most construction sites are that you need to wear a hardhat and steel-toes shoes. So, in order to comply with construction site safety regulations and Navy uniform regulations, I faced carrying white gloves onto a construction site (where, needless to say, they would not stay white very long). Not to mention, I was supposed to be carrying a purse and wearing a hardhat (instead of my uniform hat). I gave up on the steel-toed shoes since there are no steel-toed women’s pumps that I know of.

The bottom line is that those uniform regulations were set in the day when every woman wore a hat and gloves (my mom still does, to church every Sunday) and did not contemplate that women might expand to jobs that involved going onto construction sites. The regs did not keep up with the times. As a result, there is no way I could be both “in uniform” and “in compliance” on a construction site. Catch-22 – pick which regulation you are going to break, because I could not comply with all of them.

You might note that in the above case of “unattainable” or mutually conflicting regulations I should have just used common sense, and I did. But I was still technically “out of uniform.” And hence, my question, are the people advocating that the otherwise useful list become a contractual commitment (thus overusing if not abusing the utility of it) interested in better software or in building in an inability of vendors to meet all contractual provisions (the software assurance equivalent of demanding steel-toed high heeled pumps)? And if their intentions are to make software better, can they reconcile the likely outcome that vendors will consider their almost certain liability when deciding whether to release a fix and consult their lawyers on how to characterize an issue differently, rather than just getting on with the fix? Making things better should not entail requiring a level of perfection nobody could possibly meet, let alone enshrining it into a contract. Unless of course, one’s real goal is to make money out of others’ imperfections. (I should pause here and reiterate that the list is a good idea, I know the people who spearheaded it had good motives and I thank them for their efforts.)

One of the great privileges of my job has been the opportunity to advise policymakers on the challenges of cybersecurity or to comment on bills and other regulatory language. I note that while “lobbyist” is sometimes a term of opprobrium:

·

Policymakers, and the staff who capably assist them, typically want to legislate well·

Nobody can be an expert on every issue and thus policymakers and their staffers rely in part on outside stakeholders advising them of the specifics of an issue·

Such advice, if one is asked to or can offer it, is part of one’s civic responsibility (to help policymakers govern wisely)·

Lobbyists use these opportunities to talk about the scope and context of an issue, what their advice is and why, and what other positions are and why·

Bad lobbyists merely try to frame their side of the issue in a narrow context, and create law or regulation that will disproportionately benefit them personally - or their taskmasters - and to hell with everyone else and the public good

What I see shaping up in cybersecurity are a lot of people with agendas that involve personal enrichment as much as – no, I believe, in many cases more than - actually making things better. Security vendors, for example, whose core markets are drying up and who want to get into the testing business and therefore are lobbying to whomever will listen that outside testing is the answer to all security ills. Dare I say it, “Quis custodiet ipsos custodes?” (Who will watch the watchers?). People who want to come in and “audit” development processes – by regulation (again, who vets the auditors?). Vendors with encryption solutions who try to push data encryption as the legislative security for all ills. (Encryption does not solve access control problems and anyway, an alternative solution might be not allowing data to migrate to places it should not exist. Or automatically deleting it from places it should not be.) More to the point, I fear requiring specific technical remedies for a perceived risk runs the risk that the technical standards will rapidly be overtaken by newer technology, and we will be enshrining buggy whip standards in an automobile age. Or wearing white gloves to construction sites.

Now that the problem is clear, instead of recommending a particular “make it better” program like enshrining the SANS Top 25 list into contracts, here is what I would do:

I would like actual governance structures around Intended Do Good Security programs to ensure they are administered well, fairly, do not advantage a single vendor, promote actual and cost effective security improvement and do not demand the impossible overnight. In short, they give vendors both encouragement – pushy encouragement is fine – to improve and credit for doing it. And do actual security good, of course. I would include a recommended list of “good ideas that could make things better” as well as “bad ideas that legislators should stay away from.” (The way the SANS Top 25 list was developed showed good governance in that it was inclusive and transparently arrived at.)

Similarly, I would like vendors to implement some governance structures around their development processes. Nobody can do everything in security but we can all improve, and being able to a) target areas for improvement, b) create reasonable standards of practice in secure development within our own enterprises, and c) develop structures that help measure our internal consistency in depth and breadth of secure development practice is part of growing up. It’s treating security like a business value (diversity, cost containment, ethics, anything else you can and do run as a consistent corporate program). We all need to do that. (Oracle does have governance structures around our secure development programs, which will be the subject of future blogs.) None of us will develop products exactly the same way, with exactly the same APIs or exactly the same development frameworks, exactly the same tools and not every “good security idea” will be equally cost effective or useful for all of us. But we can, and should, figure out a) what we should be doing as individual vendors that is generally considered good practice, and b) make sure we do that.

For my part, and back to my Nordic skiing example, I cannot control what others do with their dogs, but for my part, I have tried to improve what I do with my dog. I started using my “happy voice” with Thunder when another dog comes up, to remind him that he likes labs, border collies, retrievers and so on. I am less tense and defensive so he does not feel he needs to protect me. I can be a better dog owner, and I try to be. Specifically, I figure if I am more open and accepting of loose, loutish dogs, it helps avoid problems and vet bills. I also thank the many responsible dog owners I meet for how smart, well behaved, and handsome their dogs are, and for calling their dogs instead of letting them bound up. Just like working on cybersecurity issues, my Nordic skiing goal is “happy – and safe – trails for all.”

* One of my dear friends just lost her beloved lab Zach. Zach was a lovely, sweet dog and will forever be enshrined in my personal pantheon of utterly lovable labs.

Book of the Week

War Made New, Technology, Warfare and the Course of History: 1500 to Today by Max Boot

A really fascinating look at how technology has contributed to military success. Max Boot analyzes warfare in terms of “ages” – gunpowder, first and second industrial age, and the information age (e.g., as applied in Iraq and Afghanistan). He also looks at potential future combat. The interesting questions in military history are not “who won?” but “why?” and “how?” It’s also fascinating to see how warfare is being transformed through information technology.

http://www.amazon.com/War-Made-New-Technology-Warfare/dp/1592402224/ref=sr_11_1?ie=UTF8&qid=1233166859&sr=11-1Max Boot also wrote The Savage Wars of Peace: Small Wars and the Rise of American Power, which I have not read, but just bought.

http://www.amazon.com/Savage-Wars-Peace-Small-American/dp/046500721X/ref=sr_1_1?ie=UTF8&s=books&qid=1233166967&sr=1-1For More Information

More on Scylla and Charybdis:

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

More on “who watches the watchers?”

http://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%3F

The SANS Top 25 Most Dangerous Programming Errors list (again, my appreciation to both those who spearheaded it - thank you, Bob Martin - and to those who contributed):

http://www.sans.org/top25errors/

More on the BCRD Nordic trails:

http://www.bcrd.org/wintertrails/tabid/55/Default.aspx

Pau hana happiness. If you’ve had a hard week, you can cheer yourself up by checking out Mānoa DNA below doing Ka’a Ahi Kahului. (You can also learn how to say ‘railroad’ in Hawaiian.) I love these guys!http://www.youtube.com/watch?v=xwx231xqAKI

You can find a the CD of the above song at:

http://www.hawaiianmusicstore.com/cds/cd689.html

Loose Dogs

Sat, 2009-02-07 04:50

As I write this, I am nursing a couple of bruises I incurred skijouring with my dog Thunder. Skijouring is Nordic skiing with your dog hooked up to a lead, so he pulls you. I believe the word “skijour” comes from the Norwegian word for “cheating,” judging by the dirty looks I get from other Nordic skiers when Thunder zooms past them towing me. Mind you, Thunder has two speeds: flat out and conked out. Periodically, he stops in the middle of a run to jump into a snow bank, do a “doggy snow angel” and cool off, or check out some other dog’s calling card. You get used to using the fast-braking snowplow since I know from experience it is no fun to reach the end of the tether at high speed: it leads to a Nordic skiing move known as a “face plant.”

I Nordic ski a lot, hooked up to Thunder most of the time though I typically do a few kilometers by myself because otherwise he is the only one getting aerobic exercise. The biggest hazard for me in Nordic skiing (which does not normally carry the risks alpine skiing does) is from what I call LLDS – loose, loutish dog syndrome. That is, many people around here ski with their dogs, hardly any of them are on leads, and of those, at least some percentage are big, loutish, untrammeled dogs who run up to Thunder at full tilt, causing him to either “defend” me or otherwise establish his alpha dog-dom. I have to explain to their owners that no, Thunder does not want to play: he is a working dog, pulling a sled or a skier is his “job” and he is single-minded about it. Sometimes but not often, his lunge after another dog bounding up at him pulls me over (hence, the previously alluded-to bruises). Last year, I had a $50 vet bill courtesy of a border collie who bit Thunder to herd him when he did most definitely did not want to be herded. The owner, needless to say, did not call his dog despite my repeated requests that he do so. Jerk.

I should add that most people on the Nordic trails around Sun Valley (especially when asked) call their dogs instead of letting them launch themselves at other dogs, most of the dogs are reasonably well behaved but about 20% are not and they are inevitably golden retrievers or labs. With apologies to my friends who have those breeds,* I cringe when I see labs or retrievers on the Nordic trails, because I know those dogs are going to be the ones bounding up and creating a problem. Part of this I attribute to rampant cute puppyitis (many people fall in love with an adorable puppy – and both labs and retrievers are very cute puppies – without bothering to find out anything about the breed temperament) and part to the fact that in any group, there are going to be irresponsible pet owners.

My dog, I admit, is hardly perfect, but the rules of the Blaine County Recreation District are that if dogs are off lead, they must be within 15 feet and under voice command, both of which are regularly flouted by the aforementioned irresponsible dog owners. I’ve seen dogs wandering not anywhere near visual or audible distance of their owners (labs and retrievers, almost always). Realistically, of course, it is the owner who is at fault and not the dog. I guess a side affect of cute puppyitis is thinking your dog is so adorable, every one else (and every other dog) will find him just as appealing and you don’t have to bother training him.

I’ve been reminded recently of the difference between (if I may be forgiven) bad dogs and bad owners with the release of the SANS Top 25 Most Dangerous Programming Errors list. The list describes the Top 25 programming errors that contribute to security vulnerabilities. Many people contributed to it so it represents a broad consensus that is, overall, a strength. I should also note that one of my team reviewed and contributed to the list. I further add (hastily) that on the face of it, I don’t have a problem with the list: a list is a list (like a dog, it’s not necessarily a bad dog or a good dog, it’s just a dog). To the extent that a Top 25 Most Dangerous Programming Errors list helps create a starting point for Avoiding Bad Coding, it can be very useful. I also thank various folks who spearheaded the creation of the list (Bob Martin at Mitre was the hard-working project manager) and who scrupulously attempted to get an industry consensus via multiple review cycles and multiple contributors. As I have opined previously, there are a lot of universities that don’t teach secure coding or emphasize it and a lot of developers who are looking for guidance as to where to start paying attention to What Not To Do. To that extent, the SANS list is very useful.

My issue is with the potential mischief this list can and I fear will be put to, which, like my Nordic skiing example is not the fault of the dog (the list), it’s a fault of the “owners,” in this case people who “buy” the cute little list and are enamored of it and think it can do no wrong. I meet dog owners who decide their dog who runs up at Thunder full throttle is just the cutest thing and they do not understand why Thunder does not want to play. Then, it is my fault if there is a problem (uh, my dog is on a lead, yours is not, nor does yours obey voice command, therefore, your dog is by definition out of control and it is your responsibility to control the animal). I love Nordic skiing but the LLDS problem makes me absolutely crazy and ruins my skiing experience. Similarly, I am seeing what started as a good idea – a “don’t do this” list – morph into a big, loutish dog.

For example, I have heard people exclaim that it would be a great thing to demand of commercial software vendors that the solution to all security ills is that vendors be made to attest (as part of a contract) that their code contains no programming errors in the SANS Top 25 Most Dangerous Programming Errors list. Now, even if this could be foisted on the vendor community, just like a large untrammeled Labrador, I believe, the results would be unpredictable and not universally welcome. One wants to know, is the goal to have better software, or to have someone to sue? Because making forced contractual attestations as to the degree to which one’s software is free of a class of defects has some unintended consequences.

I have opined previously on the fact that automated tools help find Dumb Things In Code that could include some or all of the SANS Top 25. But everyone who has used them knows that the available tools on the market do not find all vulnerabilities or even all types of vulnerabilities. And if your code is quadruple digits in length or more – and most commercial software is multiple million lines of code – manual code review is a) time consuming, b) unlikely to succeed, c) subject to the vagaries of the reviewer and therefore not repeatable or consistent, and d) out of date as soon as the code changes, which is daily in many development organizations. More to the point, what happens when a vendor that has done the best it can to find and eradicate the SANS Top 25 (or whatever the List Du Jour is, more on which later) finds a vulnerability on the verboten list after using the best available tools? That is, where the product is already shipping? Suppose that the vulnerability a vendor finds is a really bad one (let’s say, CVSS 10), and so easy to exploit your grandmother can do it. Does the vendor a) sit on the vulnerability and hope nobody else finds it, or b) fix the problem and find themselves in breach of contract? That, dear reader, is what is known as a Catch-22 (or, in the best classic tradition, being caught between Scylla and Charybdis). Back to my original question, are the people rubbing their hands in glee at the prospect of forcing contract provisions that are list-based down vendors’ throats actually interested in better software, or having someone to blame?

I believe there is another problem with enshrining anything like a SANS Top 25 list into a contractual or regulatory straightjacket. First of all, the SANS Top 25 list is a general list with both the utility and limitations of that. If one’s code is (based on one’s development practice, development framework and deployment scenario of the software) more at risk from another kind of vulnerability that did not make the Top 25 (or, if new threats are discovered, and they are all the time), what should a vendor focus on? The theoretical Top 25 or the issues based on one’s own experience? The very nature of a Top 25 list is that it is likely to be overtaken by events (actually, in the general sense, it would be a very nice problem to have, because it might mean everyone had eradicated the Top 25 issues or at least made a really good dent in them, which we all want). However, that does not mean contractual language would change fast enough to maintain relevancy. It never does.

By way of example, when I was in the Navy, it was (at that time) part of the uniform regulations that females wearing dress uniforms (service dress blue or service dress white) were required to wear or carry white gloves and a purse. (If you carried white gloves instead of wearing them, they had to be folded lengthwise with “fingers out” – in front of your hand. If you care.) In short, white gloves and a purse were “part of the uniform” and if you did not wear or carry gloves and carry a purse that meant you were technically, “out of uniform,” one of the seven deadly sins in the Navy. Did I mention that part of your annual fitness report (think “employee performance review”) is “military bearing” and you get graded on things like how well you wear the uniform and observe military etiquette? Now, as a member of the Civil Engineer Corps, my job as a contracting officer entailed going on construction sites. The safety “rules” of most construction sites are that you need to wear a hardhat and steel-toes shoes. So, in order to comply with construction site safety regulations and Navy uniform regulations, I faced carrying white gloves onto a construction site (where, needless to say, they would not stay white very long). Not to mention, I was supposed to be carrying a purse and wearing a hardhat (instead of my uniform hat). I gave up on the steel-toed shoes since there are no steel-toed women’s pumps that I know of.

The bottom line is that those uniform regulations were set in the day when every woman wore a hat and gloves (my mom still does, to church every Sunday) and did not contemplate that women might expand to jobs that involved going onto construction sites. The regs did not keep up with the times. As a result, there is no way I could be both “in uniform” and “in compliance” on a construction site. Catch-22 – pick which regulation you are going to break, because I could not comply with all of them.

You might note that in the above case of “unattainable” or mutually conflicting regulations I should have just used common sense, and I did. But I was still technically “out of uniform.” And hence, my question, are the people advocating that the otherwise useful list become a contractual commitment (thus overusing if not abusing the utility of it) interested in better software or in building in an inability of vendors to meet all contractual provisions (the software assurance equivalent of demanding steel-toed high heeled pumps)? And if their intentions are to make software better, can they reconcile the likely outcome that vendors will consider their almost certain liability when deciding whether to release a fix and consult their lawyers on how to characterize an issue differently, rather than just getting on with the fix? Making things better should not entail requiring a level of perfection nobody could possibly meet, let alone enshrining it into a contract. Unless of course, one’s real goal is to make money out of others’ imperfections. (I should pause here and reiterate that the list is a good idea, I know the people who spearheaded it had good motives and I thank them for their efforts.)

One of the great privileges of my job has been the opportunity to advise policymakers on the challenges of cybersecurity or to comment on bills and other regulatory language. I note that while “lobbyist” is sometimes a term of opprobrium:

· Policymakers, and the staff who capably assist them, typically want to legislate well
· Nobody can be an expert on every issue and thus policymakers and their staffers rely in part on outside stakeholders advising them of the specifics of an issue
· Such advice, if one is asked to or can offer it, is part of one’s civic responsibility (to help policymakers govern wisely)
· Lobbyists use these opportunities to talk about the scope and context of an issue, what their advice is and why, and what other positions are and why
· Bad lobbyists merely try to frame their side of the issue in a narrow context, and create law or regulation that will disproportionately benefit them personally - or their taskmasters - and to hell with everyone else and the public good

What I see shaping up in cybersecurity are a lot of people with agendas that involve personal enrichment as much as – no, I believe, in many cases more than - actually making things better. Security vendors, for example, whose core markets are drying up and who want to get into the testing business and therefore are lobbying to whomever will listen that outside testing is the answer to all security ills. Dare I say it, “Quis custodiet ipsos custodes?” (Who will watch the watchers?). People who want to come in and “audit” development processes – by regulation (again, who vets the auditors?). Vendors with encryption solutions who try to push data encryption as the legislative security for all ills. (Encryption does not solve access control problems and anyway, an alternative solution might be not allowing data to migrate to places it should not exist. Or automatically deleting it from places it should not be.) More to the point, I fear requiring specific technical remedies for a perceived risk runs the risk that the technical standards will rapidly be overtaken by newer technology, and we will be enshrining buggy whip standards in an automobile age. Or wearing white gloves to construction sites.

Now that the problem is clear, instead of recommending a particular “make it better” program like enshrining the SANS Top 25 list into contracts, here is what I would do:

I would like actual governance structures around Intended Do Good Security programs to ensure they are administered well, fairly, do not advantage a single vendor, promote actual and cost effective security improvement and do not demand the impossible overnight. In short, they give vendors both encouragement – pushy encouragement is fine – to improve and credit for doing it. And do actual security good, of course. I would include a recommended list of “good ideas that could make things better” as well as “bad ideas that legislators should stay away from.” (The way the SANS Top 25 list was developed showed good governance in that it was inclusive and transparently arrived at.)

Similarly, I would like vendors to implement some governance structures around their development processes. Nobody can do everything in security but we can all improve, and being able to a) target areas for improvement, b) create reasonable standards of practice in secure development within our own enterprises, and c) develop structures that help measure our internal consistency in depth and breadth of secure development practice is part of growing up. It’s treating security like a business value (diversity, cost containment, ethics, anything else you can and do run as a consistent corporate program). We all need to do that. (Oracle does have governance structures around our secure development programs, which will be the subject of future blogs.) None of us will develop products exactly the same way, with exactly the same APIs or exactly the same development frameworks, exactly the same tools and not every “good security idea” will be equally cost effective or useful for all of us. But we can, and should, figure out a) what we should be doing as individual vendors that is generally considered good practice, and b) make sure we do that.

For my part, and back to my Nordic skiing example, I cannot control what others do with their dogs, but for my part, I have tried to improve what I do with my dog. I started using my “happy voice” with Thunder when another dog comes up, to remind him that he likes labs, border collies, retrievers and so on. I am less tense and defensive so he does not feel he needs to protect me. I can be a better dog owner, and I try to be. Specifically, I figure if I am more open and accepting of loose, loutish dogs, it helps avoid problems and vet bills. I also thank the many responsible dog owners I meet for how smart, well behaved, and handsome their dogs are, and for calling their dogs instead of letting them bound up. Just like working on cybersecurity issues, my Nordic skiing goal is “happy – and safe – trails for all.”

* One of my dear friends just lost her beloved lab Zach. Zach was a lovely, sweet dog and will forever be enshrined in my personal pantheon of utterly lovable labs.

Book of the Week

War Made New, Technology, Warfare and the Course of History: 1500 to Today by Max Boot

A really fascinating look at how technology has contributed to military success. Max Boot analyzes warfare in terms of “ages” – gunpowder, first and second industrial age, and the information age (e.g., as applied in Iraq and Afghanistan). He also looks at potential future combat. The interesting questions in military history are not “who won?” but “why?” and “how?” It’s also fascinating to see how warfare is being transformed through information technology.

http://www.amazon.com/War-Made-New-Technology-Warfare/dp/1592402224/ref=sr_11_1?ie=UTF8&qid=1233166859&sr=11-1

Max Boot also wrote The Savage Wars of Peace: Small Wars and the Rise of American Power, which I have not read, but just bought.

http://www.amazon.com/Savage-Wars-Peace-Small-American/dp/046500721X/ref=sr_1_1?ie=UTF8&s=books&qid=1233166967&sr=1-1

For More Information

More on Scylla and Charybdis:

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

More on “who watches the watchers?”

http://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%3F

The SANS Top 25 Most Dangerous Programming Errors list (again, my appreciation to both those who spearheaded it - thank you, Bob Martin - and to those who contributed):

http://www.sans.org/top25errors/

More on the BCRD Nordic trails:

http://www.bcrd.org/wintertrails/tabid/55/Default.aspx

Pau hana happiness. If you’ve had a hard week, you can cheer yourself up by checking out Mānoa DNA below doing Ka’a Ahi Kahului. (You can also learn how to say ‘railroad’ in Hawaiian.) I love these guys!

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

You can find a the CD of the above song at:

http://www.hawaiianmusicstore.com/cds/cd689.html

School's Out

Fri, 2009-01-09 08:09

When I look back on my career, particularly my educational background, I find it interesting to consider what has stuck with me, what I have forgotten, and what continues to be useful. I have sort of a strange background for a security weenie – an undergraduate mechanical engineering degree and an MBA. I don’t talk about the MBA all that much, partly because I know plenty of overblown egos who can’t wait to trot out the fact they have an MBA from Harvard, Wharton, Stanford, (insert name of prestigious MBA program here). Second, someone who worked for me awhile ago got an MBA and proceeded to treat his directs really poorly with newly-minted MBA hubris that was astonishing (I recognize the disease because I had a bad case of it once, myself). He thought that MBA stood for Me Before All and everyone who worked for him was there to advance his career. Third, but mostly first, Impressive Academic Credentials are increasingly unimportant the longer you are in the working world; what you actually accomplish is far more important than how well educated you are.

That said, I do think that the education I got in my MBA program gave me some “tricks of the trade” I still find inordinately useful. Now, not everything one learns at universities is timeless. Particularly in the liberal arts area, there are reinterpretations and revisions of widely held knowledge going on all the time. I guess that especially for academic areas that have been strip mined more than Appalachia, the way you create academic street creds for yourself is by regularly throwing out babies after drowning your colleagues in the bathwater. My father (who has a PhD in civil engineering and has been a university professor and administrator) liked to tell the joke about an engineering professor and an economics professor conversing on a campus. “I hear you give the same exam each semester in the economics department,” says the engineering guy. “Our students get hold of the old exams. So, how on earth do you get away with it in the econ department?” “Easy, “ says the economics professor. “We just change the answers.” Now, it’s not totally true that economics changes all that fast (although I hope we have driven a stake through John Maynard Keynes* and all his sycophants once and for all). But economic theories do change.

That said, among the most useful classes I took at business school, and one of the areas I refer to often in my work, are the economics classes. It’s just timeless, whether we are talking about micro- or macroeconomics. It’s particularly important in talking about public policy issues (yes, even around security). For example, I have talked about (and there are many who have) whether there is a market failure in information security. The discussion becomes (if there is a market failure) how to correct it? How do you make markets work efficiently (e.g., to remove externalities or “social costs?”) There are also a lot of offshoots of economics that have applications in other areas (game theory, for example, which was tremendously influential in Cold War strategy). I have thought about game theory in various security discussions (in particular, discussions in which industry can maximize our collective best interests or “payoff” by hanging together, like the prisoners of the prisoners’ dilemma, and yet one “defector” can achieve a higher individual payoff by selling other vendors down the game theory river. Alas, I have seen one vendor do just that and now everybody is worse off than if the vendor had not "defected.").

Financial theory is pretty useful, too. For example, the idea that you should disregard sunk costs in future decision making, a fancy way of saying ignore how much money you’ve already thrown at a problem in analyzing whether to go forward with it. I use that all the time, especially when someone starts in with “we’ve worked so long/hard/whatever on project X.” You have to look at the expectation of success going forward and what it will cost to get there (and other options for those resources) because sunk costs are by definition non-recoverable no matter what you do. You’ve spent the money, you can’t get it back: now what?

Some of those economic and financial market lessons have been reiterated in spades in looking at the current financial market meltdown. One of them is that “diversification reduces risk” in terms of a portfolio – the financial market theory of not having all your financial eggs in one basket. The corollary is that some kinds of risk are not diversifiable (e.g., if the entire market craps out, everything sinks together and diversification doesn’t help you, as many of us who’ve opened our 401K statements recently are all too painfully aware). You really wish, when reading about people who became stupidly overleveraged (fancy term for living way beyond your means and all on credit) that they had some basic comprehension of economics. Not merely for their own financial well-being, but so that people have realistic expectations of personal responsibility and the limits of government. (Hint: governments cannot create wealth, though they can print money. If they print enough money with no actual wealth behind it devalues the money you have. Getting someone else besides you to pay for your lifestyle is nice work if you can get it, but if you keep robbing Peter to give lazy bones Paul a free ride, Peter will find ways to work less or otherwise revolt.) None of this is rocket science yet so many people never learned basic financial or economic principles. There really is no such thing as a free lunch.

Business law is another area I find incredibly useful. Granted, a lot of my pragmatic understanding of contract law in particular I learned as a contract administrator in the Navy (nothing like having a $200,000 claim over the meaning of the word “automatic” or the performance of a contract hinge on a misplaced comma, both of which I have experienced). One of the big lessons I learned is the legal equivalent of RTFM: let’s call it RTFC or “Read the Friggin’ Contract.” In particular, if you are negotiating a contract, realize that what you agree to with your counterpart has to survive the participants who drew up the contract (that’s why things are written down). The words “well, everybody knows what we meant by that” absolutely never enter into legal parlance. The legal equivalent of Murphy’s Law is that if something in a contract is ambiguous, it will be misinterpreted by at least one party to the contract. You need to read it (over and over and over) through all revisions to avoid expensive mistakes. (It took me a year to negotiate a licensing agreement with a partner, but at the end of the year, we had a deal and there were no disputes over the terms during the life of the contract. My counterpart at the other company is still a great gal pal to this day.)

The other lesson I learned is that contracts also are not good vehicles for creating trust between parties. If someone is a slimy so-and-so, you cannot write a contract that will make them less of a slimy so-and-so. A contract will not create trust; it will tell you who has to do what under the terms of the contract, and possibly spell out remedies if parties do not perform under the contract. That assumes that you can actually get a remedy out of someone that is timely or meaningful. I am always astonished at someone whose going in position is “if it doesn’t work, we can sue.” (Kind of like people who get married with the expectation, “if it doesn’t work out, we can get a divorce.” The formulation of an exit strategy on the day you ink a deal does not bode well for it, so why are you signing on the dotted line?) If someone rips off your intellectual property (for example, in a geographic area with not a whole lot of respect for intellectual property rights), good luck on a “remedy” that will make you whole. “Don’t take that bet” is sometimes a better strategy than counting on a contract to make you whole if something goes wrong, especially if you have a high expectation that you are going to have a problem.

Another of the other really useful constructs I got from B-school was my quantitative methods class. Quantitative methods are a way of putting more numeric rigor around decision making, whether it is analyzing a business strategy or problem solving. For example, you may have an optimization problem you are working on, like “the truck routing problem.” You have so many trucks, they need to make deliveries, you want to find out the most efficient route but without delaying deliveries too long, and so on. You have a number of constraints you have to work with – you only have so many trucks, so many deliveries, so much distance, and time limits within which you have to deliver things. If nothing else, you learn that while sometimes you can add resource (more trucks can make more deliveries in shorter time), you still have constraints you can’t necessarily move (houses are not going to move closer together for your convenience, and you can’t make time go faster).

Particularly when I find myself dealing with (and they mean well) academics, think-tankers or government wonks who want to create public policy, I sometimes need to remind them of quantitative methods 101: resources are always constrained. Sometimes, people who don’t actually have to earn a profit or make tradeoffs or implement their own public policies find lots of “really important” ways for other people to spend money in pursuit of A Noble Purpose. The reality is that sometimes you don’t have any more resource, and even if you did, there might be a better way to use the resource that would lead to a public policy (or other) good, like better return for investors. In discussing public policy I try to talk about what the real-world constraints are, and inevitably I ask some of the government folks questions like, “do you want absolute perfection, or do you want to give industry a way to say Yes, where they can make progress, improve what they are doing in a cost effective way that actually makes the problem better?” Something is almost always better than nothing. You can either listen, understand what people’s constraints are and allow for them, or create a problem statement that says, ‘I want to have my cake, eat it too, have it be organic, sustainable, biodegradable, delicious, rich, and have zero calories: in fact, I want to lose weight while eating it.” People who understand optimization problems know you’d do well if you got three of those conditions satisfied. You cannot satisfy all of them.

I even use the quantitative methods approach (finally!) in asking for more headcount. I am embarrassed to admit that it took me years at Oracle to figure out how to get more headcount, and the method I finally hit on (more accurately, that I finally embraced after enough people told me the best way to do it, I ignored the advice and learned the hard way that they were right), is a simple exercise. I collate, in an organized way, “what we are doing now, what we are not doing now, and what we can do with more resource.” “What we get with more resource” is along the lines of (in priority order) additional work my team could take on and the value to the company of us doing that (sometimes the value is cost avoidance or something tangible we can (roughly) quantify). I am hardnosed in that, if people who work for me who run various areas do not make a good enough case to me for their headcount requests, I draw the “wish list” line above their headcount requests. In going to my boss, I will say, “here is what we get with more resource (in priority order), meaning if I got one headcount, I’d add one person to do A, if another person, I would put them on B, then a third person to do C, here is the value to the company for adding those bodies, and any headcount beyond that should go to someone else in your organization who can spend the resource better.” Meaning, my goal is not empire building, it is adding enough resource to use it to add value (or reduce cost), and no more.

There is always a lot more to learn. In writing this blog entry, I realized I had forgotten a whole lot about economics and game theory (and I didn’t relearn them in the time it took to write the blog). But, one of my absolutely favorite hangouts – the Ketchum Community Library (they say I am their best customer) is right down the hill, and I will be trotting down there later today to see what books they have on economics and game theory.

The beginning of a new year is a bright and shiny opportunity to do things differently. While time is one of our most constrained resources (I may stay up late reading myself blind, but I still need some sleep), I always set a New Year’s resolution or two around learning a new skill, or beefing up a knowledge area. It doesn’t always have to be in computer security, either. Sometimes learning something new (or revisiting something old) can give a fresh perspective to your day job.

Hau’oli Makahiki Hou (Happy New Year!)

* FDR, in my opinion, did bubkes to get us out of the Great Depression and should not get credit for it; there was double digit unemployment into 1942. On the contrary, the Second World War ended the Great Depression, and we can thank James Forrestal (who architected the unprecedented industrial gear shifting to war production) for helping end the Great Depression far more than FDR.


Book of the Week

A Roof Against the Rain by JoEllen Collins

This is a public service announcement: I know JoEllen – she is a friend of mine. She also happens to be a cracking good writer. I loved the book – which is about loss of a loved one - and am recommending it broadly. I think it would be a particularly good “book group book” ( I recommended it to my book group). Her characters are believable and there is a moral center (so few dreary modern works of fiction have one). It’s also just a fun read and it takes place in Sun Valley; Idaho another reason I liked the book.

http://www.buy.com/prod/a-roof-against-the-rain/q/loc/106/208184025.html

Other good reads:

Why the Allies Won by Richard Overy

We forget that the victory of the Allies over the Axis in WWII was not a done deal at all but quite a close thing. This book describes the factors involve in that victory – leadership, economies, technology, among others.

http://www.amazon.com/s/ref=nb_ss_b_0_18?url=search-alias%3Dstripbooks&field-keywords=why+the+allies+won+by+richard+overy&x=0&y=0&sprefix=why+the+allies+won

The New Dealer’s War: FDR and the War Within World War II by Thomas Fleming

A very different “take” on FDR and an eye-opening one. Between FDR’s (likely) leaking of the Rainbow Plan to ignoring the Katyn Massacre, FDR hagiography is quite deftly shattered by this book.

http://www.amazon.com/New-Dealers-War-Within-World/dp/0465024653

For more information

I am completely stoked that my favorite Hawaiian music group Maunalua (together with Grammy winner John Cruz) is playing at an inaugural lu’au at the Hotel Monaco in DC on January 20. Nā mele no ka ‘oi!

http://inauguralluau.eventbrite.com/

The Prisoner’s Dilemma is an interesting book on the influence of game theory on the Cold War.

http://www.amazon.com/Prisoners-Dilemma-William-Poundstone/dp/038541580X/ref=sr_1_1?ie=UTF8&s=books&qid=1231442535&sr=1-1

Legacy

Thu, 2008-12-04 10:49

I have been rather silent on the blog front for some time. The reason has not been a happy one. I went through something very painful this summer that all of us inevitably experience: the death of a loved one. In my case, it was my best friend of 17 years – though Kerry was more than that, truly. As my sister says of him, echoing Alec Guinness in Star Wars, “there has been a disturbance in The Force.” Someone who was larger than life leaves a void in many lives, most especially mine. For awhile, I was tied up in his illness, then the funeral, and then I just could not pick up my virtual pen because it is hard to live through this much less write about it. The blog entry I really meant to write (about force multipliers) kept being crowded into the back of my mind, because I really needed to write about my friend Kerry and the meaning of legacy.

The occasion of death is a forced milestone in that it is a logical time to assess what matters in life. And what seems to matter to us during our lives is often not what matters after one’s course has run. There’s a story about a man reading that John D. Rockefeller had died and asking a companion, “How much money did he leave?” The answer was, “All of it.” All the things we think matter in terms of accomplishments, press clippings, portfolio, and so on, are dust in the wind once we are gone. Even having a building named after you is not all that permanent. The sages of Israel taught of Herod’s temple in Jerusalem: "Whoever has never seen the building constructed by Herod, has never seen a beautiful building in his life." Herod’s temple took over eighty years to build, yet the Romans utterly destroyed it in a matter of days. All we have left is a retaining wall of the temple structure and a holy day to mourn its destruction:Tisha B’Av.

No wonder that Jesus wept over Jerusalem and advised his disciples, "Do not store up for yourselves treasures on earth, where moth and rust destroy, and where thieves break in and steal. But store up for yourselves treasures in heaven, where moth and rust do not destroy, and where thieves do not break in and steal. For where your treasure is, there your heart will be also.”

Kerry did not leave a legacy in things the world values. He left no assets. No property. No portfolio. No bank account. No buildings named after him. No children. Yet he left a very rich legacy in many hearts. People who loved him. Lives he changed, mine in particular. To name two things near and dear to my heart, Kerry taught me to surf, and talked me into buying my house in Idaho. Oh, and committed me to buying a dog without asking (said dog, Thunder, is howling for a treat a I write this). How can you thank someone for giving you a life, or for helping make you who you are? I can’t really imagine what my life would have been like without him, except that it would have been so much poorer.

The number of calls, cards, emails, and so on I have gotten from people who knew him and cannot believe he is gone astonishes and humbles me. And the way they talk about him is a reminder of what really matters to people. One friend said that Kerry was the only person he could ever trust with money – after years of being burned by partners in business. Kerry not only made my friend good money, but was giving away his “trade secrets” by teaching my friend to do what he did in the markets. The financial institution he cleared paper through called up (to a person) to tell me how much Kerry had meant to them though none of them had met him personally: “We talked every day for four years and we didn’t just talk about the stock market; we talked about life.”

Particularly as we watch the recent economic meltdown caused – if I may be indulged here – by a number of people at all levels of society engaging in financial deception or delusion (such as buying a house one knows very well one cannot afford and that is bigger than one needs, or taking equity out to finance a lifestyle one cannot afford) – Kerry stood out. He always “paid cash or did without.” An old-fashioned value that the world needs more of.

He also had the most honest business model that I know of, one in which he took part of the risk that he assumed for his clients. I get lots of cold calls from money managers. I tell them if they are willing to work on the same basis as Kerry did, I will consider it Kerry made 25% of closed out net capital gains, which means if he lost clients money, he had to make it back for them and be in the black before he made any money for himself. None of these MMLs (money management leeches) take my offer, and typically stutter that my counter-offer is not reasonable. I reply that they want to get paid regardless of whether they earn me money or lose it all. The risk, in other words, is all mine, and none of it is theirs. What, one asks, is fair about that? Kerry only did well if his clients did well. A “square deal meal” kind of guy, an increasing rarity in a world where so many are without honor or integrity, and where many are happy to take the reward on the upside but want a bailout on the downside of risk (which economists rightly call a “moral hazard”).

Back to my point, a legacy of changed lives is all that we can really leave behind us that matters. Yet for some reason, in the software industry, “legacy” as a term seems to only be uttered with a sneer. “That is a legacy system” is almost always said with disdain. Why? What’s wrong with old code? Actual users (remember them?) think “legacy” means “something that works, that meets my business needs and is paid for and I am happy with it so I want to keep using it if possible.” Software kahunas think “legacy” is a pejorative term, and that new is always better, old is always bad, and we all need to upgrade “just because.” (The last software upgrade I went through required me to install all new client software with really poor instructions – uh, is there some reason I should have to magically know to rename a file to BLAHBLAH.exe?) and I absolutely lost it. It was the weekend Kerry died and the thing that caused me to break down and “lose it” was the software upgrade, not Kerry’s death. The three most dreaded words in the English language, as all parents learn to their dismay on Christmas Eve at 3AM, is “some assembly required.”)

Merriam Webster defines “legacy” as follows:

1 : a gift by will especially of money or other personal property : bequest 2 : something transmitted by or received from an ancestor or predecessor or from the past

I’ve talked about the first meaning of “legacy.” Now, to the second. Granted, not everything in the past is worth pulling forward and celebrating, but many things are. At the very least, the passage of time allows us to pan through historical dust to find nuggets of permanent value. The second meaning of legacy reminds us that not everything new is wonderful simply because it is new. In particular, the belief that “new and improved” equates to progress is almost a de facto religious belief among many technologists. Yet never has the half-life of technological progress been shorter. Who among us really remembers (or cares) who invented the FOOBAR protocol? Especially when the FOOBAR protocol will be overtaken by something else within a few short years.

Many of the things that historically matter to us now were not obvious to the citizenry of the time (does anybody remember the number one tentmaker in Jerusalem circa 30AD? Yet most of us have at least heard of an obscure carpenter/rabbi named Yeshua). Western civilization, for example, has percolated along quite happily on the strength of the ideas and writings of (if I may be forgiven) innumerable dead white males. Has anyone in the 21st century approached the stature of Rabbi Yeshua or other dead white males (Aristotle, Plato?) We may only know in hindsight. Despite the compressed lifecycle of so much we work with and work on, we should resist the temptation to engage in hagiography on the strength of anything short-lived or of recent occurrence, because we will probably be wrong about who and what really mattered.

An example of near religious ecstasy around technology is all the hoopla around cloud computing, if anyone can decide what it actually is. If by cloud computing, someone really means “software as a service,” that’s not actually a “new” idea at all. It’s been around for eons (remember Compuserve?). And many software vendors offer hosted applications and make a nice business out of it, too. Software as a service makes sense in some scenarios (is that alliterative, or what?). I personally outsource buying anything electronic to my brother-in-law, who does extensive market research and then tells me what to get. “Gizmo-buying-as-a-service” works for me.

If cloud computing is the idea that all your “stuff” will magically be “out there somewhere, in the cloud,” well, that is looney tunes for obvious reasons. Just think basics. I still have cookbooks if for no other reason than I can “fire them up” without waiting for software to load, and I would really hate to have to access recipes in the cloud. Open book, read recipe, book does not need rebooting, ever. Sometimes I do look for recipes online when I realize (in Idaho) that the cookbook I had with my pecan bar recipes is in San Francisco. So, “recipes as a service” might be useful sometimes – but I sure do not want the recipe server to be down when I am in the middle of cooking Thanksgiving dinner.

More to the point, the “it’s stored wherever, and you don’t need to know where” hype around “everything will be in the cloud” is technogobbledygook. There are many things you aren’t going to want to store “somewhere out there,” for good reasons, especially if you have no idea how secure it is and it is something you find valuable. Imagine someone saying, “Mrs. Smith, we can’t actually tell you where your daughter Janie – who you dropped off at day care this morning - will be during the day, she is out there in the daycare cloud someplace, running around, we are not really sure where. But trust us, when you stop by at 5 to pick her up, we’ll have her at the right place.” Yeah, right. Not surprisingly, security people are not buying “somewhere, out there” model of cloud computing. Nobody should. At the very least, instead of having somewhat defensible enclaves of security, you’d have to make everything secure, which is simply not possible.

I was reminded in a frightening way recently that people worship new technology without in many cases either analyzing what problem it solves or whether the benefits are worth the risks. Specifically, I recently heard a highly placed official in the Department of Defense opine about the fact that DoD wants to embrace Web 2.0 because (to paraphrase), “We need to attract and keep all these young people and they won’t work here if we don’t let them use Facebook in the workplace.” What are people going to use Facebook for in the Defense Department, one wants to know? <”Hi, my name is Achmed and I am an Al Qaeda operative. I like long walks on the beach and IEDs. Will you be my friend?” I don’t think so.>

The official went on to say that industry really needed to secure all these Web 2.0 technologies. At that point, I could not contain myself. I asked the gentleman if the Department of Defense was planning on taking container ships and retrofitting them to be aircraft carriers, or buying Lear jets and making them into F-22 Raptors? No, he said. Then why, I offered, does DoD think that the IT industry can take technologies that were never designed with security in mind and “secure them?” Why is IT somehow different that we can, ex post facto, make things secure that were never designed for the threat environment in which they are now deployed? People don’t use a road bike to mountain bike, I don’t use my short board to surf big waves (if I surfed big waves, that is, which I don’t. But if I did I’d get a really expensive blank and get someone to shape me a Big Wave Board, aka “rhino chaser”).

Your “tools” need to be designed for the environment in which they are going to operate. If they aren’t, you are going to have trouble my friend, right here in River City (with apologies to Meredith Willson). To put it even more succinctly (more apologies to Meredith Willson): “You gotta know the territory.” Meredith Willson was not writing about security when he wrote The Music Man, but “you gotta know the territory” is as succinct a description of a security weenie’s responsibilities as ever there was.

Mind you, I understand that the idea of collaboration is a powerful one and, if it is appropriately secure, can be a powerful construct. We read, for example, that the intelligence community has created an internal Web 2.0 construct called Intellipedia (along the same lines as Wikipedia). It makes sense that, instead of having one expert on, say, Syrian antiaircraft defense, that that person’s knowledge can be written down and accessed by others. In a way, that kind of collaboration facilitates “legacy” because someone who knows something valuable can share it with others far more easily than through one-on-one oral transmission. But there is a big difference between “let’s embrace collaborative constructs” and “let’s allow insecure and unsecurable Web 2.0 technologies into a classified environment.”

The key to the new is remembering the universal truths of old – legacies. This is particular true in security in that, while the attack vectors may change as the technology does, there are principles of security that do not change (“trust, but verify” works just as well for IT security as for arms control). Remembering and applying “legacy truths” will help us to avoid getting wrapped up in the latest technical fads as something “new and different” when really, it is just the same security issues wrapped in shiny new code.

There’s a great story from Jewish lore about King Solomon challenging a servant to find a magic ring for him, magic in that a happy man wearing it would become sad, and a sad man would become happy. After a long search, the servant brought to King Solomon a ring engraved, “This, too shall pass.” Technologists would do well to remember that story.

I admit to being more backward looking than forward looking. But this much I know: the “old legacy” values that Kerry lived by are still timeless ones. “Honor thy father and mother.” “I am the Lord thy God, you will have no other gods before me.” “For where your treasure is, there your heart will be also.” Kerry died penniless, but richer than anybody else I know. That he gave of himself to so many people is the legacy he leaves us, and I for one feel so blessed to have known him and to have been cherished by him. As for grief, “this too, shall pass,” and someday I will only remember the happy memories.

The only accolade – the only legacy - that matters at the end of your life is the one that I know Kerry heard from his Creator in the early hours of August 17: “Well done, thou good and faithful servant.”

E Keli, ‘o ku’u pu’uwai ‘oe, mau loa.

Remembering Kerry:

http://www.mtexpress.com/index2.php?ID=2005122267

Ua lawa.


Book of the Month: Tried By War: Abraham Lincoln as Commander in Chief by James M. McPherson

A really fascinating look at how Abraham Lincoln influence the military course of the Civil War, devising strategies that (once he could find generals who would adopt them) made a critical difference, such as attacking the Confederate lines at two different places at the same point in time. You also have a new appreciation (and frustration) of what Lincoln went through to find generals who understood how to win. And lastly, I have a new appreciation for the element of moral courage Lincoln displayed in prevailing against long odds. In 1862, the Democratic controlled Congress was whining that the war was taking too long, costing too many lives, and the North should sue for peace at any price, including taking the issue of slavery off the table. Had it not been for Lincoln’s moral courage in staying the course, the world would look very different indeed. Leadership is, among other things, taking the long moral view and not merely the expedient political one.

McPherson also wrote the Pulitzer Prize-winning Battle Cry of Freedom.

http://www.amazon.com/Tried-War-Abraham-Lincoln-Commander/dp/1594201919

It’s that time of the year again. A really lovely album of Christmas music (not all of which is in Hawaiian) is:

http://www.mele.com/music/artist/brothers+cazimero/cazimero+christmas+favorites/

Herod’s temple:

http://en.wikipedia.org/wiki/Herod's_Temple

About Meredith Willson:

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

This, too, shall pass:

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

Synthesis

Wed, 2008-07-30 07:06

This summer Idaho has had the loveliest profusion of wildflowers I’ve ever seen, the product of a healthy snow pack, full reservoirs and a late spring. Happily enough, many wildflowers have seeded themselves in my rock garden, which is far more diverse and healthy than is the case with whatever else is planted that is not coming up because I have a black thumb. (I’ve actually thought about planting weeds and hoping invasive flowers take over. A girl can dream.)

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

Skiing the Ruts

Sun, 2008-06-29 04:35

When I began writing this blog entry, it was still winter in Idaho. Then (if I may be forgiven), I got into a writer’s rut out of which I have only recently hauled my slightly frostbitten muse. E kala mai ia’u (please excuse me).

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

The Supply Chain Problem

Mon, 2008-04-07 19:46

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 21st 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/




Forces for Good in the Universe

Tue, 2008-03-18 14:12

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/

 




 

Do-Gooderitis

Thu, 2008-03-06 09:26

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 &lt;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/

 

Lies, Damn Lies, and Statistics

Tue, 2008-02-12 13:24

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,

And it must follow, as the night the day,
Thou canst not then be false to any man.

 

For More Information:

 

Book of the week - War Made New: Technology, Warfare and the Course of History: 1500 to Today by Max Boot

 

A really great read about how technological changes influence warfare. If you have no idea how IT-centric warfare now is (in terms of command and control), the last 100 pages are really insightful.

 

http://www.amazon.com/War-Made-New-Technology-Warfare/dp/1592402224

 

One of the very best security metrics kahunas I know is Dan Geer. Anyone interested in this topic should Start With Dan:

 

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

 

More on books by Arthur Herman:

 

http://books.google.com/books?as_auth=Arthur+Herman&ots=rYQc2DLq3w&sa=X&oi=print&ct=title&cad=author-navigational&hl=en

 

An article by Arthur Herman on the Vietnam War:

 

http://www.commentarymagazine.com/viewarticle.cfm/Who-Owns-the-Vietnam-War--11006

 

One of the best books on Vietnam is still Lewis Sorley's A Better War:

 

http://www.amazon.com/Better-War-Unexamined-Victories-Americas/dp/0156013096

 

Tahiti Rising

Fri, 2007-12-14 10:55

As is obvious from my previous blog entries, I have a great appreciation for n&#257; mea 'apau Hawai'i - all things Hawai'i Since Polynesian culture is not, in general, something a lot of people know anything about, I enjoy opportunities to talk about it to friends. A few weeks ago, when I was at the Army-Navy* game with an "infidel" friend (I mean, a friend who had gone to West Point instead of the Naval Academy), we talked about our relative experiences in the military, specifically, the differences between finding your way on land and finding your way on the sea. I had a chance to talk about Polynesia in the context of navigation. (I skipped over the fact that I was singularly lousy at seamanship, one of many reasons the Navy in its infinite wisdom did not make me a navigator.)

 

The traditional (Western) history of the world ascribes amazing feats of navigation to Ferdinand Magellan, who was the first to circumnavigate the globe. Personally, I'm not all that impressed, since Magellan had a compass and a quadrant at his disposal, and the rest was testosterone and favorable winds. OK, that probably isn't fair. What I mean to say is that even if Magellan deserves some accolades as a mariner, he had mechanical help (the aforementioned compass and quadrant), and he certainly wasn't the first to make long voyages in the Pacific.

 

The true master mariners, in my opinion, were the Polynesians, who traveled thousands of miles in the Pacific, between New Zealand, Tahiti, Hawai'i and the Marquesas, even Easter Island (Rapa Nui). They were able to do so using traditional Polynesian wayfinding, which considers the wind, the waters, the stars, even the birds. No mechanical assistance, in other words, which makes their navigational skills truly extraordinary. (Lewis and Clark carved a way through the wilderness; today, people can drive an RV from St. Louis, Missouri to Astoria, Oregon, with all the creature comforts of home, the interstate highway network and a GPS system. It's hardly comparable, is it?) The Polynesians navigated the Pacific long before Magellan, because they were an island people. To expand their territory, they had to become voyagers.

 

By the 1970s, the art of Polynesian wayfinding had all but died out. One of the last practitioners was a master navigator from Micronesia named Mau Piailug. He came to Hawai'i to teach Nainoa Thompson, a Hawaiian whose dream it was to sail a double-hulled voyaging canoe called the H&#333;k&#363;le'a from Hawai'i to Tahiti using Polynesian wayfinding.

 

The story is told that one night, Mau stood under a star-filled sky and asked Nainoa to point to Tahiti. Nainoa pointed to the star (h&#333;k&#363;) under which Tahiti lay. Then Mau asked him, "Do you see Tahiti?" Such a strange question; how could Nainoa possibly see an island 2700 miles away? Finally, after much thought, Nainoa said, "I see the island in my mind," to which Mau replied that Nainoa must never forget what he was seeing or he would be lost.

 

The day came when the H&#333;k&#363;le'a set sail with Nainoa as the navigator. Nainoa could see Tahiti in his mind, until the day came when H&#333;k&#363;le'a was approaching the equator, and with it a great cloud of rain. Nainoa feared that he would not be able to steer the ship without the benefit of the stars to guide him. Great fear and restlessness over came him, until he remembered Mau telling him that he needed to look inside, that he would be lost if he tried to see with his eyes. Suddenly, Nainoa had a feeling of deep relaxation, and he felt the moon over his shoulder, despite the fact it could not be seen in the cloudy sky. He was able to navigate by a sense of knowing where Tahiti was. Days later, he turned towards the horizon and saw Tahiti rising, as he had hoped and dreamed.

 

Because of the voyages of H&#333;k&#363;le'a and other Polynesian voyaging canoes over the last 30 years, the Hawaiian people have come to have great pride -  a resurgence of pride - in their culture. In fact, Hawaiian culture has had a sort of renaissance in all areas - language, music, dance. At one point, there were less than 50 native speakers of Hawaiian under the age of 18. Now, there are multiple immersion schools in the Hawaiian language and many young people speak the language. The story of H&#333;k&#363;le'a does not end with a single voyage. One man's willingness to see Tahiti rising and keep after it affected an entire culture.

 

Something else I find interesting about this story is that it challenges our assumptions that in the steady march of progress,  new technology is inevitably more sophisticated and better than knowledge built up over hundreds or thousands of years. Maybe it isn't -  maybe we are just lazier than we used to be and nobody wants to put in the time to learn anything of substance anymore.

 

I recently read a book about the impending extinction of so many of the world's languages. Loss of a language also means losing the knowledge encompassed in that language. A Siberian language (Tuvan) can use a single word to describe all the attributes of a reindeer (age, health, disposition) that are useful if you want to ride him. In English, the linguistic encapsulation of "male reindeer, 5 years old, excellent health and easy to ride" takes 11 times as many words as in the Siberian language.

 

There is no such thing as a living language with no native speakers. When a language dies - because there are no longer native speakers - the culture dies and most of the knowledge embedded in the culture dies with it. Only today, I read that pharmaceutical companies may be reaching the upper limit of what they can do with purely chemical treatments of disease: they are shifting their investments to biologically-based treatments. Of course, many indigenous peoples - many of whose languages are facing extinction - use plant and animal-based medicines, the use and utility of which is incorporated into their language. If the language dies, so does that knowledge.

 

In a strange way, we may become collectively more ignorant when we increase our reliance on technology and forget (or don't learn) what our fathers and mothers knew, however simple. How many of us have been in a checkout line when the clerk could not do basic addition and subtraction (to make change) unless the cash register was able to do it for him? I confess, I once had a perfectly lovely financial calculator that could amortize a bond for you. Unfortunately, I was able to get the right answer in some of my MBA classes while in many respects not grokking the basics of finance (one of many reasons I don't work in finance). 

 

How many people can't actually read a map any more? (I've had some spectacular failures with mapquest.com and just lived through one with a GPS system.) I cringe when I hear about people going hiking or skiing in the backcountry without basic equipment and survival skills (including a compass and knowledge of how to use it). Too many assume that they can use a cell phone to call for help if they get lost. (Not if there is no cel tower in range or your battery dies.) 

 

We've become so removed from nature that many of us have lost respect for it. A couple of years ago, some (allegedly expert) climbers decided to ascend Mount Hood in advance of a storm (I am told by my climbing friends in Idaho that you should never, ever climb thinking you will "beat" the weather. If there is a better definition of "hubris" than that I don't know what it is). The climbers died. The tragedy was that their deaths were avoidable if only they had respected the weather report. If you live in a wilderness area, you learn to respect it. You don't "tame" it anymore than you "tame" a grizzly bear.

 

A concomitant of busy lives and "more technology" is that too many of us spend too much time with gadgets and gizmos and not enough time experiencing the natural world. Dare I say, "the real world." A particularly pathetic example of this was a wealthy real estate developer who installed a state-of-the-art golf simulator in his basement. He bragged on camera (one of those home improvement shows on HGTV) that he had "played"  all the best courses in the world - from his basement. The reality is that he is so busy with work that he does not have time to actually play golf. Real golf. Playing virtual golf and saying you've played St. Andrews is like reading the Cliff Notes and saying you read Dickens. It isn't the same - not even close. It's not about your golf score, it is about being there, because the game isn't going to show you the elk that peek out on the course, the geese that fly overhead, or the particularly beautiful late afternoon lighting on the water.

 

I am sure a lot of people will read the story of Nainoa Thompson and conclude that there are lots of faster and easier ways to get to Tahiti than recreating a Polynesian voyaging canoe and learning the art of wayfaring (so, they think, "why bother?"). Just like you can play a really great round of golf in your basement, without bugs, divots, wind or other annoyances. It's only when you look at a dream of Tahiti rising that the real value of the trip becomes apparent.

 

Several years ago, I saw the H&#333;k&#363;le'a entering San Francisco Bay, and it gave me chicken skin, as the Hawaiians say. I can say this after years of seeing some of the great warships of history, and great warships of today's modern Navy: the feeling I got when I saw the H&#333;k&#363;le'a was unlike anything, because I knew what it meant to the Hawaiian people. Respect. Pride in their culture. Now, people who will never sail a double-hulled voyaging canoe can nonetheless see Tahiti in their mind, because one man could. As Antoine de Ste. Exupery said, "It is only with the heart that one can see rightly; what is essential is invisible to the eye."

 

My sister and I are writing a book together, an IT murder mystery. This is the main reason I have not been blogging as much -  my writing energies are going into the book. We have gone from chatting about "we ought to write a book together" to an outline, drafts, character sketches, and entire chapters. My sister has become the book navigator - she sees where she wants it to go, and plots the course in her mind. She is like Nainoa Thompson, being disciplined about spending time learning her craft, and always, she sees Tahiti rising. A couple of months ago, she said she wanted us to have a draft finished by the end of the year, and now, we have.

 

I can write, but I have always lacked discipline and a vision greater than "I ought to write more." I was like the guy with the golf simulator: I dabbled at something I loved but did not make time for the real deal. I needed a navigator, and my sister stepped up to the helm. I did not envision the book, or know that the moon was over my shoulder: my sister did that. And because of her, now I can see Tahiti on the horizon. For once, I will have finished a writing project I mused about and thought about but never showed the discipline to accomplish. And like the H&#333;k&#363;le'a, who knows what other adventures will come from that first dream of Tahiti? It seems fitting that the culture of Polynesia figures prominently in our book. Nainoa Thompson inspires me, too, because of all the dreams of Tahiti rising in my mind, one of which is to some day live in Hawai'i, where I already feel at home.

 

As we come to the end of another year, it is a good time for all of us to imagine what is possible if you have a star to steer by, or one you hold in your heart that you follow to a place of your imagining. Two thousand years ago, wise men followed a star to Judea, asking the question, "Where is the one who has been born king of the Jews? We saw his star in the east and have come to worship him." (Matthew 2: 2)  They were not the first - and they have not been the last - to follow a star and find more illumination than their hearts could hold.

 

* Navy won, 38-3, the 6th straight win over Army. And, the Navy quarterback is Hawaiian, how cool is that?

 

For more information:

 

Book of the week: When Languages Die: The Extinction of the World's Languages and the Erosion of Human Knowledge by K. David Harrison

 

In all the hoopla about endangered species, people forget that a substantial percentage of the world's languages are in danger of becoming extinct. Lose a language, lose a culture, and all the priceless knowledge that goes with it.  You will never look at linguists the same after reading this book.

 

http://www.amazon.com/When-Languages-Die-Extinction-Knowledge/dp/0195181921

 

Nathan Aweau (nui kona mana!) has a new CD out (Kāne’ohe) which is absolutely kamaha'o (amazing). The very first song is about seafaring voyagers (E Pi'i Mai Ke Kai), and the Hōkūle’a is in the lyric, too. Read about it or order it at:

 

http://www.nathanaweau.org/kaneohe.htm

 

About the Polynesian Voyaging Society

 

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

 

About Chicken Soup from the Soul of Hawai'i (the source of the story about Nainoa Thompson):

 

http://www.amazon.com/Chicken-Soup-Soul-Hawaii-Paradise/dp/0757300618

 

About wayfinding:

 

http://www.pbs.org/wayfinders/wayfinding3.html

http://www.celestialnavigation.net/wayfinding.html

 

More on Nainoa Thompson:

 

http://www.ifa.hawaii.edu/tops/nainoa.html

 

Herb Kawaianui Kane's amazing art of a navigator and a voyaging canoe:

 

http://hawaiiantrading.com/cgi-bin/mivavm?/store/merchant.mvc+Screen=PROD&Product_Code=hk-22&Category_Code=herb-kane&Store_Code=hieyes

http://hawaiiantrading.com/cgi-bin/mivavm?/store/merchant.mvc+Screen=PROD&Product_Code=hk-199&Category_Code=herb-kane&Store_Code=hieyes

 

And Herb Kawaianui Kane's imagining of the discovery of Hawai'i:

 

http://hawaiiantrading.com/cgi-bin/mivavm?/store/merchant.mvc+Screen=PROD&Product_Code=hk-256&Category_Code=canoe&Store_Code=hieyes

 

About the Tuvan language:

 

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

Disclosure

Wed, 2007-10-17 12:01

Many corporations have corporate ethics policies. I take a refresher ethics class online once a year at Oracle and despite the fact I think I am pretty ethical, I always get at least one question wrong.  (I think that means I am learning at least one new thing when I take the class.)

 

One of the areas most corporate policies cover is the area of conflicts of interest. For example, at Oracle, if you are asked to serve on an advisory board or board of directors of a company, you need to get multiple approvals. Approval is generally only given under certain circumstances that include consideration of whether there is a potential conflict of interest. For example, serving on an advisory board of a company in direct competition with Oracle would most likely not be approved.

 

Even in the ordinary course of business, potential conflicts of interest can arise and you are expected to disclose these. I don't know if it's my Midwestern upbringing or going to a university with a very strong honor code, but I am really big on disclosure. Probably ad nauseum disclosure: if I think something is even approaching a gray area of ethics, I email our corporate compliance officer to ask if there is an issue. And the reason is that at some point it is not merely the company's ethics policy that governs my disclosure, it's my personal integrity. I would hate to have someone think I said or did something where I appeared to be "independent" but in reality had an "angle" that was tainted by my being a stakeholder in some way.

 

Disclosure forces you to be honest with yourself as well as other people. If you have an axe to grind about something, you need to disclose who sharpens your axe if it is material to the discussion. And it often is.

 

There are many written or unwritten ethics codes that cover issues of disclosure in the business world. People who write about securities or recommend them are generally either prohibited from owning stock in companies they write about, or they have to disclose it. Imagine reading "Investment Kahuna-ette's" column in (insert name of well-respected business publication here), going out to buy the stock Ms. Kahuna-ette touted, and come to find out, she went long on the stock before the article came out (meaning, she bought the stock and hoped the price would rise). You'd feel as if Ms. Investment Kahuna-ette pumped the stock just so she'd make money, right? And if Ms. Investment Kahuna-ette did not disclose that in her column (not in subparagraph III, second sentence on some fine print document nobody could possibly be expected to find let alone read), you'd feel as if she cheated. Because she did cheat. People get fired for that.

 

One of the real downsides to the democratization of opinions that Web 2.0 represents is that where bloggers are competing with or crowding out "professionals," they are not necessarily adopting the code of ethics that some of the professionals have or at least pretend to have. This includes issues around disclosure.

 

I read an article over the weekend about how influential bloggers are to the restaurant business. On the face of it, there is nothing wrong with word of mouth spreading a restaurant's reputation; how many of us have had friends or relatives in town and asked our "foodie" friends for a restaurant recommendation? However, some of these bloggers are so successful that they quit their day jobs and blog for a living: their revenue is through advertising. So now, they are "professionals" and ought to be governed by a code of ethics. But few are.

 

Here's what I mean: professional restaurant reviewers as a matter of course (and ethics) pay for their own meals at the restaurants so they can't be accused of being "on the take." However, the "new breed" of online restaurant reviewers are apparently, as a matter of course, wooed by restaurants through "receptions" (read, "free food and drink"), after which their reviews becomes positive, what a surprise. Or, a blogger's parents who had a horrible restaurant experience were sent meal coupons (after their online blogger child ripped the restaurant). The blogger subsequently gave a rave review to the restaurant that supplied the meal coupons to his parents.

 

Now, maybe the food was really fabulous (I can't imagine any self-respecting "foodie" calling artfully presented dog food anything but "dog food," even if it was free, high end and organic dog food). However, in none of the above cases did the Influential Blogger disclose that he or she had gotten something of value for free from the restaurant. It doesn't mean they weren't entitled to an opinion, it means that they should have disclosed the freebie(s) because it likely "taints" their opinion. Or at least gives the appearance of tainting it, which is just as bad.

Other disclosure issues arise from people's business models and 
business relationships. For example, a lot of firms that are industry
analysts, since they analyze and recommend products, also work with
product vendors to guide their product directions. Many of them are
very good in their sectors and can add value to vendors trying to
ensure they solve the right customer problems. It becomes a problem
if there is de facto or implicit "tit for tat" (meaning, if the vendor does
not purchase consulting "advice," the analyst firm's "product reviews"
of the vendor suffer). It's also a problem, in my opinion, if the analyst
firm does not disclose (as they issue reports) which firms they "consult"
for and which not.* One does have to ask the question, how objective
can you be if the people whose products you review are also paying
you to give them advice? At least disclose that there is a relationship
and let the reader decide how important that relationship is.
Appearances matter.

So, what does disclosure have to do with security? A lot, as it happens, and not just the age-old "full vs. responsible disclosure" issue. Many security professionals, me included, have opinions and beliefs and we blog about them. For a lot of us, our associations don't need an explicit disclosure because they are already obvious. I don't add a disclaimer when I say something positive about Oracle in my blog because hey, I work for Oracle, my blog is hosted by Oracle, my email address has "oracle.com" in it; nobody could reasonably expect that I have a hidden agenda if I say something positive about Oracle. 

It would be different, however, if I blogged on another web site where I had a totally different email id (let's say, a hotmail account), and I claimed to be the world's biggest Oracle security fan and did not disclose that I was a security executive with the company. Any sane person's response if I did that and it came out that LuvOracleSecurity@hotmail.com (which is a made up email address as far as I know) is lil' ol' me, would be, "Hey, who are you kidding here?" And they'd be right. It's not ethical. Not even close to being ethical. ("Slimy" is the word that comes to mind.)

 

As with other sectors of life, in the security community, many people have relationships that they do not disclose that either explicitly or implicitly influence their opinions, business judgment and/or public statements. They ought to - but often do not  - disclose them.

 

For example, many security researchers also work for vendors from time to time to help them find vulnerabilities in the software. If you are a vendor, you figure if someone is a good researcher (has found a number of product vulnerabilities and worked with you well as "an independent") and you feel you can trust him/her, it can be helpful to have the researcher in to help you improve your product. We actually hired one of these individuals to run our ethical hacking team - a smart guy, good at finding vulnerabilities, and an ethical person.

 

Many vendors hire third parties to help them improve their products (disclosure: we have hired and do hire third parties to perform product assessments in addition to using our own internal ethical hacking team). Also, typically, you have some contractual restrictions on what the researchers can do with the information they find under contract. Most of these items are covered by a confidential disclosure agreement (sometimes called a non-disclosure agreement) and the thinking behind it is, "Hey, I am paying you to tell me about what you find so I can fix it, and I want time to fix it. So, Mr. Researcher, I don't want you doing a paper about this until some period after you report the bug and I fix it, to make sure customers are protected, and I don't want you ever releasing exploit code because I think it puts people at risk." Fair enough.


 

So, where does disclosure come into it? Just this: since many researchers who do "work for hire" for vendors are prevented from talking about what they are working on for Vendor X, they can - and often do - start talking about Vendor Y. Researchers do not generally have big PR agencies working for them and creating a media splash is "free marketing" that works pretty well. And because controversy sells, they may not be saying nice things about Vendor Y. None of this is necessarily a problem if Vendor Y is actually in the wrong. If you are guilty of tormenting small mammals, and a third party says so publicly, you have no cause to complain that you were wronged. Be nice to the critters and your PR problem goes away. But to the extent that the researcher is prohibited from talking at all about Vendor X, or does not disclose that he does work for hire for them, his opinion is potentially tainted to the extent he speaks about Vendor X or others in their market sectors. Just like the restaurant reviewers, if Vendor X paid me or gave me something for free, and I now say glowing, wonderful things about their product, I ought to disclose that I am or have been on their payroll or that I am getting freebies.

 

Even if we debate responsible disclosure (about the vulnerabilities themselves, which is another charged area) there should be no debate about the ethics of disclosing business relationships if you are going to set yourself up as "an independent expert." If you are on someone's payroll, you are not independent anymore, though you may still be an expert.

 

Quite honestly, even if you cannot speak or are restricted in how you speak about Vendor X, you need to disclose that or you have no moral leg to stand on in discussing disclosure - of any kind - with anybody. You might still be right in what you say, but at least the reader can correctly surmise that you might not be telling all you know about Vendor X - because you can't.  If I am evaluating an expert's opinion, knowing what he cannot say or is not saying is at least as important as knowing what he can and does say.

 

I have a final thought on what is at the core of the disclosure issue for me, and that is the age-old but never surpassed virtues of honor and integrity. I mentioned earlier that I had gone to a university with a strong honor code: the University of Virginia. The single biggest reason I went there wasn't the beautiful architecture, though it is stupendous. Many buildings were designed by Thomas Jefferson: in 1976, Jefferson's Lawn and Rotunda were named the most outstanding architectural achievement in 200 years of American history by the American Institute of Architects (AIA). It wasn't the beauty of The University though there is that: the only time I have experienced love at first sight was seeing UVA in fall when I went there as a high school senior to check it out. I applied to UVA, and only UVA, and got in. It wasn't the fact that the engineering program was designed to turn out well-rounded graduates (I had to read More's Utopia and Plato's Republic as an engineering school requirement!), though that appeals to my literary side.

 

Nope, I went to UVA because they had an honor code that means something. It's one of the oldest honor codes in the country, and there is still a single sanction for honor violations: dismissal. Because there are no degrees of honor. If you think that there are degrees of honor, and cheating, lying and stealing are all excusable depending on day of the week, your mood, or your "value system," then you are welcome to attend another university: UVA does not want you there, and they make that clear in their recruiting materials. And as a graduate, I don't want people attending there who do not believe in and subscribe to the honor code. There is a beautiful gateway at UVA at one of the entrances, on which is incised: "Enter by this gateway and seek the way of honor, the light of truth and the will to work for men." Says it all.

 

The University recently sent a number of alumni/ae a link to some new ads they are going to run during televised football games. The emphasis in these ads was "diversity." And I was upset, but not because I have anything against diversity, if by that one means "commitment to the highest standards of academic excellence by all members of the university community, regardless of background." But what the school stands for, really and truly stands for, that makes it different from all others is the honor code, and that is what the ads should have stressed. Furthermore, in matters of honor, there should be no diversity. Whoever you are, wherever you come from, you live by the University of Virginia honor code, with its single sanction, or you go someplace else. A single code for all, and a single sanction for violations: dismissal.

 

There are precious few bastions in this country that have not fallen by the wayside to "everyone does it," "lying, cheating and stealing are just 'different values' that need to be tolerated," and "you can't expect people to live up to some arcane old ideal." (Except that I can and I do expect it.) One of these bastions is the University of Virginia. The other bastions include the service academies: the Naval Academy, the Military Academy, the Air Force Academy, the Coast Guard Academy. And for many of these schools, part of the honor code includes creating a community of honor: "A cadet will not lie, cheat or steal, nor tolerate those who do."

 

West Point has a single, straightforward motto that every cadet remembers because it is engraved on the West Point coat of arms. It is "Duty, Honor, Country." It was also among the last phrases to be quoted by GEN Douglas MacArthur at his stirring farewell address: "In my dreams I hear again the crash of guns, the rattle of musketry, the strange, mournful mutter of the battlefield. But in the evening of my memory I come back to West Point. Always there echoes and re-echoes: Duty, Honor, Country."

 

Need I add that "Duty, Honor, Country" is a lot worthier ideal than "Me, myself, and I," which seems to be the ruling ethos of so many?

 

For me, the issues around disclosure are not really as complicated as people seem to think they are. It goes back to honor. Honorable men and women disclose the nature of relationships when the existence of that relationship gives the appearance of - or substance to - a tainting of their opinions or a conflict of interest. If there is, as yet, no professional code of ethics in the security community, it is time we had one, and we can start with acting honorably as individuals: if your opinion looks to be or is influenced by a business relationship, disclose the relationship. You may still be right in what you say when you have an axe to grind, but the reader will know who sharpens your axe.

 

* Note: even if the vendor does not want the relationship disclosed for a variety of reasons, an analyst firm typically can say that they consult to players in the same space.  It has the same disclosure effect for their allegedly impartial reviews, but saves the initial vendor's confidentiality requirement.  This type of arrangement is common in the securities industry.

 

For more information:

 

Book of the week: Mr. Pip by Lloyd Jones. I do not generally like much modern fiction, especially as so much is of the post-modernist drivel variety.  However, a single great book can change your life, which happens to be the conceit of this story. After a revolution breaks out on Bougainville, the last white man on the island becomes a teacher, and he teaches the children by reading them Dicken's Great Expectations. A magical, special book that enriches your soul.

 

About the University of Virginia Honor Code:

 

http://www.virginia.edu/uvatours/shorthistory/code.html

 

A virtual tour of Jefferson's Academical Village at:

 

http://www.virginia.edu/academicalvillage/#

 

Pictures of UVA:

 

http://www.pbase.com/steveyaphotos/the_university_of_virginia

 

A link on honor codes:

 

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

 

General Douglas MacArthur's Farewell Speech at West Point:

 

http://www.nationalcenter.org/MacArthurFarewell.html

 

The Coat of Arms of West Point:

 

http://www.usma.edu/PublicAffairs/Press_Kit_files/CoatArms.htm

 

A great biography of Douglas MacArthur is still American Caesar by William Manchester, which you can find at:

 

http://www.amazon.com/American-Caesar-Douglas-MacArthur-1880-1964/dp/0440304245

 

(I found out a few years ago that my dad had actually met Douglas MacArthur a couple of times while serving in Japan after WWII. How cool is that?)

 

Pages