Author Archive for Chandler Howell

Human Error and Incremental Risk

Published by Chandler Howell on February 23, 2010 in argument. 4 Comments

As something of a follow-up to my last post on Aviation Safety, I heard this story about Toyota’s now very public quality concerns on NPR while driving my not-Prius to work last week.

Driving a Toyota may seem like a pretty risky idea these days. For weeks now, weve been hearing scary stories about sudden acceleration, failing brakes and car recalls. But as NPRs Jon Hamilton reports, assessing the risk of driving a Toyota may have more to do with emotion than statistics.

Emotion trumping statistics in a news article?  Say it isn’t so!

Mr. LEONARD EVANS (Physicist, author, Traffic Safety): The whole history of U.S. traffic safety has been one focusing on the vehicle, one of the least important factors that affects traffic safety.

HAMILTON: Studies show that the vehicle itself is almost never the sole cause of the accident. Drivers, on the other hand, are wholly to blame most of the time. A look at data on Toyotas from the National Highway Traffic Safety Administration confirms this pattern.

Evans says his review of the data show that in the decade ending in 2008, about 22,000 people were killed in vehicles made by Toyota or Lexus.

Mr. EVANS: All these people were killed because of factors that had absolutely nothing to do with any vehicle defect.

HAMILTON: Evans says during that same period, its possible, though not yet certain, that accelerator problems in Toyotas played a role in another 19 deaths, or about two each year. Evans says people should take comfort in the fact that even if an accelerator does stick, drivers should usually be able to prevent a crash.

(bold mine)

From 1998 to 2008, about 2,200 people per year (out of a total of about 35,000 total vehicle deaths per year) died in Toyotas because of some sort of non-engineering failure.  During that same period, just under two people were killed per year due to the possible engineering failure.  So all this ado is about, at most, a 0.09% increase in the Toyota-specific death rate and a 0.005% increase in the overall traffic death rate.

So why is the response so excessive to the actual scope of the problem?  Because the risk is being imposed on the driver by the manufacturer.

Mr. ROPEIK[(Risk communication consultant)]: Imposed risk always feels much worse than the same risk if you chose to do it yourself. Like if you get into one of these Toyotas and they work fine, but you drive 90 miles an hour after taking three drinks. That won’t feel as scary, even though its much riskier, because you’re choosing to do it yourself.

And, lest we forget, even in the case where the accelerator did stick there was still a certain degree of human error:

Mr. EVANS: The weakest brakes are stronger than the strongest engine. And the normal instinctive reaction when you’re in trouble ought to be to apply the brakes.

My frustration is when I compare the reality of the data with most of the reporting on the subject, I think of Hicks’ Hudson’s NSFW “Game Over” rant. (Corrected per the comments.  Thanks, 3 of 5!)

After all, given that you’re more likely to die in your home (41%) than in your car (35%), you’re still statistically safer taking to the road than sitting home cowering in fear of your Prius.

Human Error

Published by Chandler Howell on February 22, 2010 in Doing it Differently and research papers. 1 Comment

In his ongoing role of “person who finds things that I will find interesting,” Adam recently sent me a link to a paper titled “THE HUMAN FACTORS ANALYSIS AND CLASSIFICATION SYSTEM–HFACS,” which discusses the role of people in aviation accidents.  From the abstract:

Human error has been implicated in 70 to 80% of all civil and military aviation accidents. Yet, most accident reporting systems are not designed around any theoretical framework of human error. As a result, most accident databases are not conducive to a traditional human error analysis, making the identification of intervention strategies onerous. What is required is a general human error framework around which new investigative methods can be designed and existing accident databases restructured. Indeed, a comprehensive human factors analysis and classification system (HFACS) has recently been developed to meet those needs.

Consider that pilots, whether private, commercial, or military, are one of the more stringently trained and regulated groups of people on the planet.  This is due, at least in part, to the history of aviation.  As the report notes,

