Port 80

A little over a year ago, there was a brief furor among the internet security community when a company called Symbiot announced plans to develop a “counterstrike” security system which would combine traditional network defense measures — firewalls, intrusion detection systems, patching, and the like — with offensive countermeasures against network attacks. The use of offensive systems is, at the risk of understating matters, highly controversial among the security community. Some harbor ethical objections to the concept of offensive action, some feel that offensive systems represent a potential legal minefield (an accurate assessment), and some have argued that legitimizing offensive systems would lower the threshold between legal and illegal use of the Internet. At the time, my opinion was that offensive systems, love them or loathe them, were here to stay. Nation-states cannot leverage their monopoly on physical force into a monopoly on control of the Internet, necessitating the involvement of private entities in fighting malicious Internet activity.

Over the past few weeks, however, I have become increasingly convinced that this analysis — and all analyses I have seen — have neglected a critical portion of the problem. The traditional assumption about the use of a counterstrike system is that it will be slow, deliberate, and carefully controlled: purely defensive measures are applied first, followed by blacklisting, finally followed by offensive countermeasures. Furthermore, these offensive countermeasures are always described as being under the control of human operators. To date, discussion of these systems has been implicitly based on the assumption that counterstrike is a last resort and that a human will always be “in the loop.” Unfortunately, I’m not certain that any system which obeys either of these rules will be able to deal effectively with real-world Internet threats. The current state of the Internet may demand software that operates in seconds, not hours, and which may not be able to wait on human approval for its actions.

Symbiot’s original whitepaper (PDF) arguing in favor of counterstrike security systems put great emphasis on applying the rules of conventional warfare to confrontation on the Internet. Part of this focus was no doubt in order to reduce the controversy over counterstrike systems, as the paper takes pains to note that the tactics it outlines “have been refined by thousands of years of warfare, diplomacy, and legal recourse.” However, the authors also use the vocabulary and concepts of warfare as a convenient intellectual base for their arguments, and demonstrate more than a passing familiarity with The Art of War.

One military concept of great importance which is not discussed in this whitepaper is that of “operational tempo.” The idea of operational tempo was developed along with the concept of maneuver warfare as a more useful measure of the speed of an operation than its simple physical velocity. The operational tempo of a force is the rate at which it can collect new information, process it, make a decision, and finally take action based on that decision. The ultimate goal for any military force is to have a higher operational tempo than that of the opposition, and thus be able to react to new developments significantly faster than the enemy.

Symbiot’s whitepaper appears to be of two minds as to the operational tempo of a counterstrike system. When the paper begins by arguing that there is a need for counterstrike systems and a more aggressive approach to information security, the importance of rapid response is held to be paramount. The authors initially state that “the response in most cases [of network attack] must be determined and executed within seconds,” and then focus on the necessity of self-defense in situations that are “‘instant, overwhelming and leaving no choice of means and no moment for deliberation.’”

However, when describing the characteristics of a counterstrike system, this emphasis on speed appears to have been removed, perhaps to placate the legal worries of potential customers. Instead, the watchword of these sections is “graduated response.” Response, as defined by the authors, begins first with the determination that an attack is underway, followed by characterization of the attack and a determination of whether or not the attack is hostile. Upon determination of the level of hostility of the attack, countermeasures are applied. These countermeasures begin with “multiple positive identification[s] of hostile intent,” and work their way through blacklisting, action through the legal authorities, and finally coordinated counterstrikes. The process described here is one that will take hours, if not days, to complete. At almost every step, at least one human judgement is required as to the appropriate course of action. At a minimum, these judgments will take a few seconds. At the maximum - such as in the case of pursuing action through legal channels - the “human” part of this process could run for days, weeks, or months. The end result is an operational tempo which is limited by the maximum speed of human organizations.

This level of speed is wholly adequate for dealing with threats whose operational tempo is also limited by the speed of human decisions. There are a wide range of these threats to computer networks: For example, there are blackmail efforts which threaten to shut down computer networks unless a sizable ransom is paid. There are industrial espionage attempts, in which an attacker seeks to quietly extract some sensitive piece of information from a company network. There is even the threat of petty vandalism and web page defacement, in which case some cracker simply seeks to have his name and “1337 sk1lz” more widely known. In each of these cases, human decisions are required throughout the intrusion attempt, ensuring that the attacker and defender are operating at roughly the same operational tempo, and that an organized defense is possible.

