Denial ecurity threats are often divided into three c&go&s: breach of confiden- tiality, failure of authenticity and unauthorized denial ofserxice. Thr first twu have been very extensively studied; confidenti+ in particular has bear pur- sued to extraordinary lengths. Indeed, some publications on confidentialit) recall medieval disputes about how many angels could stand on the head of a pin. The second ha been the subject of. inquiry for- many years, and is remarkable for the extent to which it is easy to d&se wrong protocols. Thr third has been much less studied, and indeed, the ttwdency has been to dis miss it as a topic for serious inquiry (I did so in [S]). The &jectiw of the pre sent article is to consider a particular instance o1.a denial of service problem and to look at engineering considerations relevant to an appropriate defensr. A major aspect is the complexity and danger that result from unthinking USC of what seem to be simple cost-saving measures. There are tax-s where the security threat that must be countered is almost exclusively one of denial of service. If there is a burglar in my v&t, I do not care who tells me (no need for authenticity), I don’t much care who else finds out (not much need for confidentiality), but I care very much that attempts to inform me are not balked (no denial of suvice). One could quil, ble with the detail of this example, in particular by discussing how one might defend against f&e alarms, but it seems incontrovcrtiblc that denial of ser- lice is the main threat. Much of the presmt discussion was in fact stimulated by a study of the infrastructure needed by alarm companies, undertaken for the U.K. insurance industry. The examples given do not relate to any specifl ic product or service. The context fbr discussion is more structured than (say) the Internet, which in probably helpful. In the context of an alarm system, we have three mechanical components to deal with, namely a C&W (a controller in the vault), a wtwmk, and a wrwr (on an alarm company’s premises). There are also two nonmecl~anical pa&s to the system-the customer and the contractor The contractor uses the client, the network, and the server to give a servicr to the customer. We put it this way to emphasize that the denial of .service against which we seek to protect is the denial of service to the customer, not to the client. The attack may indeed consist of disabling or destroying the client, just a it may consist of interfering with the nehvork or with the server. Attacks on the Server, the Network, or the Client It is clearly possible to cause interruption of service by physiul dcauction of the server, and the means of making this less likely are mosdy outside the field of interest of computer people. However, it is important to observe that the contractor may be presumed to know this has happened and, perhaps less plausibly, to have plans to deal with the contingency It is clearly the respon- sibility of. the contractor to assure itself of the integrity of the server, in par- ticular by checking against unauthorized changes in its software. Such changes could, in principle, cause the server to decline, illegitimately, to give service to a particular client.The obvious attack on the network is to cause it not to transmit messages necessary to give the required service either to all clients or to a class of clients. A less obvious attack is to cause it to send messages it should not send-a, for example, the simulation of a disabled client. A third possibility is to flood the network with enough messages to impede iu proper func- tioning. If there is a place in the net- work that connects multiple clienw, destruction of that facility should cause a great number of alarm signals, which may clog the network later on, overload the server if the messages reach it satisfactorily, or overload the means of physical response (for exam ple, the police). The main attacks on a client arc destruction, with obvious conse- quences, and substitution. Substitu- tion involves replacement of the cli- ent with an apparently similar one that will not give the service the cus- tomer believes has heen purchased- for example, always reporting “all’s well,” even when there is a burglar. Defenses ‘l‘here are ready defenses agamat some attacks, and it is necessary to consider their scope, their limits, and most particularly, their objectives. Customers want to get the service they pay for, and if they do not, and are rohhed, they will file claims with their insurance companies. Insurance companies do not wish to receive claims, and therefore want to be satis- fied that the defenses are adequate. Manufacturers and vendors of client5 do not want to he sued by insurers or contractors, and neither do the nrt- work providers. They all want to pass liability on in the direction ofcontrac- tars, which themselves wish to have demonstrably received the alarm and called the police. The best defenses with respect to each class ofattack are (as usual) end- to-end defenses, though they do not deal with everything. The obvious manifestation of an end-to-end de- fense is a continuous regular hand- shake between the client and the server, which I will discuss in some detail. The purpose of such a hand- shake is to assure the contractor that the system is working properly, as- aunung that the conu-actor can ,rly on the good behavior of the server The contractor’s computer will douhtlcss carry out many corporate functions; good practice would segre- gate the functions having to do with handshaking in a manner more se- cure than the rest. Although the in- formation conveyed by such a hand- shake can, and probably should, be