In the early years of aviation, it could reasonably be said that, more often than not, the aircraft killed the pilot. That is, the aircraft were intrinsically unforgiving and, relative to their modern counterparts, mechanically unsafe. However, the modern era of aviation has witnessed an ironic reversal of sorts. It now appears to some that the aircrew themselves are more deadly than the aircraft they fly (Mason, 1993; cited in Murray, 1997). In fact, estimates in the literature indicate that between 70 and 80 percent of aviation accidents can be attributed, at least in part, to human error (Shappell & Wiegmann, 1996).

One upon a time, operating an airplane was so dangerous that only highly-skilled experts could do it, and even then the equipment would get out of their control and crash.  Later (yet still almost twenty years ago), the equipment improved to the point that equipment failure no longer overshadowed operator error, but planes still get out of control and crash.

Other than the fact that pilots are almost universally still highly-skilled and/or trained operators, this doesn’t sound all that different from the evolution of computing.

Flight has obviously never really had the adoption rate explode like PC’s in the Age of the Web, but there is still a strong parallel between aircraft accidents and Information Security failures.  This assertion becomes even more true once the paper gets into James Reason’s “Swiss Cheese” model of understanding root causes of aircraft accidents.

Reason identifies four factors that interact with each other increase accident rates, which I’ll paraphrase as:

  1. Unsafe Acts — This is the cause of the active failure (i.e. crash), such as a poor decision or a failure to watch the instruments or otherwise recognize the unsafe situation was forming or occurring
  2. Preconditions for Unsafe Acts– Situations that increase risk of an accident, such as miscommunication between aircrew members or with others outside the aircraft, such as air traffic control
  3. Unsafe Supervision– failures of management or leadership to recognize when they are, for example, pairing inexperienced pilots together in less-than-optimal conditions
  4. Organizational Influences — Usually business-level decisions, such as reducing training hours to reduce costs

How familiar does this sound?  If you’ve ever read an IT Audit report, this should seem painfully familiar, even if only analogously.  The paper provides a strong taxonomy within each area, and I could easily drill down at least one more level into each one.  Read the paper to learn more and become a better professional problem solver, security-related or otherwise.

For example, using a real-world case I dealt with recently.  This is an easy example which ties the four levels together more neatly than many, so consider it an “Example-Size Problem” and extend as you see appropriate.

The incident was the loss of sensitive business information, which I personally believe hurt the company in a negotiation:

  1. Unsafe Act:  The VP left his unencrypted laptop unattended while at a meeting — this was the Active Failure/Unsafe Act that led to the Mishap
  2. Preconditions:  The VP assumed that others were watching his laptop, but did not explicitly confirm this fact
  3. Unsafe Supervision:  Despite knowing that Executives are high-risk users with regards to sensitive information on their laptops, the IT Executive Support Team had recommended against deploying Full-Disk Encryption on executives’ laptops because they feared being held accountable if an executive lost information due to an encryption system failure
  4. Organizational Influences:  While a Laptop Encryption Policy existed and specified that the VP should have been encrypted for multiple reasons, the policy was widely ignored, there was no cultural pressure to ensure that mobile information was protected, and thus compliance was unacceptably low.  No pressure to comply was generated by Executive management because the cost associated with doing so was considered to be prohibitive.

In this case, the damage (opportunity cost) of lost revenue due to that single lost laptop was many multiples of the complete cost of deploying a Full-Disk Encryption system.  Unfortunately, in the absence of a comprehensive analysis of the series of failures leading up to the unsafe act, the real root cause of an incident may be ignored or mis-assigned, leading to either an incomplete or unsustainable remediation course.

When incidents occur, it’s rare to see a true and honest assessment not just what went wrong, but why.  Too often, in fact, the culture seems to be to put it down to, “nobody could have predicted it.”  Reject these assessments.  To improve an organization, we must refuse to accept these explanations.  Instead, find the root cause–all the way up to the Organizational Influences–and then Fix It.