Unfortunately, there is an entirely different class of network attacks which operate not at the speed of human decisions, but at the speed of processor commands and network packets. I am speaking, of course, of self-propagating Internet worms. Since worms seek out and infect new targets without any human intervention (beyond the initial decision to release a worm in the first place), their speed of spread is typically only limited by the design of their networking code and the speed of the network connections limiting their victims. The Witty worm, released in March 2004, infected almost all vulnerable computers (about 12,000) in 45 minutes. In August 2001, Code Red II infected some 359,000 computers in 14 hours, peaking at 2,000 infections per minute. However, the all-time speed record is held by the Sapphire worm, also known as SQL Slammer. Sapphire infected most of the vulnerable hosts worldwide in roughly ten minutes, with a final victim count of between 75,000 and 100,000 computers.

The operational tempo of an worm - infecting a host, finding new vulnerable targets, and infecting them - is measured in milliseconds, not in the minutes or hours of a cycle which is controlled by human intervention. Simply put, there is no way that any human-controlled security system can cope with the speed of a full-fledged worm outbreak.

To date, there have been two approaches to solving this speed disparity. The first of these approaches has been to attack a worm asymmetrically - rather than fighting every infected host individually, security professionals have attempted to block all traffic which shares a certain characteristic typical of the worm. Some worms, such as the Witty worm, will always attempt to communicate over a certain port. Others, such as Sapphire/SQL Slammer, will always send themselves as network packets of a certain length. Still others, such as the Blaster worm, will always have some distinctive string within their packets. By filtering traffic which matches some particular worm characteristic, system administrators have been able to effectively block an entire worm outbreak at a single stroke.

Unfortunately, this approach is trivially defeated if worm authors begin to work to randomize the traffic generated by their worms. The key will not be to make worm traffic impossible to recognize, but rather impossible to recognize during the few hours that a worm requires to spread. What good does it do a system administrator if a pattern to worm traffic is discovered after the vast majority of vulnerable machines are infected? The likely result of this tactic will be an arms race on both sides: Worm authors will try to make their worms more and more random, while system administrators will attempt to better characterize worm traffic at ever faster speeds. It is uncertain who will eventually win this race, but clearly pattern-matching and traffic-filtering is no panacea.

The other approach to addressing the speed of worms takes advantage of their pattern of exponential growth. While a worm infection in full swing grows at a truly frightening rate, the early stages of a worm infection grow at a relatively slow pace, as a handful of seed machines work to infect other computers around them. It is during this short time that countermeasures against the spread of a worm - either passive pattern recognition and traffic blocking or active counterstrikes - can be most effective.

Exponential growth is an inherent property of any internet worm or disease outbreak, meaning that worm authors will always have to contend with this particular hurdle. However, the Witty worm showed a way to cross this hurdle before the race even begins. Instead of starting with one infected host, the author of the Witty worm began his attack with between 110 and 160. Thus, the earliest and slowest phase of exponential growth was avoided, and the worm grew rapidly at its initial release. Larger pools of pre-infected hosts will only serve to increase the initial growth speed of a worm. Using this method, it is possible to speed up the initial growth of a worm to the point that human intervention will simply be too slow to effectively contain it. Certainly, there is no chance that the slow and careful “graduated response” that Symbiot envisions will be able to handle the job.

Furthermore, although most worms so far have been costly nuisances, the possibility of targeted worms exists. What if a worm were instructed to send random traffic to a company webserver, establishing a “botnet” and creating a DDoS attack in a matter of hours or minutes? What if a worm were instructed to delete or corrupt all data on a hard drive, but only if the host was within the IP address range of a specific corporation? What if that same worm was instructed to send all Word documents or e-mails on a hard drive to another computer before corrupting them? To date, we have not seen targeted worm attacks because standard, human-directed intrusion has been a sufficient tool for criminals. If counterstrike systems make human-directed attacks more difficult, however, automated attacks will be the logical next step.

The solution to the problem of internet worms is self-evident at this point: If human-directed countermeasures do not have the speed with which to counter a computer-directed attack, then it will eventually be necessary to turn to computer-directed countermeasures. The goal of any such countermeasures will be to match the operational tempo of an automated attack. At most, human operators will be presented with a probable threat, a list of possible responses to choose from, and a single button marked “Launch.” Depending on how fast automated attacks become, it is possible that human operators might only be given the authority to cancel a counterstrike which is already in progress.

