
Vol 8 December 2003 Issue 2
Return to Table of Contents	Citation Information

THE PHENOMENON OF INSECURE SOFTWARE IN A SECURITY-FOCUSED WORLD

Reid Skibell[*]

[p107]

Introduction: The Economics of Insecure Software ..... 107
The Bundle of Security Measures ................................. 110
- Application Security ................................................ 110
- Penetrate and Patch ................................................. 113
- Security Countermeasures ........................................ 117
Traditional Explanations for Insecure Software ........ 122
- The Failure of the Absence of Liability Theory .......... 122
- The Failure of the Lack of Demand Theory ............... 126
The Argument for an Information Failure Theory ...... 128
The Way Forward .......................................................... 133

I. Introduction: The Economics of Insecure Software

Last year the Federal Trade Commission (FTC) demanded that Microsoft improve the security on its Passport information service, or face stiff fines up to eleven thousand dollars per violation.[1] Based on the fact [p108] that information for 200 million users is stored in Passport, Microsoft faces fines that could total up to $2.2 trillion for a security flaw discovered in May 2003 that would allow an attacker to access a Passport account at will. [2] Interestingly enough, the flaw was not discovered by automated scanning, or detailed analysis by a group of researchers. Rather, it took a single security specialist less than four minutes to discover and exploit the weakness.[3] Most would view this story as yet another indictment of Microsoft, but what is most disturbing about this episode is just how unremarkable it is, and how easily it could have happened to almost any of the major software manufacturers. Almost all software is riddled with holes, and programs are released to purchasers with hundreds, if not thousands, of security-related weaknesses. [4] This Article is an exploration of this phenomenon, an attempt to understand just how undesirable insecure software is, and to articulate those forces which are responsible for this situation.

In undertaking this task, this Article will adopt a distinctly law and economics perspective. This approach is warranted given the nature of the relationship at the core of the issue, namely the interaction between software seller and software buyer; but perhaps more important is the framework that economics provides for locating what is the ideal amount of software security. Economically speaking, security expenditure has long been recognized as a dead weight loss, as it represents a transfer of productive resources towards the empty activity of protection. [5] Security is not a product that has usefulness in of itself, as its social benefit derives only from its ability to reduce the welfare losses from theft and vandalism.[6] [p109] Consequently, the social utility of an extra unit of security must be based on it preventing a more significant loss from crime; with an equilibrium point where an extra unit is equivalent to the welfare loss that would be prevented by that unit. Also, it seems fairly evident that security in the context of computer crime is not a homogenous good, and these varying types of security products have different levels of effectiveness. One would also expect that there would be diminishing marginal utility from the employment of any one type of security product, and that a bundle would be the optimal way to achieve security equilibrium. Based on this framework it would seem that the question of whether the amount spent on security is efficient would be primary, but given the near impossibility of calculating the total amount lost to security incidents, the focus should be on the issue of whether the current allocation of resources includes an efficient mix of security-related products.[7]

In the context of computer crime this mix will include some combination of three approaches: engineer applications to have fewer security holes, produce patches as security holes are discovered, and implement security countermeasures to guard against attacks on a more general level. As vividly demonstrated by the example of the cracking of Microsoft’s Passport information system, the current mix favors the last two at the expense of application security. Part II of this Article describes the three types of security, and establishes why application security should be a higher priority. Part III lays out the conventional arguments for why software security is not more of a priority, and explains why they do not sufficiently account for this situation. Part IV puts forth an alternative explanation, that there is a systemic market failure because information about the safety level of software is largely unattainable. Since consumers have no ability to determine if the product they are buying is vulnerable, they cannot appropriately factor security into their buying decisions and companies have no incentive to produce secure software. Finally, Part V suggests some areas of analysis that could prove important for later attempts to define how this market failure might be rectified. [p110]

II. The Bundle of Security Measures

A. Application Security

Software programs are incredibly dense complex configurations of data, and this essential essence of software makes some level of bugs inevitable. [8] However, complexity does not account for the large number of security-related weaknesses found in most software applications. The real cause is a lack of emphasis on software security.[9] This lack of a concern for application security is underscored by the spending patterns of software producers. For the year 2001, they spent more than $8.4 billion on application design and construction tools, while total spending on application security tools, training, and consulting was less than $50 million.[10]

One argument raised by manufacturers about the presence of so many holes is that they are not determinative of whether a system is at risk. They contend that the skills of computer intruders are advanced and that if sufficiently dedicated, they will be able to break the security on a system, or find a way to launch a virus. For example, in Congressional testimony in the wake of the devastating SQL Slammer virus, Microsoft’s Susan Kelley Koeppen took the position that:

These attacks did not occur because the extremely innovative engineers creating the underlying codes disregarded security. They occurred because equally innovative criminal hackers worked day after day to find, create and exploit vulnerabilities in the software or in human nature that gave them new ways to trespass on your computers, steal your data and shut down your networks.[11]

This explanation brings computer security conceptually close to physical security, in the sense that while there may be ways to protect one’s home from an intruder, a burglar will almost always find a way to break in. In the [p111] world of physical security the response is to use significant criminal sanctions and a criminal justice infrastructure, both to deter and apprehend those who would transgress the law. However, the industry position is not supported by the data on computer attacks, which demonstrates that the majority of intrusions can be traced to those with very limited computer skills.[12] These intruders, labeled script-kiddies in computer crime jargon, download standardized tools from the Internet, which they use to exploit common software security holes. [13] This is not to say that there are not skilled malevolent hackers who are breaking into systems, or designing these standardized tools, but the fact remains that holes being exploited by generic tools are a primary source of losses from computer crime.

There is also reason to believe that application security could be useful against other categories of computer criminals. Security specialists contend that the key ingredient in protecting one’s system is not the quality of the intrusion-detection system, fire wall, or encryption protocol; rather, it is whether or not the underlying application software is secure.[14] This is true both in the sense that application holes are the primary avenue through which attackers gain access to a system, and that software is the key determinant of just how much damage will be done.[15] One estimate concluded that design flaws in commercial and custom software composed thirty to fifty percent of the total risks to IT infrastructure.[16] Furthermore, highly secure applications were found in practice to reduce overall [p112] business security risk by eighty percent. [17] Plainly, quality software is an important aspect of a network security scheme, no matter the source of the attack.

The other argument alleged against improving application security is the substantial nature of the costs involved. To make a significant difference in the number of security holes in software, manufacturers would have to make sizeable investments in security that would be passed onto the consumer in the form of higher prices. [18] The size of the costs involved is evident in the current disparity between spending on functionality tools versus security tools, but higher costs are not of themselves an efficiency loss. Instead, the potential for waste is based on the fact that only five to ten percent of software holes released into the market are discovered, and improving the security of applications might involve correcting holes that might never become an issue. [19] To what extent this is wasteful is largely dependent on how easy it is to project which holes are most likely to be discovered. The evidence on this issue is mixed. Some scanning for security holes can be automated, but to a large degree it is labor intensive and holes are extremely difficult to locate. [20] In spite of this, there are general areas of weakness and categories of attacks, and if security is designed into software from the beginning, this can make a serious difference with a relatively small investment of resources.[21] For example, the reason that Passport was hacked so quickly was that the tester was familiar with security principles and common Microsoft weaknesses, and thus knew where to look. The implication is that some of the most problematic security concerns are eminently foreseeable and may not have even been that difficult to fix. There has been very little research on this issue, but a study by Andrew Jacquith found that seventy percent of security weaknesses resulted from design flaws that could have been anticipated by a greater emphasis on security. [22] Specifically, he concludes: “What is most surprising about the defects was . . . the degree to which they were entirely preventable. Armed with the right skills and tools, we believe that the companies in our survey could have readily detected and [p113] fixed the defects we found during the design phase.”[23] Jaquith argues that what made the most difference between the low-performing and high performing software was the quality of the security practices integrated into the development. [24] The efficiency of a more holistic approach is really not very surprising, particularly in comparison to how security is handled in many development situations. Often, a design team will be solely preoccupied with getting an application to work, and the holes that interfere with functionality are their primary concern. Security holes are often addressed at the end of the process, and the effort expended on them is proportional to the immediacy of the deadline.[25]