V-22 Osprey Metrics

Published by Chandler Howell on February 3, 2010 in Uncategorized and metrics. 2 Comments

Metrics seem to be yet another way in which Angry Bear noticed that the V-22 Osprey program has hidden from its failure to deliver on its promises:

Generally, mission capability runs 20% higher than availability, but availability is hidden on new stuff, while shouted about on older stuff, because there would be severe embarrassment if you considered that 40% of the brand new V-22 were not available (okay 60% available sounds much better, buy a car which is broke 40% of the time, how good does the warranty service need to be?).
The Navy and GAO are not sure which metrics to use. One of the reasons that US quality fell in the 70’s was avoiding measuring the hard things [that] gets you in trouble; a weakness of the DoD acquisition process. But the spending is more important than meaningful results.
Missing mission capable suggests that basic reliability and maintenance performance are not part of V-22 repertoire. Quality may not have been affordable during the long development cycle, and the savings are now costing in added support and lost use of the V-22

And as one commenter notes, the problem is even more fundamental than poor quality–the Osprey “cannot do a lot of what it is replacing:  HH 53 and HH 46.”  I would pretty much guarantee that no one is measuring the number of missions that are not performed by the Osprey but which could have been by the helicopters it replaced.

Metrics are powerful tools, but they can be as much a force for evil as a force for good.  Choosing the easy-to-gather metrics or the metrics that make the thing being measured look better may play well in Slide-Deck-Land, but it doesn’t change the fact that there is still a reality lurking underneath there which isn’t going away just because someone refuses to measure it.

What people choose to measure can tell you a lot about both their competence and their motivations.  Ignore it at your peril.

How not to do security, Drone Video Edition

Published by Chandler Howell on January 4, 2010 in Doing it Differently. 3 Comments

This is probably considered to be “old news” by many, but I’m high-latency in my news at the moment.

Much was made of the fact that the US Military’s enemies are now eavesdropping on the video feeds from US Drones on the battlefield using cheaply available commercial technology.  But it’s OK, because according to the Military, there was a Good Reason why it wasn’t encrypted:

The reason the U.S. military didn’t encrypt video streams from drone aircraft flying over war zones is that soldiers without security clearances needed access to the video, and if it were encrypted, anyone using it would require security clearance, a military security expert says.

I can only hope that this is not really what passes for logic among the security decision-makers in the U.S. Military and their contractors.  There is additional information in the article which tells us that they at least performed a risk assessment, but the assessment seems to have been flawed.

It’s always easy to second-guess decisions in hindsight, but if the rationale given is even minimally truthful, then what they have essentially said is, The video feed was not encrypted because the policies which would have then applied would have been too onerous.

That’s not to say that my summary of the rationale is not sound in certain cases–after all, the processes necessary to comply are part of the cost of a countermeasure.  But in this case, the policy was clearly flawed  Who wants to bet that the same un-cleared soldiers never have access to encrypted radio links, or that they use military Web sites encrypted with SSL?

Access to (shared or symetrical) encryption keys probably does (and probably should) require a clearance, but claiming that requirement would extend to utilizing the encrypted link as rationalization for not doing so strikes me as a bit absurd.

Similarly, this justification:

…the video information loses its value so rapidly that the military may have decided it wasn’t worth the effort to encrypt it. “Even if it were a feed off a drone with attack capabilities, and even if the bad guys saw that the drone was flying over where they were at that moment, they wouldn’t have the chance to respond before the missile was fired,”

also fails to pass muster.

A key element of insurgency and counter-insurgency is the hide-and-seek aspect of it.  The initial value of drones was their ability to monitor large areas in real time and loiter on-scene for much longer (and more cheaply) than conventional aircraft.   As a result, drones are a huge force multiplier for the US and its allies in counter-insurgency operations.  If the insurgents are able to determine where the US forces are looking for them, that is extremely valuable intelligence to the insurgents, since they can then identify which logistical routes or encampments are potentially compromised and re-route forces accordingly.