There are other points in Symbiot’s white paper which take on a new level of meaning when tied to the concept of automated response. In particular, the authors discuss at great length the importance of new data-sharing protocols for security measures which will enable faster coordination in response to network attacks. Such protocols would be especially effective when coupled to automated security responses. Consider the possibility of linking ISPs up with the security professionals at trusted corporations, so that a home PC implicated in a denial of service attack could be taken off of the Internet automatically. This sort of linkage would greatly increase the speed and effectiveness of a counterstrike system, although it raises a few other questions: How exactly will customers react to having their DSL disconnected based on an automated report from a third party? (The safe money is on “not well.”)

When I wrote before on the impact of human-directed counterstrike systems, I argued that the development of counterstrike systems would necessitate a serious shift in how home users looked at computers. Rather than a device for entertainment, such as a television, computers had to be considered in the same light as a car: A useful tool which requires careful maintenance and possesses immense destructive potential. It has always been unlikely that consumers would react to this shift in a positive manner, as there are few human desires more universal than the desire to be absolved of all responsibility. Above all else, viewing computers as an active tool rather than as a passive appliance meant that users would have to become more responsible for their actions online. In a culture where “I’m computer illiterate” or “the computer did it” are perfectly normal excuses, this is unlikely to be a popular change.

The possibility of automated counterstrike systems, if anything, would sharply accelerate this shift in viewpoint. Rather than being possibly counterstruck if they acted irresponsibly online, home users would almost certainly be counterstruck if their computers were infected by a worm or co-opted into a botnet. The high speed and exponential growth of worms means that there will be a strong incentive for security professionals to react quickly to possible attacks, and to react decisively. With this attitude, the problem of “false positive” counterstrikes is also likely to become an issue.

This accelerated shift is also likely to birth a strong backlash against it. Computer security experts can argue until they are blue in the face, but the likelihood that they will overcome public objection to counterstrike systems is minimal. Almost universally, the public loves the benefits of automated systems which enforce responsibility, but hates the systems which enforce it. We love air travel, but hate metal detectors and X-ray machines. We love low interest rates, but despise credit reporting systems. We love to drive cars, but despise mandatory insurance and statistically-adjusted insurance rates. (As a young male driver with no accidents, I especially despise statistically-adjusted car insurance rates.) Likewise, we love the convenience of high-speed, always-on Internet access. We will no doubt hate automatic counterstrike systems.

With most of the aforementioned systems, public debate has led to at least a grudging allowance that the systems are worthwhile. We grumble and moan about airport security lines, but very few suggest completely abolishing security checkpoints. Likewise, credit scores are accepted, albeit with some resentment, as the price of doing business. However, there is constant debate about just how much information corporations should be allowed to track.

To date, I have seen little public discussion of the impact of counterstrike security systems. I have seen no public discussion of the impact of fully-automatic counterstrike systems. This lack of debate is made all the worse by the public’s “appliance” attitude towards computers. Even the most spirited discussion within the computer security community would be unlikely to penetrate the public consciousness. (Ask a computer security professional what he thinks of Bruce Schneier’s stand on airline passenger screening, and you’ll get a whole range of responses. Ask someone who’s not a computer security professional, and you’ll get a blank look and a “Who?”)

The end result will be that sooner or later, one or two security companies will decide to develop an automatic counterstrike system in response to the worm threat. The system will be debated for months on BUGTRAQ and Slashdot, and will finally be deployed somewhere irrespective of the furor. And then, one morning, a major worm will break out and a few hundred thousand AOL customers will wake up and wonder why their computers won’t turn on anymore. The backlash will be swift, widespread, ill-informed, and quite possibly legislative. So far, government action on computer issues has created the DCMA, nearly mandated the Fritz chip, and came within a few months of mandating the broadcast flag. Does anyone want to bet that a ruling on the limits of computer security systems will be carefully-thought-out and well-reasoned?

There is a final mismatch in operational tempo that must yet be addressed. At present, computer security professionals are debating the effectiveness of current tactics: patches, improved security awareness, and the like. Few are considering the possible issues associated with future tactics: Human-directed counterstrike systems, automatic counterstrike systems, and whatever systems are yet to be conceived. At the same time, programmers are working to build and deploy these “future” systems. The operational tempo of our development of doctrine no longer matches the tempo at which new technology is being devised. Counterstrike systems are here. It’s past time to start working out the consequences of their arrival.