Cooperation, Not Blame, Leads to Better Solutions

 
 
By Peter Coffee  |  Posted 2002-01-14 Email Print this article Print
 
 
 
 
 
 
 

Peter Coffee: National Academy's recommendation that vendors face more liability for security flaws is wrong-headed.

Perhaps youve heard the story about the physicist, the engineer, the economist and the can of beans. The three people find themselves stranded on an island with no other food and with limited tools, and theyre discussing their options. "We could heat the can until it explodes," suggests the physicist. "Wed need to have some kind of enclosure, or wed lose the beans," observes the engineer. The physicist is applying a useful principle, but is overlooking the point that the goal is to get the beans, not merely to open the can; the engineer keeps the essential purpose in mind. I thought of this story when I read the National Academy of Sciences report, "Cybersecurity Today and Tomorrow: Pay Now or Pay Later." You wont find new technical information on exploits or countermeasures in this concise document; rather, its a 48-page treatise that uses recent events (including the 9/11 attacks) as context for an overview of past reports that are anywhere from two to 10 years old.
Isnt it depressing that such well-aged observations are still points well worth making in security discussions?
The document provides a useful strategic overview of security issues, in terms that can readily be understood by non-IT management. Particularly poignant is its comment on the failure of the federal governments "Orange Book" criteria to elevate the security of federal IT practices: "The government demanded secure systems, industry produced them, and then government agencies refused to buy them because they were slower and less functional than other nonsecure systems available on the open market." If the document makes a single most important point, its that rational IT buyers generally pass over secure systems because they are, almost invariably, later to market with less capability than competing systems that are built from off-the-shelf components and configured for maximum function rather than minimum risk. I part company, though, with the study when it consequently recommends that "policy makers should...increase the exposure of software and system vendors and system operators to liability for system breaches..." This is a dangerous path. Existing product liability laws define breach of warranty, negligence and strict liability as the three different standards to which a seller of goods may be held. I dont believe we want to move in the direction of narrowing buyer choice on any of these grounds.
Its easy to say, for example, that a Web server software product carries an implicit warranty of fitness for use in the threat environment of the Internet, but I dont believe we want all Web server products to be built to the highest achievable level of security. There are applications, such as physically isolated intranets or internal document servers, in which the administrative costs and performance overheads of state-of-the-art security are out of proportion to the business risk. People should be able to buy products that suit their needs. Likewise, strict liability has long been defined as the appropriate standard for products whose use involves unacceptable downside risks, especially when the buyers own testing or modification cant reasonably mitigate those risks. But as the report itself observes, "operational security can only be maintained by systematic and independently conducted red team attacks and correction of the defects that they reveal" (emphasis in the original). IT products are configured in so many different ways and used in so many different environments that I would argue that its inappropriate to apply strict liability. That leaves us with negligence as the only practical basis for making a claim against an IT vendor: The definition of negligence is a moving target, defined by the pace of technical development and the speed with which a competent practitioner can stay abreast of new threats. I dont want to see this threshold being defined by legislators. Do you? Its time for the punch line of my opening story. The physicist and the engineer turn to the economist for any additional suggestions. After a pause, the economist says, "Suppose we assume a can opener." Lets not wave our hands and say, "IT buyers do stupid things, so lets assume that we can create legal or supra-market incentives that force them to make better decisions." If legislators or insurance companies knew how to make IT secure without destroying competitive advantage, theyd be funding startup companies. Our only real-world choice is to learn together. E-mail eWEEK Technology Editor Peter Coffee
 
 
 
 
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...

 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel