Skip to content

Author Archives Mary Ann Davidson

The Supply Chain Problem

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?partner=rssnyt&emc=rss


 


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/





Posted 08 April 2008 § Uncategorized ‡ Comments Off °

Forces for Good in the Universe

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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


Who is on my network?


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


What is happening that I should be worried about?


 


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


 


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


 


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


 


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


 


For More Information:


 


Book of the Week: Lone Survivor by Marcus Luttrell.


 


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


 


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


 


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


 


The citation for Michael Murphy’s Medal of Honor:


 


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


 


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


 


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


 


More on the IT Security Entrepreneur’s Forum:


 


http://www.publicprivatepartnerships.org/


 


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


 


http://www.greenplug.us/


 


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


 


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


 


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


 


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


 





 

Posted 19 March 2008 § Uncategorized ‡ Comments Off °

Do-Gooderitis

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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


 


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


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


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


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


 


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


 


For More Information:


 


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


 


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


 


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


 


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


 


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


 


Check it out at:


 


http://www.lelegowau.com/


 

Posted 06 March 2008 § Uncategorized ‡ Comments Off °

Lies, Damn Lies, and Statistics

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


 

Posted 13 February 2008 § Uncategorized ‡ Comments Off °

Tahiti Rising

As is obvious from my previous blog entries, I have a great appreciation for nā 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ōkū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ōkū) 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ōkūle’a set sail with Nainoa as the navigator. Nainoa could see Tahiti in his mind, until the day came when Hōkū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ōkū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ōkū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ōkū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ōkū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ōkū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

Posted 14 December 2007 § Uncategorized ‡ Comments Off °

Disclosure

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.