There is also reason to believe that the increase in cost could be offset, to a degree, by less of a need to invest in security-specific applications. Viega and McGraw argue that there is a direct correlation between poor application security and spending on fire walls, intrusion-detection systems, and other types of defensive precautions. [26] The nature of software security is such that it is only as strong as its weakest link, so one vulnerable piece of software can necessitate substantial investments on the part of the consumer to counter the risk. [27] The value of this reduction of spending on security countermeasures would be compounded by the fact that the marginal utility of an additional unit is close to zero, so the cost of a producer upgrading their software could be diffused over a wide number of consumers. Essentially, there is a choice between a manufacturer upgrading the security of its one product, with each consumer reaping the benefits in terms of security, or the consumers each independently spending on upgrading their security.

B. Penetrate and Patch

While each software manufacturer might have a slightly different approach, the dominant paradigm is what has been loosely termed [p114] “penetrate and patch.”[28] Under this model, software is released into the market, and once a weakness is discovered a patch is designed and issued to contain the risk.[29] This means that purchasers will be susceptible to attacks during an interim period, termed the “window of vulnerability,” between when attackers start exploiting the vulnerability, and when manufacturers have become sufficiently aware of it to develop a patch. [30] Penetrate and patch is predicated on the idea that a security weakness is only problematic in context, and the danger presented by initial discovery is acceptably low. This danger grows as information about the hole spreads, but is still relatively localized until some enterprising hacker decides to automate it, making it available to the much larger network of script-kiddies who are not sufficiently adept to use anything but an automated tool. [31] Penetrate and patch will thus be most efficient when patches are designed and issued prior to this automation, and the industry purposefully attempts to slow this diffusion process, going so far as to push for criminal prosecution for those who would intentionally post such information. [32] They base this position on the argument that the most effective defense against exploitation of a software weakness is anonymity.[33]

The available evidence suggests that there are serious technical problems when relying on patches to fix software problems. Often, the weaknesses that patches are supposed to address are embedded within the [p115] very structure of the code, and they are not always capable of correcting the weakness. This problem is so pronounced that one leading researcher claims that the “effectiveness of patches is somewhere between band-aids and a stiff drink.” [34] For example, both the Windows 9x platform (Windows 95/98/ME) and UNIX were not designed with security in mind, and these systems have needed substantial security retrofitting that has not been entirely successful. This is particularly true of Windows 9x, which is still so vulnerable that a knowledgeable hacker should be able to crash or hijack one with relatively little difficulty. [35] The other problem with patching is that by continually applying makeshift code, the cohesion of the original program starts to denigrate, and a patch can often create as many problems as it fixes. [36] Consequently, while patches may be a necessary component to software security, they are still a stopgap measure which should not be overly relied upon.

Beyond the technical problems associated with patches, there is the issue of whether it is really possible to shrink the window of vulnerability by suppressing information about security holes. There is some validity to the industry argument that it is the publication of information on holes that is responsible for them being so widely exploited. Studies have shown that there is an upswing in intrusions using a given security weakness once it has been publicly disclosed. [37] However, it is probably unrealistic to expect that information on security weaknesses is not going to find its way out into the open, or be passed along to those who would exploit such information. [38] Also, it may be impossible to separate publication of security holes from the general framework of penetrate and patch. Some commentators have suggested that it is the negative publicity associated with public disclosure, or the fear of such publicity, that motivates vendors to release patches. Without this incentive, software vendors would be extremely slow to spend the resources designing patches, if they did so at all.[39]

[p116] Even if anonymity could successfully function to slow down awareness of security weaknesses, there are reasons to doubt that the penetrate and patch approach can function effectively. While the industry has grown better at releasing patches in a timely manner, there are still noticeable examples of long lag times. [40] In other instances, manufacturers have decided that developing a patch is prohibitively expensive, so the user is left with no easy way to repair the hole.[41] Furthermore, even after a patch is released many corporations are slow in updating their software. William Arbaugh found that, “many systems remain vulnerable to security flaws months or even years after corrections become available.”[42] This problem may be reduced by the advent of automatic updating features, such as the one included in Windows XP.[43] However, there is still a lot of resistance to automatic updating, especially by corporations, because it necessitates a high degree of system access be ceded to an external company. [44] Furthermore, recent research indicates that it is not a simple implementation failure by network administrators to timely update their software. Companies are faced with resource constraints that make constant software updating difficult, and they have concerns that patches will create new functionality problems which will destabilize their networks and production systems. [45] [p117]

C. Security Countermeasures

The penetrate and patch approach is complemented by the development of more general “reactive” tools like fire walls, cryptography, detection programs, and other add-ons that are intended to protect a system from a wide variety of security weaknesses. [46] There is no denying that these security-specific applications work, and should be an aspect of prudent organizational security. Fire walls, in particular, are useful in limiting access to the network, and in confining attackers to parts of the network that do not contain vital information. [47] Encryption can also be a very powerful force in protecting systems by protecting packets in transit from interception. [48] Similar to patching, an argument can be made that these measures are so effective that they should be emphasized at the expense of application security. Essentially, if fire walls and intrusion monitors can successfully control the risk associated with vulnerable software then it might not be efficient for producers to invest the resources needed to reduce the amount of security holes.

There is also a second advantage to add-on security measures that arguably makes them superior to both improved security through design and patching. With the other forms of software security, the developer is expending resources to fix holes in a piece of software that will be used by a variety of different companies, some of which face very few security threats, or do not have data that is deserving of substantial protection. Certainly, Citibank needs a higher level of protection than a minor e-commerce web site, but both may employ the same basic database software. With security-specific applications, Citibank can choose the level of security that is appropriate to its risk level and the value of its information. This is the flipside of the argument that it is more efficient to fix the software once instead of companies individually investing in costly security measures. It is not clear which of these two effects predominates, but there is a separate reason to prefer that the software company act instead of individuals choosing the security level they believe is appropriate.

Unlike the world of physical security, insecure companies are a threat to more than themselves. If an intruder can easily enter a company’s network, he or she can launch an attack on his or her real target using that [p118] company’s computers, helping to cloak their identity from possible identification. This type of obfuscation is a key problem for law enforcement in their pursuit of computer criminals, and also complicates the building of cases for prosecution. [49] Furthermore, access to an insecure company’s systems might help to compromise other, possibly more important, companies with which they regularly share data. For example, an intruder could use his presence within the first company to help slip past the fire wall of the second company, or directly enter through a wide-open connection between the two networks, like a just-in-time ordering system. Lastly, insecure networks are useful to malevolent intruders, because they can be used for launching Denial-of-Service (DoS) attacks. In these attacks, computers brought under the attackers control are used to flood a server with requests for service, which can effectively bring network traffic to a stand-still. [50] If enough computers are turned to this purpose, in what are known as Distributed DoS attacks, even web sites with enormous resources can be compromised.[51] Consequently, even if defensive countermeasures were extremely effective in countering attacks, there still might be an efficiency problem in that individual users might not choose an amount commensurate with the optimal social level.

These types of security technologies have their uses; however, in terms of risk analysis overreliance can be dangerous. These countermeasures are largely perimeter defenses; and as a result, once an intruder is able to circumvent them there are few limitations on the amount of damage that can be done. [52] This would not be a problem if the technology were perfect, but this is far from the case, and the combination of human error and system failure means that failures are inevitable. [53] Another problem is that these technologies cannot replace application security because vulnerabilities at the application level can undercut their effectiveness. [p119] Because these countermeasures function according to a particular logic that can be easily grasped by an external attacker, their weaknesses can be targeted. This problem can be seen in the case of cryptography. Even perfect cryptography will not protect against many different types of attacks because the endpoints (where the information gets encrypted or decrypted) can be attacked if those applications are insecure. Attackers know this, and consequently the most vulnerable aspect of a given system is generally application security.[54]