Using drones as a delivery platform for munitions, on the other hand, is relatively rare and was not, in fact, even in-scope for the drones when initially deployed.

As a general rule, justifications for risk acceptance based on exceptional cases should be taken as evidence that the  decision was bad.  This is not an exception to that rule.

Airplane Terrorism, Data-Driven Edition

Published by Chandler Howell on December 31, 2009 in Uncategorized. 0 Comments

I’m just off a flight from London back to the United States and I’m hesitant to attempt to think while jet-lagged.  I’ll have some more thoughts and first-hand observations once my head clears, however.

In the meantime, Nate Silver has broken down the risk of terror attacks on airplanes so I don’t have to.  Summarizing his points, the odds of a terror attack can be variously expressed as:

  • one terrorist incident per 16,553,385 departures
  • one terrorist incident per 11,569,297,667 miles flown. This distance is equivalent to 1,459,664 trips around the diameter of the Earth, 24,218 round trips to the Moon, or two round trips to Neptune.
  • one incident per 3,105 years airborne
  • the odds of being on given departure which is the subject of a terrorist incident have been 1 in 10,408,947 over the past decade. By contrast, the odds of being struck by lightning in a given year are about 1 in 500,000

    • One point that Nate mentions up front, but doesn’t elaborate on, is that these are the odds of being on a plane that’s attacked.   A third of those attacks failed and no one but the terrorist was injured (Richard Reid and the latest Christmas Day attack).

    That’s right, you are twenty times more likely to be struck by lightning than to be on a plane that’s the target of an attack, and almost thirty times more likely to be struck by lightning than to be killed or injured in a terrorist attack.

    Pick your preferred typical comparison, but you’ll find that they’re all several orders of magnitude more likely than airline terrorism.

    All in the Presentation

    Published by Chandler Howell on December 5, 2009 in Amusements and Links. 0 Comments

    America’s Finest News Source teaches an excellent lesson on how to spin data:

    Labor Dept: Available Labor Rate Increases To 10.2%

    WASHINGTON—In what is being touted by the Labor Department as extremely positive news, the nation’s available labor rate has reached double digits for the first time in 26 years, bringing the total number of potentially employable Americans to an impressive 15.7 million.

    Engineers vs. Scammers

    Published by Chandler Howell on December 5, 2009 in Doing it Differently, Reports and Data and Uncategorized. 0 Comments

    Adam recently sent me a link to a paper titled, “Understanding scam victims: seven principles for systems security.”  The paper examines a number of real-world (i.e. face-to-face) frauds and then extrapolates security principles which can be applied generically to both face-to-face and information or IT security problems.

    By illustrating these principles with examples taken from the British television series The Real Hustle, they provide accessible examples of how reasonable, intelligent people can be manipulated into making extremely poor (for them) decisions and being defrauded as a result. Perhaps you’re thinking, “That’s all well and good, but what do I care about other people getting scammed due to behaviors that I would like to believe I would never engage in?”

    It’s a nice idea, and while it may hold true with some of them, such as the Dishonesty Principle (“It’s illegal, that’s why you’re getting such a good deal.”), many of these scams work not because the person is trying to do something sneaky, because they’re either trying to “Do The Right Thing,” e.g. The Social Compliance Principle, just get the job done, such as the Distraction Principle, or just plain get fooled, e.g. the Deception Principle,

    So, like it or not, the paper would seem to tell us, you’re Damned if You Do, Damned If You Don’t, and eventually you’ll let your guard down at just the wrong time. The sub-title of the paper might as well have been, “Why your security system will eventually fail, no matter how good it is.”

    So what’s the point of trying?

    Well, first off, because all hope is not lost—even if you don’t read the paper, there are a number of points to consider, two of which I want to call out because they are essential to designing or analyzing a security system (or, really, a system which requires a degree of security):

    • Identify the cases where the security of your system depends on an authentication task (of known people, of unknown people or of “objects”, including cash machines and web sites) performed by humans.

    • Understand and acknowledge that users are very good at recognizing known people but easily deceived when asked to “authenticate”, in the widest sense of the word, “objects” or unknown people.

    By understanding how and why systems fail, we can design them in such a manner as to avoid the failure. For example, never forget that authentication is really a two-way street, even most people are generally bad (at best) and oblivious (in general) to their role in the problem.

    In the case of an ATM, the traditional security efforts are around protecting the ATM from malicious users. The fact that the users must also be protected from malicious ATM’s never seems to come up. Likewise, phishing and other forms of credential harvesting depend on the victim being unable to accurately authenticate the requester of their credentials, whether due to falling prey to Distraction, Deception, or Social Compliance.

    By understanding this and explicitly forcing that problem to be considered “in-scope” by the system designers, we accomplish two important security goals. First, we address the fact that authentication is a two-way street, even if only it only a formal process (e.g. logging in) in one direction. Second, we expand the pool of people working on solving the problem and thus potentially creating a valuable innovation which can be applied across that problem elsewhere.

    What we can’t do is take the easy way out and “blame the users.” In fact, the authors even close their paper by reminding us of this fact:

    Our message for the system security architect is that it is naïve and pointless just to lay the blame on the users and whinge that “the system I designed would be secure if only users were less gullible”; instead, the successful security designer seeking a robust solution will acknowledge the existence of these vulnerabilities as an unavoidable consequence of human nature and will actively build safeguards that prevent their exploitation.

    While Adam, Alex and I were discussing the paper, Adam took the bold step of declaring that,

    The principles that tell an engineer what to do are better than those that tell a scammer what to do.

    Personally, I’m going to confess that while I don’t disagree with his statement, I don’t think it matters, either. Engineering principles can help us make better decisions and design better systems, but unfortunately, they don’t let us make perfect decisions or design perfect solutions. Fortunately, even if they did we’d still have innovation elsewhere to create new and interesting problems which people would employ us to solve.

    Regardless, there will always be an interplay of innovation and reaction on both sides of the equation—for scammers or attackers and for security engineers or defenders*. The attackers find a hole, the defenders find a way to close it or render it ineffective. So the attackers find a new hole, ad infinitum. The hole can be a weakness in an IT system, a business process, or, as is the case in many of the examples in Part One, the human brain.

    Here’s where it gets tricky, though. Most defenders work for Someone Else. By that, I mean that they are employees of, either directly or by contract, of some other entity who is in the business of Getting Something Done. The entity is typically not in the business of Securing Things. Thus, the Distraction Principle is already working against us before we ever even get to work in the morning.

    Next, once the asset is not something obviously valuable, such as money, people’s ability to recognize it as such fails rapidly, especially when they interact with it on a day-to-day basis. This is especially true when trying to protect trade secrets and other Intellectual Assets. I have been in meetings where Very Senior people were asked to identify the critical secrets in their branch of the organization and they were unable to do so. It’s not that they didn’t have any, it’s that they couldn’t pick them out of the crowd of their responsibilities because everyone they dealt with was also authorized to see them, so they had no recurring reminder or other filtering mechanism.  This is one of the reasons that Top Secret documents are stamped “Top Secret.”

    In the examples from the paper, scammers utilize the opposite form of this problem in their principle of Deception, by convincing people that valueless things are actually, in fact, valuable—fake diamond rings, TV boxes with rocks in them, etc. In the corporate world, people don’t know, understand or remember what’s valuable, and thus are unable to properly prioritize protecting it among their other responsibilities (the Distraction Principle again).

    Thus, I would argue that the issue is that people are just bad at accurately assessing value; that their ability to do so degrades over time; and that their ability is further weakened when scammers manipulate them.  Call it the Valuation Principle. This, in turn, makes them more vulnerable to a variety of ways of losing their valuables, be it cash, a car, or a Trade Secret, by application of the other Principles in the paper.

    The challenge is that while it’s irrational to protect everything if only a small portion of the assets need the highest level of protection, most people (and thus, their organizations) are really bad at determining what level of security an asset actually requires (even with tools like classification and risk assessment).  Cost-effective Information Protection is as much about determining what to protect as ensuring that it’s protected.

    * I assign these roles under the assumption that the defender holds an asset that an attacker wants to access or possess.

    Visualization Monday: Storage

    Published by Chandler Howell on November 30, 2009 in Uncategorized. 1 Comment Tags: .

    This is cool.  Visualization of relative storage capacities in terms of media and format.

    storage-cropped

    Notice that it goes all the way back into pre-digital forms, a subtle tweak that I’ll bet a lot of people miss on first inspection.  Too bad, too, since the ability to seamlessly compare seemingly-different things is a valuable skill when explaining risk and security issues.

    Rational Ignorance: The Users’ view of security

    Published by Chandler Howell on November 19, 2009 in Data Analysis, Reports and Data and metrics. 6 Comments

    Cormac Herley at Microsoft Research has done us all a favor and released a paper So Long, And No Thanks for the Externalities:  The Rational Rejection of Security Advice by Users which opens its abstract with:

    It is often suggested that users are hopelessly lazy and unmotivated on security questions. They chose weak passwords, ignore security warnings, and are oblivious to certi cates errors. We argue that users’ rejection of the security advice they receive is entirely rational from an economic perspective.

    And you know it’s going to be good when they write:

    Thus we find that most security advice simply offers a poor cost-benefit tradeoff to users and is rejected.  Security advice is a daily burden, applied to the whole population, while an upper bound on the benefit is the harm suffered by the fraction that become victims annually.  When that fraction is small, designing security advice that is beneficial is very hard.  For example, it makes little sense to burden all users with a daily task to spare 0.01% of them a modest annual pain.

    People are not stupid.  They make what we, as relative experts on the topic of security, perceive to be bad decisions, but this paper argues that their behavior is rational.

    [W]e argue for a third view, which is that users’ rejection of the security advice they receive is entirely rational from an economic viewpoint.  The advice o ers to shield them from the direct costs of attacks, but burdens them with increased indirect costs, or externalities. Since the direct costs are generally small relative to the indirect ones they reject this bargain. Since victimization is rare, and imposes a one-time cost, while security advice applies to everyone and is an ongoing cost, the burden ends up being larger than that caused by the ill it addresses.

    The paper provides both a good and accessible overview of externalities and rational behavior using spam as an example.

    For example, Kanich et al. [32] document a campaign of 350 million spam messages sent for $2731 worth of sales made. If 1% of the spam made it into in-boxes, and each message in an inbox absorbed 2 seconds of the recipient’s time this represents 1944 hours of user
    time wasted, or $28188 at twice the US minimum wage of $7.25 per hour.

    Coincidentally, we get a little over 300 million spam messages into our corporate email gateways every month, which means that I can compare the cost-per-delete-click (at $7.25/hour) against the cost of our corporate spam filtering contract without having to do any real math.  Since we pay about $50,000/month for filtering.  That means that we’re getting a pretty good deal, since our white-collar employees cost over $14/hour.

    That’s just time that would be spent seeing and deleting the message, don’t forget.  Fourteen Dollars per hour completely ignores the cost of attention disruption (much more than two seconds) and the Direct Losses, either because I cannot quantify, which causes the entire argument to appear specious in the eyes of  Senior Leadership, or I am not at liberty to disclose enough detail to pass the “cannot quantify” test.

    They then go on to document in fairly accessible models why password complexity, anti-phishing awareness, and SSL Errors are cost-inefficient, and get into a favorite topic of mine, the difficulty of defining security losses or the benefit from adding safeguards at the end-user level.  This section should be mandatory reading for any security person who attempts to talk to non-security people about the topic–i.e. all of us.

    What’s missing from the paper, though, is the next logical step of analysis, the appropriate Risk Management strategy in response to the information presented. Hopefully that will be the follow-on paper, because as it was, it felt like a bit of a cliff-hanger to me.  All of the discussion assumes that mitigation is the only option.  This may feel right from a Security perspective, but it’s probably not the correct risk management decision.

    To manage the risk in these cases, though, I see a strong argument for risk transfer.  High-Impact, Low-Likelihood events are best managed by aggregating the risk into a pool and spreading the cost across the pool, i.e. buying insurance against these losses.  If you could buy anti-phishing insurance for $1/person/year (which, realistically, is multiples of what it could cost if 200 million people all bought in) rather than throwing large, uncoordinated piles of money at ineffective awareness training or technical countermeasures which will probably be out-innovated by the attackers in hours or days, why wouldn’t you?

    Why have anti-virus vendors not thought of this?  If your AV vendor said they would also insure you against Direct Losses (having your bank account cleaned out) for your $50/year subscription, would that differentiate them enough to win your business?

    By all means, we should continue to work on the challenges of improving the security experience and reducing the risk of using computers.  More accurately, though, we should be reducing the amount that must be experienced by users at all to improve security of their information and transactions.

    Cures versus Treatment

    Published by Chandler Howell on August 28, 2009 in Uncategorized. 0 Comments

    A relevant tale of medical survival over at The Reality-Based Community:

    Three years ago a 39-year-old American man arrived at the haematology clinic of Berlin’s sprawling Charité hospital. (The venerable Charité, one of the great names in the history of medicine, used to be in East Berlin, but it’s now the brand for the merged university hospitals of the whole city.) He had both leukaemia and HIV; you wouldn’t have given much for his chances. Now he has neither. How?

    …

    The great cancer researcher and medical writer Lewis Thomas wrote this in 1983 (The Youngest Science, endnote to page 175). The context is his stint as an adviser on health policy in Lyndon Johnson’s White House in 1967:

    We recognised three levels of medical technology:

    (1) genuine high technology, exemplified by Salk and Sabin poliomyelitis vaccines, which simply eliminated a major disease at very low cost by providing protection against the three strains of virus known to exist;

    (2) “halfway” technology, applied to the management of disease when the underlying mechanism is not understood and when medicine is obliged to do whatever it can to shore things up and postpone incapacitation and death, at whatever cost, usually very high indeed, illustrated by open-heart surgery, coronary artery bypass, and the replacement of damaged organs by transplanting new ones…

    and (3) nontechnology, the kind of things doctors do when there is nothing at all to be done, as in the case of patients with advanced cancer and senile dementia.We suggested that the rising cost of health care was resulting from efforts to treat diseases of the halfway or nontechnology class, and recommended that basic research on these ailments be sponsored by NIH.

    Thomas’ analysis still looks spot on to me. But his optimism has so far not proved justified: the billions poured into medical research ever since have led to many improved treatments but disappointingly few cures. The ideal state for Big Pharma is represented by the state of the art on diabetes and HIV: costly lifelong treatments. For most lethal conditions, we don’t have even that.

    Information Security also seems to be stuck in the “halfway” technology mode.  We treat the symptoms by patching and deploying security products to prolong survival, but as of yet, there is no cure.

    In most organizations, it’s even worse.  Lack of basic knowledge and awareness, lack of funding and/or misplaced risk tolerance produce more nontechnology, such as Business Acceptance of Risk Forms and Security Dashboards where vanity metrics provide CYA.

    Even when we know what the Right Things to reduce a risk are, whether turning off the TV, eating right and getting some exercise or removing admin rights and keeping crapware off the machines, we as a society and as companies all-to-rarely seem to have the will to make it happen.

    To twist a line from Dean Wormer, “Fat, dumb and pwned is no way to go through life, son.”