The other reason that application security can undermine defensive measures is that to a large degree they are dependent on applications for the logic under which they operate. This problem is particularly apparent in the case of fire walls, which are often regarded as the most potent of these types of defensive precautions. The term “fire wall” comes from the iron walls that separated the passenger cars on coal-powered trains from the engine compartment. The accumulation of highly flammable coal dust would ignite fires, and the wall kept the fires from spreading. The image conjured up by the term is one of complete protection, a hard shield that is a perimeter around the network. [55] However, a fire wall is permeable, and acts as more of a gatekeeper. Thus, a cell wall would be more of an accurate analogy. [56] An attacker can sneak something through the fire wall, and modern networks are susceptible because of the varying types of information with which the fire wall must interact. [57] This is most problematic in a business context, where information flows are constant between the company and outside systems. For example, a just-in-time ordering system has to maintain a constant and open connection between the network and that of partner companies. Not only does this create an inherent vulnerability because of the amount of information flowing, but it also risks an insider attack from the partner company. The point is that the effectiveness of fire walls is never going to be perfect, and to a large [p120] degree their effectiveness is determined by how secure the underlying applications are. On this point Matthew Levine notes:

By design, however, the network must route legitimate traffic to the critical resources housing business logic in the form of applications. Network security protects the integrity and reliability of the traffic to critical resources, but application logic must determine what input or transactions are legitimate. Manipulation and corruption of application logic is an attacker’s approach to compromising business data.[58]

Superior algorithms may improve their ability to filter traffic, but ultimately they are a simple gatekeeper dependent on interactions with other programs for information on what to block. Consequently, fire walls, and other types of perimeter defenses, are not suitable replacements for secure software.

The final problem with defensive technologies concerns their visibility and how they influence the perceptions of an attacker. This is not true of every one of these measures, but in general one can easily locate, and even check the brand of fire walls, intrusion-detectors, and virus detectors, prior to commencing an attack. [59] In contrast, most applications are not visible through the fire wall, and one aspect of designing security into the application is constructing it to decrease its visibility.[60] Fingerprinting is the technique by which an intruder uses a port scanner in order to ascertain the operating system and applications running on a system. It can be difficult to do, is time-consuming, and opens up the intruder to the possibility of detection. [61] Consequently, when the applications are secure an intruder may not know whether they can even break into a system until they have assumed these types of costs, and the importance of raising the transaction costs in this manner can be seen by drawing upon academic work on the effectiveness of physical security.

This problem can best be understood by looking to a framework used by Steven Shavell in analyzing the market for physical security products. Shavell notes that there is a difference between observable security [p121] precautions and unobservable precautions in terms of their impact on perpetrator behavior. [62] Observable precautions have a displacement effect, in the sense that iron bars on one’s windows may encourage a burglar to attack a more vulnerable house down the street. They may also have what Shavell calls a theft reduction effect; in that they may decrease the amount that a dedicated thief can successfully steal.[63] Similarly, a computer criminal that determines a company is using a technologically superior fire wall or intrusion-monitor may simply move onto an easier target. Shavell uses the example of wall safes to demonstrate that unobservable precautions operate differently. A wall safe will have the same type of theft reduction effect as observable precautions, but it will not possess a diversionary aspect because the thief will not know if the house has a safe or not. In this way unobservable precautions can produce a more general deterrent effect; as the number of safes goes up, so does the thief’s perception that any individual house may contain one and the general cost of engaging in criminal behavior is raised for the thief. This prediction has been borne out in an impressive study by Ian Ayres and Steven Levitt on the Lojack vehicle retrieval system.[64] Ayres and Levitt found that the marginal social benefit of an additional unit of Lojack has been fifteen times greater than the marginal social cost in high crime areas. [65] This reduction in crime was largely due to the deterrent effect delineated by Shavell, as they found that the perception of the mean Lojack installation rate strongly influenced thief behavior. [66] The same might be true of software security: if the average amount of users of secure software were increased and if the type of applications were successfully shielded from external view, then crime might go down.[67]

There is another interesting aspect to this deterrence argument, in that this transaction cost analysis could also be extended to the discovery of [p122] holes. Microsoft’s Passport information system only took four minutes to break, and the expectation of this type of quick result encourages attempts to try and locate software holes. Consequently, a slight increase in the level of software security might have a significant deterrent effect in that computer criminals may not see it as worth their time to probe the code in search of holes that might not be there. This is also an important reason why the cost of increasing software security might not be as high as commonly thought.

III. Traditional Explanations for Insecure Software

That society is not utilizing the proper level of security in software applications strongly suggests that the market for software products is not properly functioning. A normal competitive market should move towards an equilibrium point where the mix of the three components of computer security should be at their optimal point; instead, the two other types are being emphasized at the expense of application security. There are two main explanations that serve as an excuse for poor quality software. The first explanation focuses on the supply-side, and the possibility that vendors are not being properly incentivized due to the absence of liability for security holes. The second argues that the problem comes from the demand-side, specifically, that business consumers are systematically undervaluing the worth of secure software. Neither of these theories is particularly compelling, as they struggle to explain on a causal level why the market has not compensated. This market is composed of sophisticated buyers and sellers, and only a structural impediment can adequately explain why they have not adjusted and overcome minor hurdles to efficient allocation of security resources.

A. The Failure of the Absence of Liability Theory

There are a number of impediments to attempting to sue manufacturers for negligently producing software with security weaknesses. Most software purchases are considered a sale of “goods,” and are covered under corresponding provisions of the Uniform Commercial Code.[68] Some courts [p123] have distinguished that the full development of software for a specific company should be understood as a service, rather than a good. [69] However, this difference is relatively unimportant, as very few software applications are built from the ground up for one purchaser. The importance of falling under the UCC is that they are subject to its warranty provisions, which has the effect of preempting negligence claims that might have been brought under a tort theory of liability. [70] Furthermore, in a contract for a sale of goods the default remedy does not include consequential damages, meaning that the majority of the loss will fall upon the purchaser.[71]

The other possible avenue for arguing for liability would be through the civil liability section of the Computer Fraud and Abuse Act. [72] Early cases made it seem possible that a defective design that harmed the integrity of one’s system might be reachable under the statute. For example, in Shaw v. Toshiba American Information Systems, Inc., the court held that defective floppy disk controllers qualified as knowing transmission under the statute, and thus the manufacturer could be liable for damages in excess of $5,000. [73] However, two changes made to the CFAA by the USA Patriot Act cut off use of the statute for these purposes. Congress altered 18 U.S.C. section 1030(a)(5)(B)(i) so that only the government could aggregate losses from a related course of conduct to meet the monetary liability threshold. [74] This makes it much harder to use the civil liability [p124] subsection because a plaintiff would have to prove that a single attack caused sufficient monetary damage to trigger liability, rather than being able to add the damage from related attacks against the system. Furthermore, Congress added language to the civil liability subsection that specifically exempts damage from the negligent design of software or hardware. [75] This change almost certainly forecloses the possibility of using the CFAA against software manufacturers.

Some have argued that this no liability regime is a fundamental reason why software is insecure.[76] Essentially, without this liability vendors lack a key incentive to produce a quality product, as is effectively explained by Bruce Schneier:

There is no market incentive to produce secure software because software manufacturers risk nothing when their products are insecure. . . If automobile manufacturers were immune from product liability, I would be able to buy a motorcycle with a nitrous oxide injector spliced into my fuel line. I would be able to push the acceleration faster than the brakes could handle. I would be able to have any performance feature that the manufacturers could build, regardless of the consequences. But I can’t, because the manufacturers would face lawsuits for marketing an unsafe product.[77]

Schneier’s analogy to car manufacturers is instructive because it demonstrates that this argument is predicated on a certain interpretation of the nature of software. He is comparing software to a mass-market product, where the consumer is not in position to negotiate specific terms and does not have the technical knowledge to assess the safety feature of the product. While an argument can be made that this is the case for shrink-wrap software, it does not fit business application software that is the primary focus of this Article. Manufacturers being free from liability is a default rule that could be altered through the incorporation of different contractual terms, and even small and medium-sized businesses negotiate specific terms for enterprise applications. [78] Software companies do not rely on these default rules; instead they include specific contractual clauses to free themselves from liability, as is noted by Daniel Perlman: [p125]

Contracts covering software agreements typically include standard form exculpatory terms such as integration clauses, warranty disclaimers, and provisions limiting remedies to the repair or replacement of defects. The use of these contract provisions shifts the risk of software failure from the seller to the user.[79]

These terms do not always have to be to the detriment of the buyer, as there are some limited examples of larger companies successfully negotiating the inclusion of clauses conferring liability on the manufacturer.[80] Basically, the fact that the default rules do not favor consumers in disputes has very little to do with the contractual terms that could be included in contracts.

With this having been said, there is the possibility that a structural reason might be preventing different contractual terms from being negotiated, with implications for the importance of the default rule on influencing behavior. An organization’s network will have applications from a number of different vendors, and it is not clear how security incidents resulting from application interaction would be handled. There is also a moral hazard issue, as a large proportion of software incidents result from the failure of internal IT staffs to properly configure software or to install patches. [81] Estimating the damage from computer intrusions is also notoriously difficult, and would have to be negotiated prior to signing the contract.[82] Yet while these problems exist for computer intrusion insurance policies, they are becoming widely available. [83] While these policies have only been offered for a limited period of time, and are still being fine-tuned, insurers believe that a mix of deductibles, security audits, and effective pricing can overcome the difficulties with assigning liability in this context.[84] This is solid evidence that vendors and purchasers could [p126] account for these issues in a properly negotiated contract. In fact, the existence of cyber-insurance policies makes the fact that vendors do not take on the burden of liability something of an anomaly. Because vendors, rather than insurers, understand the risks associated with their products, one would think this would put them in the best position to assume the risk of intrusions, and profit, from risk-averse businesses. The same should be true of moral hazard, in that the vendors should be able to better anticipate the risks of configuration errors or failure to update software, and guard against them. While alternative explanations exist for this phenomenon, the fact that this is not occurring strongly points towards the existence of a substantial market failure.

B. The Failure of the Lack of Demand Theory

Presumably, if there were a sufficient demand for secure products, then market forces would compel vendors to create better software. Drawing upon this logic, most attempts to explain why a computer security problem exists have focused on the businesses’ demand for security. Two related versions of this approach exist, the first of which claims that executives suffer from a technological myopia which prevents them from understanding the value of safeguarding information.[85] It is not a market failure in the sense that the information is not available; rather it is a generation of executives that cannot appreciate the importance of something as abstract as computer security.[86] Consequently, one would predict that it would dissipate over time as management familiarized themselves to a larger degree with technology, and as younger and more technologically focused individuals infiltrated the higher ranks of management. The available evidence indicates that just such a scenario is being played out. The risk of computer intrusions has largely infiltrated the corporate consciousness, and Mario Correa contends that the vast majority of CEOs are generally aware of security as an issue, and appreciate its importance for their businesses.[87] His contention is independently supported by research surveys which demonstrate “a greater acceptance by senior management that information needs to be protected.” [88] Studies also [p127] show that companies are increasingly placing high level administrators in specific computer security positions, and that the majority of them report directly to senior management.[89] The growing role of a constituency within corporations focused on computer security suggests that these types of concerns are being seriously considered by corporate decision-makers. And while it may have been true at one time that the problem of insecure systems could be linked to corporate apathy, this no longer appears to be the case.

The second version contends that because the value of security products is probabilistic in comparison to the costs which are concrete and up-front, businesses do not choose the proper level of security.[90] The implication is that businesses will continue to under-invest in the efficient amount of security on a societal level, because they choose less expensive options when they are faced with the concrete costs of secure systems. An illustrative example was the federal government’s Trusted Computer System Evaluation Criteria, also referred to as the Orange Book Program, which were a series of guidelines meant to influence commercial systems development and thus improve security generally. Industry successfully delivered secure products; however, governmental agencies refused to buy them, instead preferring less expensive and more functional alternatives.[91] Some basis for this problem also exists in cognitive theory, as individuals are generally risk-averse when it comes to potential gains, but are risk seekers when it comes to potential losses. It is well documented that there is a substantial qualitative difference between the curve of subjective utilities for gains and for losses. [92] However, if such a cognitive bias were responsible for companies not valuing secure software, then one would expect a similar pattern with regard to other types of IT security spending. This does not seem to be occurring, as security applications and consulting are the fastest growing subgroup within the technology sector.[93] Dataquest, [p128] a Gartner analyst firm, forecasts that security-related services in North America will grow to $9 billion by 2006, up from $4.1 billion in 2001, a compound growth rate of 17%.[94] To put these numbers in perspective, Bruce Sterling found when researching his 1993 book that there was virtually no private industry, the government and phone companies were completely responsible for computer security.[95] Security-specific spending has continued even as the rest of the software industry suffers from the global slowdown. For the third and fourth quarters of 2002 every software sector was down, with the exception of the security sector which showed 12.8% and 11.1% growth respectively.[96] Furthermore, companies are so uncomfortable about bearing the risk of security incidents that they are increasingly finding insurance to be an attractive option. [97] Given the high level of corporate resources being devoted to computer security, a lack of will does not seem to be a compelling explanation for why companies are not demanding more secure software applications. Also, considering the evidence that application security is instrumental to preventing intrusions, the lack of a demand for secure applications is a rather glaring anomaly, and is worthy of further investigation.

IV. The Argument for an Information Failure Theory

The reason that buyer demand does not equate to more secure applications being supplied is that there are informational failures which handicap the functioning of this market. For buyers to be able to successfully make purchasing decisions that create pressures for improved security, they have to be able to evaluate the quality of the product. The higher the degree of buyer uncertainty is with regard to the security level of a product, the less it should factor into the purchasing decision. Companies may make claims with regard to security, but in practice these assertions are often quite exaggerated and do not provide a sufficient basis to make a concrete investment in more expensive software.[98] Furthermore, companies know how difficult it is to distinguish between products on the basis of security, and thus find it more useful to try and compete on the basis of functionality and price.

[p129] This reluctance of purchasers to base their decisions on security may be enhanced by the composition of the market, which is dominated by a few major producers.[99] Once a company makes the sizable investment to work with one of these providers, substantial sunk costs may inhibit them from changing. This behavior is a form of path dependency, where the switching costs are so prohibitively high that a company may be forced to continue working with the same provider even after it has become aware of the substantial security failings of their software. This is particularly true in the case of enterprise applications, since a corporation is unlikely to change providers once it has invested in a total network solution, like that offered by SAP. The market numbers provide an illustration of how pronounced this path dependency problem is, as sales rates for enterprise applications have been contracting since 2001, and Gartner is projecting a mere 3.1% compound growth rate in the sector for 2002-2006. [100] This drop in demand is forcing the major software vendors into the small and medium business market, which traditionally has had a higher degree of competitiveness.[101] This migration into the small and medium business market may be an indication that the switching cost problem may also continue to grow.

A conceptual reason why security testing is so difficult is namely that what one is trying to establish is the nonexistence of something. Security testing can only verifiably establish the existence of holes, and not finding a hole could be an indication of the quality of the investigation as much as the quality of the product. [102] However, what is not so apparent is just how severe the implications are of this conceptual problem with security testing. The effectiveness of an application resisting attacks is so opaque that Schneier contends:

The average person cannot tell good security from bad security. It works the same. It costs the same. . . The advertising is the same; the product [p130] literature is the same. It’s not different until you look under the hood: examine the source code, pick apart the hardware. And then only if you’re an expert. The average person still won’t be able to tell a quality product from snake oil.[103]

What Schneier means by “expert” is not a system administrator, or someone else that has a background in programming. Rather, he means someone that has a specific background in computer security, and is familiar not only with the theory of how attacks are undertaken, but has practical knowledge of how different components on the system’s network interact.[104] Only someone with this type of skill-set will be able to ascertain if the absence of visible holes actually means that the holes are not there.

There are some additional complications that make security testing difficult, even for someone with a deep knowledge of the field. Security testing is different from functional testing in that it is a creative process, whereby one probes the system to look for areas of potential weakness.[105] Consequently, familiarity with the product, and an understanding of how it was developed and its internal structure, is fundamental to properly testing it. A different impediment to effective purchaser testing is that the source code is often hidden from the potential buyer.[106] Security testing generally does not result in clear-cut results, and usually a weakness is only discovered when something about a system’s behavior suggests a need for manual inspection of the code. [107] Without access to the code it is nearly impossible to assess whether a vulnerability is present. [108] It is also impossible to assess the general quality of the programming, or to evaluate [p131] how an application deals with common security problem areas like access control and end to-end encryption.[109] In this sense, effective security testing really is best done by the manufacturer, as they have a level of access and depth of knowledge about the product which it is almost impossible to replicate.

The inability of companies to verify an application’s security effectiveness does not necessarily mean that information on product quality cannot be ascertained. To the extent that manufacturers and buyers are repeat players, it is conceivable that reputation can serve as an effective proxy, functionally serving the same purpose as testing. If a manufacturer continues to not live up to the level of their security claims, the market should respond by discounting their products accordingly. This works in the case of most consumer products, as can be seen in the market for automobiles. While the buyer may not be able to personally determine that the Volvo is safer than the Toyota, the buyer factors the additional safety of the Volvo into his buying calculation, based on its reputation. However, this reputational mechanism is far from automatic and requires timely, widely disseminated, and above all accurate information. Since costs are associated with collecting and deciphering this information, if to a large degree these criteria are not met then software buyers would have a rational basis for not valuing security when buying software.

Even if a product is extremely vulnerable to attacks, this information might not be effectively communicated. A number of companies search for software vulnerabilities and publicly report them. The primary motivation for these companies is to generate publicity for their security services, and they have an economic incentive to issue a large amount of these alerts.[110] To garner as much exposure as possible, each alert emphasizes the severity of the hole, and separating the important information from the trivial becomes overwhelming. [111] They are also under the same constraints with regard to the source code, and this limits the depth of analysis that they can perform. The overall effect is a valueless amalgamation of security data that a consumer cannot trust for buying decisions.

[p132] More objective parties also face substantial obstacles in trying to collect accurate information on the degree of security vulnerabilities found in a company’s software. As explained earlier, software manufacturers attempt to contain all information relating to security weaknesses, on the basis that its release serves as a blueprint for malevolent hackers of how to break into systems. This will be particularly problematic if they are successful in shutting down the largest source of reliable intrusion information, namely governmental data under the Freedom of Information Act. Manufacturers are lobbying for a broad FOIA exemption, and if they are successful, the ability of researchers and other third parties to study software security failures will be severely compromised.[112]

Given these difficulties, information about software vulnerabilities is generally confined to what individuals or companies have learned through personal experience. This information is not widely shared because companies have little incentive to publicly report it, and the accompanying information on how the intruder was able to penetrate their system. The 2002 Computer Security Institute/FBI survey found that only 34% of respondents were willing to report intrusions to law enforcement. [113] The respondents based this decision on fears about negative publicity, or that competitors would use it to their advantage, both of which would be present in a more widespread dissemination of attack data. [114] Thus, in a drive to maintain an edge over their competitors, companies are cutting themselves off from information that might be instrumental in helping them to avoid similar attacks. The willingness of companies to share information on computer intrusions may further deteriorate, as they begin to fear that such disclosures could subject them to lawsuits. This concern arises because under recent regulations, such as the finance industry’s Gramm-Leach-Bliley Act (GLBA), and health care’s Health Insurance Portability and Accountability Act (HIPAA), businesses could be liable for inadequately protecting confidential customer information. [115] [p133]

V. The Way Forward

The failure of businesses to be able to distinguish between secure and insecure products is at the heart of the current computer crime problem. When consumers have no ability to evaluate a qualitative difference in an aspect of a good, the only alternative is to make purchasing decisions on other criteria. This is a rather simple proposition, but as has been demonstrated, it can have a substantial impact on the efficient allocation of market resources. The nature of this issue calls for a separate and detailed examination in proposing a solution, but this Article’s analysis does demonstrate some areas of concern that should serve as a starting point for such a study. In some ways the most obvious answer to this problem would be to shift liability to software manufacturers for security vulnerabilities in their applications. However, this would not address the underlying problem and would most likely be bargained around, as has occurred with the current default rule against liability. If liability were more forcefully applied to manufacturers, the market would likely respond by increasing security, but it is not clear that this would be done in an efficient fashion. Depending on the liability rule, whether it be negligence or strict liability, a rule that could not be bargained around might cut too deeply and have a chilling effect on the production of software.[116] In this sense, liability might not be a sufficiently tailored approach to correcting this failure, and regulation might be superior as an alternative. However, regulation would have to address the informational problem directly, so as not to be as ineffective as the Orange Book program. This is not an easy task, as the reasons for this failure are buried deeply into the structure of the software relationship. Furthermore, the value from increased information would in all probability not flow linearly, as there should be a threshold of security knowledge before companies feel comfortable spending more for secure software. Exactly how high this threshold is, and how difficult it is to reach, should be at the center of any examination advocating regulation as a solution.

[*] J.D. Candidate, Columbia Law School, 2004; Msc Information Systems, London School of Economics, 2000. Special thanks to Victor Goldberg, John Dunagan, and Tugba Colpan for their editorial suggestions and assistance. I would also like to acknowledge the generous financial support for this work provided by the Milbank, Tweed, Hadley & McCloy Law & Economics Fellowship.

[1] This FTC warning was the impetus for Microsoft’s $100 million security initiative, called Trustworthy and Secure Computing, which was supposed to lead to changes in development throughout the company. See Ashlee Vance, $2 Trillion Fine for Microsoft Security Snafu?, The Register, May 8, 2003; see Robert Lemos, One Year On, is Microsoft Trustworthy?, CNET News.com (Jan. 16, 2003), available at http://news.com.com/2100-1001-981015.html (last visited Oct. 29, 2003) (discussing “trustworthy and secure computing” and the changes created by the program).

[2] See Vance, supra note 1.

[3] Id.

[4] See Bruce Schneier, Foreword to John Viega & Gary McGraw, Building Secure Software: How to Avoid Security Problems the Right Way, at xix (2002) (“the average large software application ships with hundreds, if not thousands, of security related vulnerabilities”).

[5] See Gordon Tullock, The Welfare Costs of Tariffs, Monopolies, and Theft, 5 W. Econ. J. 224, 231 (1967); Fred S. McChesney, Boxed in: Economists and Benefits from Crime, 13 Int’l Rev. L. & Econ. 225, 228 (1993).

[6] Just what the costs of theft are is more complicated than it may initially seem. A significant portion of the perceived loss from theft is simply a transfer of wealth, with no net loss in social welfare. With this being the case society may be investing scarce resources in preventing a transfer of wealth, which would represent a dead weight loss. See Richard L. Hasen & Richard H. McAdams, The Surprisingly Complex Case Against Theft, 17 Int’l Rev. L. & Econ. 367, 369 (1997); Tullock, supra note 5, at 23; McChesney, supra note 5, at 228. This is not as problematic for defining what the equilibrium point is for computer crime as it would be for other types of crime. This is due to the fact that a large proportion of computer crime inflicts a loss with no accompanying gain in utility for the attacker, as in the case of nuisance attacks. See Reid Skibell, Cyber-Crimes & Misdemeanors: A Reevaluation of the Computer Fraud and Abuse Act, 8 Berkeley Tech. L.J. 909 (2003). For this reason, and to focus the analysis of this Article, the welfare losses from theft will be treated as equivalent to the total losses from computer crime.

[7] To further concentrate the analysis, this Article will confine itself to the issue of corporate computer crime, and the security challenges faced by businesses attempting to combat computer crime. Also, while the issue of insecure software is international, this Article focuses on how the situation has developed in the United States.

[8] See Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering 183-84 (1995).

[9] The preference of software manufacturers for issuing patching over creating secure software will be more fully fleshed out in the section specifically devoted to patching.

[10] Abner Germanow et al., The Injustice of Insecure Software, @Stake Research Report, 3 (Feb. 2002), available at http://www.atstake.com/research/reports/acrobat/atstake_injustice.pdf (last visited Nov. 5, 2003); Telephone Interview with Bruce Schneier, CTO of Counterpane Internet Security (Apr. 8, 2003).

[11] Cyber-Security Enhancement Act: Hearing on H.R. 3482 Before the Subcomm. on Crime of the House Comm. On the Judiciary, 107th Cong. 8 (2002) (Testimony of Susan Kelly Koeppen, Corporate Attorney, Microsoft Corporation); Telephone Interview with Harris Miller, President Information Technology Association of America (Apr. 17, 2003) (arguing that skilled hackers are the cause of computer crime).

[12] See Reid Skibell, The Myth of the Computer Hacker, 5.3 Info. Conn. & Soc’y 336, 343 (2002) (explaining that the majority of computer crime is undertaken by unskilled attackers, or corporate insiders); see Richard Barber, Hackers Profiled — Who are They and What are Their Motivations?, Computer Fraud & Security, Feb. 2001, at 14-17 (delineating unskilled script-kiddies); Editorial, Hackers, Crackers and Phreakers Oh My!, Computer Fraud & Security, Apr. 1999, at 18 (showing script-kiddies make very common programming mistakes with regularity), available at http://www.shockwavewriters.com/Articles/SWW/hcpom.htm (last visited Nov. 5, 2003); Duncan Graham Rowe, Access Granted, New Scientist, Aug. 12, 2000, at 42 (“They've [script-kiddies] no idea what they’re doing. They download programs or scripts and hack by pointing and clicking.”).

[13] See Skibell, supra note 12, at 343. While this is generally true, it must also be admitted that attacks designed by more sophisticated users can also cause widespread damage. For example, the SQL Slammer worm was not due to script-kiddies, and it may be that all the script-kiddie attacks of 2002 added up were less costly than the effects of recovering from Slammer.

[14] See Matthew Levine, The Importance of Application Security, @Stake Research Report, 1 (Jan. 2003), available at http://www.atstake.com/research/reports/acrobat/atstake_application_security.pdf (last visited Nov. 5, 2003); Bruce Schneier, Secrets and Lies: Digital Security in a Networked World 189 (2000) (explaining that the quality of the software is the key factor of whether a system is at risk); John Viega & Gary McGraw, Risky Business, SD Mag., Mar. 1, 2003 (showing software is the root cause of all major security incidents).

[15] Schneier, supra note 10.

[16] Germanow et al., supra note 10, at 1.

[17] Id. at 2.

[18] Telephone Interview with Mario Correa, Director of Internet and Network Security, Business Software Alliance (Mar. 12, 2003); Miller supra note 11.

[19] Bruce Schneier, Will We Ever Learn?, Info. Security, (Apr. 2000) (“It's much cheaper to release buggy software and fix the 5 to 10 percent of bugs people find and complain about.”).

[20] Schneier, supra note 10.

[21] See John Viega & Gary McGraw, Building Secure Software: How to Avoid Security Problems the Right Way 23 (2002).

[22] Andrew Jaquith, The Security of Applications: Not All are Created Equal, @Stake Research Report, 1 (Feb. 2002).

[23] See id. at 4.

[24] See id. at 5 (“the difference between the top- and bottom–quartile performers is due to superior practices in designing, coding, and deploying secure applications”; see also Viega & McGraw, supra note 21, at 38 (“good software engineering practice is crucial to building secure software”).

[25] See Schneier, supra note 10.

[26] See Viega & McGraw, supra note 14 (“We wouldn’t have to spend so much time, money and effort on network security if software security weren’t so shaky.”); Schneier, supra note 14, at 280 (“strong protection mechanisms mean that you don’t need good detection and reaction mechanisms”).

[27] See Computer Science and Telecommunications Board (CTSB), Cybersecurity Today and Tomorrow: Pay Now or Pay Later 7 (2002) (“Weaknesses in any of these aspects can be very damaging, since competent attackers seek out weak points in the security of a network or system.”); Viega & McGraw, supra note 21, at 2.

[28] See Rebecca T. Mercuri, Computer Security: Quality Rather than Quantity, 45 Comm. ACM 11, 12 (2002); Jaquith, supra note 22, at 3 (“many companies treat security as a ‘penetrate and patch’ activity typically done after an application is deployed, rather than employing secure software engineering practices”); Viega & McGraw, supra note 21, at 15 (“Many well-known software vendors don’t yet understand that security is not an add-on feature”).

[29] One study described the basic nature of penetrate and patch with a descriptive analogy: The practice is “akin to an automotive manufacturer ensuring quality by banging out the dings with rubber mallets at the end of the assembly line — or worse, after receiving customer complaints — rather than designing a better manufacturing process from the beginning.” Jaquith, supra note 22 at 3.

[30] See William A. Arbaugh, William L. Fithen, & John McHugh, Windows of Vulnerability: A Case-Study Analysis, IEEE Computer 52, 54-56 (2000); Bruce Schneier, Closing the Window of Exposure: Reflections on the Future of Security, Security Focus, Sept. 18, 2000, available at http://www.securityfocus.com/guest/3384 (last visited Nov. 5, 2003).

[31] Arbaugh, Fithen, and McHugh describe a software hole as having a life cycle, which commences with its being discovered and ends with installation of a patch. During the early stages the vulnerability curve is increased, until the vulnerability is automated, and the vulnerability curve begins decreasing with the issuance of the patch. Arbaugh, Fithen, & McHugh, supra note 30, at 52. Schneier uses the same descriptive framework. Schneier, supra note 30.

[32] See Jennifer Granick, Comments to the U.S. Sentencing Commission 7-8 (Feb. 19, 2003), available at www.eff.org/Legislation/CFAA/20030317_comments.php (last visited Oct. 29, 2003).

[33] Miller, supra note 11; Scott Culp, It’s Time to End Information Anarchy, Microsoft Security Essays, (Oct. 2001).

[34] Germanow et al., supra note 10, at 5.

[35] See Viega & McGraw, supra note 21, at 37.

[36] See Mercuri, supra note 28, at 11 (“eventually the resulting patchwork quilt of [patches] becomes unmaintainable”).

[37] Arbaugh, Fithen, & McHugh, supra note 30, at 52.

[38] See Eben Moglen, Free Software Matters: Security Through Freedom (June 15, 2002), available at http://emoglen.law.columbia.edu/publications/lu-21.pdf (last visited Oct. 29, 2003) (arguing that information on holes will inevitably be shared); Bruce Schneier, Managed Security Monitoring: Closing the Window of Exposure (2000), available at http://www.counterpane.com/window.pdf (last visited Oct. 29, 2003).

[39] See Viega & McGraw, supra note 21, at 15-16 (“[software vendors] start to worry about security only after their product has been publicly (and often spectacularly) broken by someone.”).

[40] For example, Microsoft was informed of a major security weakness in Windows XP but took more than two months to release a patch that could have been available within two weeks. See Richard Forno, Who Needs Hackers When We Have MS, The Register, Dec. 12, 2001. In another case, a known weakness in Microsoft IIS was left unpatched for a year and a half, allowing the theft of credit card information. See Schneier, supra note 38.

[41] A recent example is provided by a flaw in Microsoft’s Endpoint Mapper, which affects its various Microsoft operating systems. A patch was devised for Windows 2000 and Windows XP, but Microsoft admitted that it would be too costly to create a patch for Windows NT. The company’s rationale was that the flaw would allow an attacker to crash the system but not gain access, and thus a patch was not critical. See John Leyden, NT 4.0 Too Flawed to Fix — Official, The Register, Mar. 27, 2003; see also Bruce Schneier, Three Minutes with Security Expert Bruce Schneier, PCWorld, Sept. 28, 2001 (“If it’s an easy fix, they’ll fix it quickly and announce how good they are. If it’s a hard fix, they'll tell you it’s not a problem.”).

[42] Arbaugh, Fithen, & McHugh, supra note 30, at 52, 58.

[43] Telephone Interview with John Dunagan, Microsoft Research (Apr. 11, 2003).

[44] Correa, supra note 18 (explaining the fear of giving vendors the kind of access necessary to make automatic updating work).

[45] Most security flaws do not affect functionality or reliability, and companies may have concerns that patches will interfere with their systems in a more short term and concrete manner. See Register Editorial, To Patch or Not to Patch, The Register, Apr. 5, 2003 (discussing the inconvenience of constant patching); see Tiffany Kary, Security’s Big Picture: Trust in Web Services?, ZDNet, Nov. 27, 2002 (quoting Bruce Schneier, “If I was a sys admin I would have to do one every day of the week. And you know [patches] always break stuff”).

[46] Mercuri, supra note 28, at 11.

[47] See Martin Caminada et al., Internet Security Incidents: a Survey within Dutch Organisations, 17 Computers & Security 417 (1998); Schneier, supra note 14, at 89 (“Today’s fire walls act as boundaries between private networks and the vast public network. They keep intruders out, and only allow authorized users in”); Dunagan, supra note 43 (explaining that technology is making it increasingly difficult to illegally access sensitive data).

[48] See Schneier, supra note 10.

[49] See Bill Boni, Crossing the Line or Making the Case?, 2002 Computer Fraud & Security 18, 19, (Dec. 2002) (explaining that difficulties in tracing hackers is a severe problem for law enforcement).

[50] See Skibell, supra note 12 (explaining the combination of how little computing skill is needed to launch DoS attacks, and the potential damage that they can do, makes them one of the most popular forms of computer crime).

[51] The danger from distributed DoS attacks was made apparent in February 2000, when several high-profile sites were effectively shutdown. See Skibell, supra note 12, at 351; Pinkney, infra note 68, at 60.

[52] See Avi Freedman, Securing the Edge, Queue, Mar. 2003, at 6, 8 (“Since any determined attacker (an employee’s teenager, for example) can probably find one user to ‘come in as’ through sanctioned and supported VPN channels, it’s also important to ensure authenticated users don’t get the keys to the kingdom when inside your network.”).

[53] See Schneier, supra note 14, at 280-81 (noting the technological and human problems with countermeasures).

[54] See Viega & McGraw, supra note 21, at 94.

[55] Bruce Schneier makes an interesting observation on the etymology of the term. He believes the reason that the term “fire wall” so poorly matches up with the technological reality is that the meaning has changed since it was first used in computer networks. The original networks were buggy and would inevitably crash, and fire walls were installed to prevent bad networking software in one part of the network from taking down the rest of the network. Schneier, supra note 14, at 88.

[56] Bruce Schneier uses the analogy of the Great Wall of China to denote the permeability of fire walls. See id. at 190.

[57] See Levine, supra note 14, at 1; see Schneier, supra note 14, at 166 (“A firewall is a router with a consistent rule set that it tests network traffic against. . . This was relatively easy in early networks, but today’s firewalls have to deal with multimedia traffic, downloadable programs, Java applets, and all sorts of weird things.”).

[58] Levine, supra note 14, at 1.

[59] Schneier notes that a particular type of intrusion monitor does not have this problem, called a burglar alarm or honey-pot. They function by attaching an alarm to a hidden spot within the system, or to a dummy part of the system that has been made to purposefully look attractive to an intruder. However, in general these technologies are visible. See Schneier, supra note 14, at 198.

[60] Viega & McGraw, supra note 21, at 64.

[61] See Fyodor, Remote OS Detection via TCP/IP Stack Fingerprinting (June 11, 2002), available at http://www.insecure.org/nmap/nmap-fingerprinting-article.html (last visited Oct. 29, 2003); Ronald Black, How Does Network Security Scanning Work Anyway? (Sept. 27, 2000), available at http://www.giac.org/practical/GSEC/Ronald_Black_GSEC.pdf (last visited Oct. 29, 2003).

[62] Steven Shavell, Individual Precautions to Prevent Theft: Private Versus Socially Optimal Behavior, 11 Int’l Rev. L. & Econ. 123, 126 (1991).

[63] Id.

[64] Ian Ayres & Steven D. Levitt, Measuring Positive Externalities from Unobservable Victim Precaution: An Empirical Analysis of Lojack, Q.J. Econ., Feb. 1998, at 43, 44 (“in this paper we provide the first thorough empirical examination of the externalities associated with self-protective efforts”).

[65] See id. at 43.

[66] See id. at 75-76 (“auto theft rates are affected by thieves’ perceptions about the mean Lojack installation rate”).

[67] Ayres and Levitt found that Lojack is so effective that penetration rates as low as 10-20% might actually eradicate car theft altogether. See id. at 75. The combination of the impossibility of determining whether Lojack is installed, and the high risk of Lojack leading to a criminal prosecution, makes it somewhat unique. However, the example is still instructive of the potentially powerful effects of raising the perception of the mean rate of unobservable security precautions.

[68] See Kevin R. Pinkney, Putting Blame Where Blame is Due: Software Manufacturer Liability for Security-Related Software Failure, 13 Alb. L.J. Sci. & Tech. 43, 67 (2002); Daniel T. Perlman, Note, Who Pays the Price of Computer Software Failure?, 24 Rutgers Computer & Tech. L.J. 383, 385 (1998). The most forceful and influential statement of this doctrine comes in Advent Systems v. Unisys Corp.:

The topic has stimulated academic commentary with the majority espousing the view that software fits within the definition of a “good” in the U.C.C.. . . The importance of software to the commercial world and the advantages to be gained by the uniformity inherent in the U.C.C. are strong policy arguments favoring inclusion. The contrary arguments are not persuasive, and we hold that software is a “good” within the definition in the Code.

Advent Sys. v. Unisys Corp., 925 F.2d 670, 675-76 (3d Cir. 1991).

[69] See, e.g., Pearl Invs., L.L.C. v. Standard I/O, Inc., 257 F. Supp. 2d 326, 353 (2003) (“By contrast, in the instant case, Standard and Pearl agreed that Standard would create ATS software from scratch (concept to realization) for which it would be paid on a time and materials basis.”).

[70] See Perlman, supra note 68, at 385 (“the UCC’s warranties. . . pre-empt the possibility of a negligence claim”); Alan Charles Raul et al., Liability for Computer Glitches and Online Security Lapses, BNA Electronic Commerce Law Report, Vol. 6, No. 31, at 849 (Aug. 8, 2001), available at http://pubs.bna.com/nwsstnd/ip/BNA/EIP.NSF/23d9e82d7d25950885256743006e3012/df54d7572ecfd1db85256aa100762737?OpenDocument&Highlight=2,raul (last visited Oct. 29, 2003).

[71] See Perlman, supra note 68, at 386.

[72] 18 U.S.C. § 1030(a)(5)(B)(i).

[73] See Shaw v. Toshiba Sys., 91 F. Supp. 2d 926 (E.D. Tex. 1999); see also In re AOL, Inc. Version 5.0 Software Litig., 168 F. Supp. 2d 1359 (S.D. Fla. 2001) (AOL’s transmission allegedly “changes” the host system’s communications configuration and settings is actionable); Christian v. Sony Corp., 152 F. Supp. 2d 1184, 1187 (Dist. Ct. Minn. 2001) (providing diskettes with faulty code “violates the CFAA”).

[74] See Computer Crime and Intellectual Property Section (CCIPS), Field Guidance on New Authorities That Relate to Computer Crime and Electronic Evidence Enacted in the USA Patriot Act of 2001, available at http://www.usdoj.gov/criminal/cybercrime/PatriotAct.htm (last visited Sept. 22, 2003).

[75] See CCIPS, Redline Version of USA Patriot Act, available at http://www.usdoj.gov/criminal/cybercrime/Patriot_redline.htm (last visited Sept. 22, 2003).

[76] See Pinkney, supra note 68, at 72 (the no liability regime encourages companies to not exercise due care); Schneier, supra note 14, at 365 (“Software manufacturers don’t have to produce a quality product because they face no consequences if they don’t.”); Ira Sager & Jay Greene, The Best Way to Make Software Secure: Liability, BusinessWeek, Mar. 18, 2002, (arguing that software is poor because there is no liability).

[77] Schneier, supra note 4, at xx-xxi.

[78] Correa, supra note 18 (explaining that there are opportunities to negotiate these terms).

[79] Perlman, supra note 68, at 386. Correa, supra note 18; Suzanne R. Eschrich, Note, The Year 2000 — Delight or Disaster: Vendor Liability and the Year 2000 Bug in Computer Software, 4 B.U. J. Sci. & Tech. L. 8 (1998) (“In negotiated contracts, the contract normally contains provisions limiting or excluding warranties, and limiting liability”).

[80] See Dennis Fisher, Contracts Getting Tough on Security, EWeek, Apr. 15, 2002 (though the contract referred therein did not include a consequential damages clause).

[81] Miller, supra note 11 (arguing that configuration errors are the principle cause of intrusions); Mark Rasch, Suing Over Slammer, Security Focus, Feb. 10, 2003.

[82] See Skibell, supra note 12 (explaining the many problems with common damage determinations); Correa, supra note 18 (the BSA never quotes damage figures because they know how unreliable they are).

[83] Lawrence A. Gordon et al., A Framework for Using Insurance for Cyber-Risk Management, 46 Comm. ACM 82 (2003) (noting that American International Group, Chubb, Fidelity & Deposit, Marsh, Lloyds of London, J.S. Wurlzer, and others provide cyber-insurance).

[84] See id. at 82-84; Oscar Kolodzinski, Cyber-Insurance Issues: Managing Risk by Tying Network Security to Business Goals, CPA J., Nov. 1, 2002, LEXIS; Richard Thieme, What Insurance Can — and Can’t — Do for Security Risks, Secure Bus. Q., Winter 2001, at 2-3.

[85] See, e.g., Winn Schwartau, Cyber-Shock: Surviving Hackers, Phreakers, Identity Thieves, Internet Terrorists and Weapons of Mass Destruction 225 (2000) (arguing that the principal problem is a lack of awareness of security issues).

[86] Id.

[87] Correa, supra note 18.

[88] Stephen Hinde, Security Surveys Spring Crop, 21 Computers & Security, 314 (2002); see also Richard Power, 2002 CSI/FBI Computer Crime and Security Survey, 8 Computer Security Issues & Trends, 1 (2002).

[89] Lorraine Cosgrove Ware, CIO Research Reports, Security Spending: How Much is Enough?, CIO Mag., Sept. 12, 2002 (surveys demonstrate the increasingly important role played by security personnel), available at www.csoonline.com/csoresearch/report6.html (last visited Nov. 18, 2003).

[90] See, e.g., CTSB, supra note 27, at 7 (“[Security] has no value when there is no attack or natural/accidental disruption in the system environment. Consequently, people tend to use as little of it as they think they can get away with.”); Miller, supra note 11.

[91] See CTSB, supra note 27, at 9 (arguing that the Orange Book is a striking example of how security is disfavored in buying decisions).

[92] See Massimo Piatelli-Palmarini, Inevitable Illusions: How Mistakes of Reason Rule Our Minds 60-61 (1994).

[93] Kelly Kavanagh, North America Security Services Market Forecast: 2001-2006, Gartner Research Report (Oct. 9, 2002), available at http://www.gartner.com/DisplayDocument?doc_cd=110432 (last visited Oct. 28, 2003).

[94] Id.

[95] Bruce Sterling, The Hacker Crackdown: Law and Disorder on the Electronic Frontier 43 (1993).

[96] Hugh Bishop & James Tsai, IT Spending Shows Mixed Results, Aberdeen Group Research Report (Mar. 12, 2003) (on file with the author).

[97] Gordon et al., supra note 83, at 82.

[98] Schneier, supra note 10, (arguing that the security claims of companies are usually nothing more than unverifiable advertising).

[99] See Joanne Correia, Software Market Stalled in Global Economy's Slow Engine, Gartner Research Report (Feb. 28, 2003), available at http://www4.gartner.com/pages/story.php.id.3350.s.8.jsp (last visited Oct. 28, 2003) (explaining that the software titans continue to gain market share over pure-play vendors, due to their ability to sell complementary services); see Judge Richard Posner, Antitrust in the New Economy, ALI-ABA Lecture (Jan. 29, 2001), available at http://www.ali-aba.org/aliaba/posner_101100.htm (last visited Oct. 28, 2003) (explaining why the software industry is particularly susceptible to anti-competitive behavior.

[100] See Ronna Abramson, Big Software Aims Small in 2003, TheStreet.com, Dec. 30, 2002, available at http://www.thestreet.com/tech/ronnaabramson/10057600.html (last visited Oct. 28, 2003).

[101] See id. (relating that the market for small and medium business software has generally been more competitive); James Browning, What SMBs and Their Vendors Should Be Thinking About in 2003, Gartner Research Report (Nov. 11, 2002), available at http://www3.gartner.com/resources/111300/111302/111302.pdf (last visited Oct. 28, 2003).

[102] See Schneier, supra note 14, at 352 (detailing the conceptual problem of security testing).

[103] Id. at 392.

[104] Not only does Schneier claim it takes a skilled professional, but he believes very substantial amounts of man-hours are required for a comprehensive security evaluation. See id. at 350.

[105] See Viega & McGraw, supra note 21, at 39.

[106] Just because the inaccessibility of the code makes security testing difficult, it does not follow that opening the code would lead directly to more secure software, as has been alleged by proponents of open-source software. See Moglen, supra note 38. There are a wide range of incentive problems and technical limitations that suggest open-source software is no more secure than proprietary software. See Viega & McGraw, supra note 21, at 77-82.

[107] See Viega & McGraw, supra note 21, at 39.

[108] John Dunagan described the difference between access and lack of access in a descriptive analogy:

Just to make sure you understand the difference in how much less work there is to do when you have access to the code, it’s like having to verify that an ATM withdraw operation where you request $x removes $x from your bank account. If you don’t have access to the source code, you have to test every allowable input x and observe the effect. If you do have access to the source code, you just check that the code takes an input and uses that same input to debit your account.

Dunagan, supra note 25.

[109] With access control one can generally check that it works part of the time, but not all of the time without checking the source code. See id. Encryption is even more problematic in that all types of cryptographic protocols are not equally secure in practice, even if they all use 128 bit keys. For example, Microsoft developed its own proprietary protocol, Point-to-Point Tunneling Protocol, which was badly flawed. Since no one had access to the code, problems with the protocol were not discovered until it had been widely used in Windows NT, 95, 98, and in their virtual private network products. See Schneier, supra note 14, at 117.

[110] See Marcus Ranum, Script Kiddiez Suck: Toward an Economy for Vulnerability Disclosure, 17 Computer Security J. 28 (2001) (He quotes an estimate from Russ Cooper, the moderator of NT Bugtraq, that 70% of these alerts are nothing more than marketing ploys.).

[111] See id. at 27 (“If there’s too much information it becomes valueless.”).

[112] Creating the Department of Homeland Security: Consideration of the Administration’s Proposal Before the House Comm. on Energy and Commerce Subcomm. on Oversight and Investigations, 107th Cong. (July 9, 2002), (Testimony of David L. Sobel, General Counsel EPIC) (explaining the importance of FOIA data on software failures), available at http://www.epic.org/security/infowar/07_02_testimony.html (last visited Oct. 28, 2003).

[113] Power, supra note 88, at 10 (This percentage had been growing steadily over the survey’s six years, but seems to have stabilized at this level).

[114] Id. at 21.

[115] See Lawrence M. Welsh, Forecast: Cyberlitigation, Info. Security, Mar. 2003, at 24.

[116] Miller, supra note 11 (contending that any application of liability would have a substantial chilling effect on the productivity of the industry).