Let's look at what a typical text says on the subject: ``The noise analysis of communications systems is customarily based on an idealized form of noise called `white noise', the power spectral density of which is independent of the operating frequency. The adjective `white' is used in the sense that white light contains equal amounts of all frequencies within the visible band of electromagnetic radiation. ...'' [Haykin83] The reason cited for the random noise models is the ease of analysis, [Minoli80] but ease and adequacy of analysis are not always compatible.
One of the most common techniques for detecting corruption in memory and transmission is the use of a `parity' bit associated with each byte. The parity bit is set to 1 or 0 to make the total number of `1's even (or odd, depending on whether the even or odd parity convention is being used). This technique detects ALL single bit errors, which is quite effective against particular sorts of random noise that cause transient faults. It is not effective against an intentional attacker who can change sets of bits collectively while maintaining parity, thus keeping the parity the same while corrupting the information and avoiding detection.
On disk storage, LAN packets, and in some satellite transmission, CRC (Cyclical Redundancy Check) codes are used to detect classes of faults that result in errors to linear sequences of bits of at most some predefined length. [ISO8208] Again, these codes are ineffective against an intentional attacker, because it is easy to determine the constant coefficients of the coding equations by watching packets, and from this it is easy to forge packets at will undetected. [Cohen94-2]
This work is essentially oriented toward designing a perfect system wherein all inputs, states, outputs, and state transitions are specified in full detail, and mathematical proofs are provided to show that the design is properly implemented. [Gove91] [Lubbes91] Although this type of solution may be applicable to certain limited control problems in embedded systems, these sorts of solutions are computationally infeasible for any large system, cover ONLY sufficiency and not necessity [Cohen86-2] , only cover limited function systems against disruption, [Cohen94-2] and are beyond current and anticipated capabilities over the next 20 years for the sorts of systems desired in the DII.
An alternative path to a similar solution is the use of automated program generating programs. In this technology, a small number of programs are designed to automatically write the rest of the programs. Designers spend a great deal of time and effort in perfecting the design automation system which, in turn, designs other systems. [Siewiorek90] This technology is far from perfected, and even if it were perfected, it leaves the problem of writing perfect specifications, which is at least as hard as writing a perfect programs.
In the hardware realm, design automation has been highly successful, but this does not imply that it will be successful in the software realm. There are substantial differences between hardware and software. For example, the complexity of current software is many orders of magnitude higher than the most complex automated hardware design; the physical properties of hardware are abstracted out of most software design; software is designed based on a finite but unbounded randomly accessible space, while hardware is designed based on a relatively small finite and bounded space with only local access as provided by explicitly created wires. Furthermore, hardware design automation takes substantial amounts of computer time, still leaves design flaws such as data dependencies that have resulted in disruption, and is based on specifications that are vulnerable to errors.
Another alternative is the use of extremely intensive testing to detect the presence of errors and correct them. The problem with this approach is that testing for 100 percent coverage is as complex as perfect design. Imperfect testing leaves systems that fail when `rare' events occur. In one study, the combination of two events characterized as low probability caused 50 percent of systematically designed, well tested, small control programs to fail. [Hecht93] If this is the current state of the art for low probability events in small programs, extremes in testing are not likely to be successful against intentional attacks on large globally networked infrastructures.
Gateways, terminal servers, and routers are commonly used to control traffic in networked environments, and they are quite effective against random or accidental misrouting of information, but in a hostile environment, they commonly fall prey to disruptive attacks. General purpose computers used as gateways are easily overwhelmed and corrupted. Terminal servers are commonly accessible by users logged into any computer in the network and can be altered to remove usage restrictions, connect users to wrong systems, or even lock out legitimate terminal server administrators. [Cohen93-3] Routers designed to control network traffic and prevent overloading in large networks are also easily bypassed by using the administrative mechanisms which permit remote control of the router or forgery of machine IDs with authorized access. [Cohen92]
The public telecommunications networks are a critical part of the current DII, and are likely to be a major component of the DII into the future, but they lack the information assurance features required for military operations. Service assurance features are designed into these systems at every level, [Falconer90] and yet they still fail to meet even the challenge of accidental errors and omissions. As an example, in 1991, there was a major failure in telephone switches in several large US cities that lasted for several days, and was finally traced to a 3 bit error (a `D' instead of a `6') in one byte of a software upgrade. [FCC91] This is the simple sort of mistake that even minimal software change control detects. This change was apparently never tested at all, was put into widespread use, and caused widespread harm. In 1990, AT&T's long distance network shut down due to a protocol error that impacted millions of customers nationwide for over 4 hours. [Alexander93]
In many cases, telecommunications disruptions must be resolved in very short timeframes. For example, some telephone switching systems must be repaired within 1.5 seconds or the circuit failure errors passing through the network will cause a propagating positive feedback which may deadlock more of the network, [Pekarske90] eventually cascading into a major problem. An attacker only needs to disrupt two sites for 1.5 seconds to cause such a cascading effect.
One quarterly report of large scale disruption incidents for the fall of 1993 includes an FAA (Federal Aviation Administration) computer systems failure delaying regional traffic for 90 minutes (cause unknown), an FAA weather computer system failure for 12 hours due to a time activated logic bomb, a programming error in an X-ray system that resulted in wrong dosages to about 1,045 cancer patients, and a software `bug' that crashed the Hamburg ISDN (Integrated Services Digital Network) telecommunications services for over 11 hours, and this is only one of several similar publications that report different incidents. [edpacs]
Similar lapses in policies and procedures seem to be common for major software manufacturers. As an example, in 1992, Novell released a virus to tens of thousands of customers when it was noticed after quality control was completed that a key file was missing from the master distribution disks then being transported to the disk duplication facility. Instead of returning to the quality control process, the person transporting the disks for duplication loaded the file from the most convenient computer, which by chance contained a virus that was transferred to the floppy disk. The disk was sent to duplication, packaged, and shipped to customers. [Lefkon92] The disks were apparently never tested at random after duplication for problems, the disks en-route to the duplication facility were not sealed or permanently write protected, the personnel were not properly trained, and the initial quality control process never detected that the correct file was not on the disk!
Five books on computer viruses, including two that are tutorials on writing viruses, discuss military use of this type of software. [Hoffman90] [Ludwig91] [McAfee89] [Burger88] [Ferbrache92] A recent popular novel has the central theme of crippling attacks on US computers by means of viruses, computer terminal eavesdropping, high energy radio frequency `guns', and electromagnetic pulses. The author's virus examples are not as subtle or malicious as a real attack by experts. [Schwartau91] An interactive movie on CD-ROM, released in October, 1993, illustrates information and infrastructure warfare against the US. It includes details about crippling and corrupting time standards, which affect precision weapon targeting and long distance telephone switches. [Xiphias]
The Chaos Computer Club in Germany, maintains an annotated list of the Internet addresses of US DoD command, control, supply, and logistics computers on one of their computer accounts in Germany. [Simon91] Apparently selected from hundreds of publicly available military computer Internet addresses, listed systems are primarily Army, Navy and Air Force logistics, computer, communications, and research sites. This listing is not kept in publicly available bulletin boards throughout the world, but access to it was attained via an international connection. To demonstrate one possible utility of this list in attacking the DII, during this study two simple, safe, legal, and well controlled experiments were performed.
In the first experiment, e-mail was sent to the `root' user at each of 68 sites chosen from the Chaos Computer Club listing in order to establish that mail sent to most of them would be received and stored in their computers. The following table describes the results:
Number Response ------------------------------------------------------ 10 refused the mail 1 no root user, identified self as `TSO' 2 no such user ID, listed other user IDs 2 no user called `root' on their system 7 not found by the mail system 6 got the mail - personal response 40 got the mail - no responseThe second experiment consisted of sending mass quantities of mail into one site (done on an isolated computer designated for that purpose) to see how it affected operations. The first effect was a slight slowing of other processes on the system, presumably due to the disk writes and paging required to process and store all of the mail. The second effect was consumption of all available disk space in the `/usr' partition of the disk. The target system had about 18 Mbytes of free space on that partition, and it took only 4.5 minutes to exhaust it, at which point the system started having severe problems because it could not create or add to files in that area. The system console indicated that no disk space was available on that disk partition.
It typically takes about 30 minutes to find the specific problem in such an incident (in this case, the file consuming all of the disk space) once the systems administrator is able to login to the system. On some systems, the administrator cannot login properly without adequate disk space, but either way, the net effect is a half an hour or more of denial of services, corruption, and repudiation. The lack of disk space causes many programs to fail, and if you are unable to write a file to disk, it is hard to do much useful work. Files being written when there is no space left typically end up in an inconsistent state. Most programs dealing with file IO (input and output) do not detect and properly handle these conditions, so the corruption goes unnoticed for the moment. The audit trails take disk space, and since there is none available, they cannot write. Depending on details of the implementation, the audit program may even stop operating entirely. After the problem is found, there is an even bigger problem. How does the administrator prevent this attack and still allow legitimate mail to pass? It turns out that this is not so simple in most modern computer mail systems.
After posting this information to the `risks' forum on the Internet, numerous replies asserted that this attack was not properly defended on existing systems. [Neumann95] One respondent pointed out that electronic FAX and news transmissions had similar problems, and are not adequately addressed by many current systems.
In 1993, the quarterly `hacker' magazine 2600 had the following table of contents: [2600-92]
Title Subject -------------------------------------------------------------- A Guide to the 5ESS AT&T telephone switch British Credit Holes How to subvert and take over a person's credit and identity High School Hacking Breaking into high school administrative files Meeting Advice Frustration of law enforcement activities at hacker meetings More Acronyms Acronym Dictionary Printable Letters self explanatory AT&T Pages AT&T Addresses Government bulletin boards bulletin board phone numbers Video Review Critiques of security training videos 2600 Marketplace want/sale ads Toll Fraud Device Plans for a `red box' to use on pay phones 2600 Meetings hacker meetings ANSI Bomb How to build a logic bomb for use on DOS machines
Standards usually involve many components, and this task order doesn't address standards per-se, but in the process of this work, some ideas that may be worth considering in future standards came up.
The first idea is that there should be information assurance labels associated with processes and objects, and that those labels should be used to make decisions about how to behave during operation.
As a trivial example, suppose we label information with an availability integer in the range of 0-255, where 0 indicates the lowest priority and 255 indicates the highest priority. We attach this integer (stored as 1 byte of header information) to all processes, files, and packets used throughout the DII, thus creating a tagged architecture [Feustal73] reflecting this availability parameter. When decisions have to be made about which information is to pass through limited bandwidth, higher values are given higher probabilities. Similar labels can be associated with other factors, and rules can be made for the treatment of different values in different situations. The ability to interpret these sorts of rules can then be designed into systems, so that they automatically operate to reflect the rules, but are flexible enough to be programmed with new rules as design requirements change.
While this is only a trivial example of one element of a standard and how it could impact the ultimate operation of the DII, it points out the need and the value of creating an appropriate set of standards for information assurance requirements, and how doing this will directly impact the ultimate fulfillment of the information assurance goals in the DII. There is a precedent for this approach in the ``High Probability of Call Completion'' standard developed for the public switched telephone networks in support of National Security and Emergency Preparedness (NS/EP) telecommunications. This standard uses a ``traveling class mark'' to provide the capability for preemption of calls and other priority treatment for NS/EP calls within the network. [NRC89]
A second idea about standards for information assurance is that risk analysis for many other areas is fundamentally different than the techniques that apply to malicious disruption. Specifically, if an attacker knows how to disrupt a system, in most cases, the likelihood of success in an attack is 1. The probabilistic approach to analyzing defenses and attacks may not be appropriate for considering human agents with malicious intent. An alternative approach that has been tried with some success is a coverage approach in which we analyze techniques which cover different vulnerabilities for their coverage and costs, and provide a minimal cover for the desired level of redundancy. [WCCS] This optimizes costs for the specified goal but does not depend on assessing probabilities of attack, or expected losses.
A third idea about standards for information assurance relates to common mode failures and correlated events. [Neumann91] It seems that several major incidents per year involving common mode failure in redundant systems now occur, and there seems to be a strong correlation between these events and inadequate standards or capabilities for redundancy. The White Plains telephone cable incident in December of 1986 involved 7 redundant circuit connections for the ARPAnet (Advanced Research Projects Agency) intended to assure that no single (or multiple up to 6) failure could disable the network connection. Unfortunately, the telephone company ended up routing all 7 connections through the same optical fiber, and when that cable was cut, all 7 redundant connections were disrupted.
It seems critical that redundant connections be explicitly specified in a manner that identifies them as redundant with respect to each other to all levels of implementation, and that mechanisms be put in place so that identified redundancies are implemented with redundant physical mechanisms at all levels. For example, a set of co-redundant telephone lines identified to the telecommunications provider should result in the routing of those lines through separate switching centers, switches, tunnels, pipes, cables, and wires.
A more stringent requirement might also demand that the redundant connections operate in different media, (i.e. fiber, metal, microwave, etc.) go through different hardware components controlled by different software (i.e. 3b2s running Unix, Intel based processors running OS/2, 68000 based processors running Apple System 7, etc.), and be controlled by different telecommunications providers.
The automation systems that control the implementation of telecommunications and other aspects of systems would likely have to be redesigned to reflect this change, since most current designs only address efficiency, and when efficiency is less important than resiliency, they tend to do the wrong thing.
The same principles that apply to telecommunications apply to all components of the DII. For example, the movement toward megacenters makes the risks associated with a megacenter failure more severe, and thus dictates more consideration. For critical applications, there should be separate and different implementations that share the same data between geographically diverse locations, and perform redundant processing using different techniques to assure that disruptions don't result in failure. Similarly backups must be performed and stored redundantly, (i.e. separately and differently) and must be tested by restoration into a separate and different environment to assure that they are free of defects.
In many cases where redundant input is required, it isn't exploited for error detection and correction, which is the worst of both worlds. An example may help clarify this point. In the US, postal zip codes directly imply the state. Why then ask for the state? For efficiency reasons, we should not! On the other hand, by asking for the state and zip code, we can detect inconsistency and act to correct the error before it creates a larger problem (e.g., sending a paycheck to the wrong place). In most current systems, we have the worst of both worlds. We ask for both zip code and state, but never compare them to find errors. Thus we have both extra data entry and inadequate coverage of errors.
Compared to finding and correcting problems in the analysis phase, the average cost of a change (i.e., correcting a software fault) according to one study is increased by a factor of 2.5 in design, 5 in testing, and 36 in system integration. [Wolverton84] In another study of large high assurance software designs with high quality specifications and extensive testing, the cost impact of a change after a system is in operation is calculated to be 100 times the cost of a change during the specification phase. [Boehm81] The same study showed that the larger the system, the more cost advantage there was to making changes earlier, and for similar sized systems, correlated to the factor of 36 given in the other study. According to one software engineering text (that we feel may be less reliable than the previous two extensive studies), the cost of fixing an error rises as more work is built upon that error before it is found and fixed. ``The cost to catch a mistake and make a change at the time of writing the requirements specifications may be $10, and during the design $300. While the product is being built, the error may cost $3000; after the product has been delivered, the mistake could cost as much as $15,000 to fix, and possibly much more in losses to the client because the product didn't work. '' [Steward87] The costs of extensive testing alone for high assurance can double the overall system costs [Wolverton84] while producing little advantage against malicious attacks.
Covering intentional disruption is a more stringent requirement than covering random events, but the costs of added coverage are not always substantial. The study of node destruction in a uniformly connected network demonstrated that a factor of 10 increase in the number of available links was required in some circumstances to withstand intentional attack to the same extent as random destruction. But that study was based on design assumptions that do not have to be true. [Minoli80] On the other end of the spectrum, cost analysis of fairly strong proactive integrity protection techniques proved more than a factor of 50 more cost effective over the lifecycle of a system than defenses based on a reactive approach to attacks (which most DoD sites have chosen for protection against virus attack). [Cohen91-2] It appears that making early design decisions can save more than an order of magnitude in information assurance costs.
The potential cost differences between intentional and random disruption protection can reach a factor of at least 50 depending on early design decisions, and the costs of changes during system integration for large systems is on the order of 100 and increases with the size of the system. In the case of the DII, the overall system is more than an order of magnitude larger than the previous systems studied, which implies an even greater increase in the costs of making assurance enhancements later in the process.
It appears from the historical data that several orders of magnitude in savings may be attained by making proper information assurance decisions early in the process, but perhaps more realistically, we will not be able to afford adequate information assurance unless we design it into the DII from the start.
Another issue in cost analysis that must be considered is the difference between life-cycle costs and procurement costs. Perhaps no area demonstrates the lack of attention to this difference more clearly today than the area of computer virus defenses. Many DoD elements have purchased virus scanning programs as a defense against computer viruses on the basis that the cost per system is only about a dollar. Unfortunately, this is only the purchase cost and not the usage cost. The factor of 50 cost increase described above represents the difference between using a virus scanner every day and using a more cost effective protection technique. [Cohen91-2] The cost of the scanner may be only $1 per year, but the 2 or more minutes per day consumed by performing scans at system startup brings the lost time to over 600 minutes (10 hours) per system per year. Even at only $10 per hour of downtime, the costs of using the scanner are 100 times more that the cost of purchase in this example. Other factors in virus scanners make them far more expensive to use than alternative technologies, and more recent analytical results show that using imperfect scanners (which all scanners are) may lead to the spread of harder to detect viruses just as the use of antibiotics have led to the so called `superbugs' which resist antibiotics. [Cohen94-2]
Major concerns about network assurance come from several sources. The listing below is incomplete, but worth considering.
A number of countries have computer security groups, and some of these are working to certify operating systems, hardware, and software. This demonstrates that these countries are working to discover flaws in existing COTS products, and that these countries are aware of specific techniques by which these systems can be disrupted. European participants in ITSEC (Information Technology Security Evaluation Criteria) include England, Netherlands, France, and Germany, [NRC91] (App E, p 283.) with Italy beginning to join in. Russia, Japan, China, Australia, New Zealand, Singapore and South Africa are also countries with certification and/or active computer security interest.
A number of countries participate in the world market for telephone and data switching systems, and can be assumed to have the knowledge to disrupt telephone and data networks based on their design, manufacturing and deployment expertise. Companies marketing PBX (Private Branch Exchange) or CO (Central Office) equipment in the US and elsewhere include Hitachi, NEC (Nippon Electric Company) and Fujitsu (Japan), Ericsson (Sweden), Alcatel (France), and Siemens (Germany). [Trades] The DII may depend on systems from these manufacturers for information assurance.
One paper published in 1989 compares computer viruses to traditional electronic counter measures and states that computer viruses are uniquely qualified to disrupt tactical operations; that several recent trends in military electronic systems make them more vulnerable, including standard computers, software, and data links; and that protective measures must be initiated before viruses are used by an adversary. [Cramer89]
Limited direct evidence exists for associating virus discovery locations with virus origins (e.g. language particulars, programming styles) and there is a substantial body of indirect evidence in the form of discovery location statistics that suggests that disruption technology and expertise exists in many nations. One study associating virus discoveries with countries gave the following results:
Country virus discoveries Former USSR 76 United States 68 Bulgaria 61 Poland 38 Germany 30 Netherlands 26 Italy 23 Canada 23 England 22 Taiwan 16 Sweden 16 Israel 15 Spain 14 Australia 14From 3-10 viruses were first discovered in Argentina, Austria, Finland, France, Greece, Hungary, India, Indonesia, Malaysia, New Zealand, Portugal, Republic of South Africa, Switzerland, and Turkey. [Preston93]
Vendors of anti-virus software normally have detailed knowledge of computer operations and large collections of viruses to study. Anti-virus software vendors are in place in the US(5), Israel(3), United Kingdom(3), New Zealand(3), Holland(3), Australia(3), Thailand, Iceland, Canada, Colombia, Sweden, and Ukraine. [Slade]
Another indicator is the countries of residence of speakers at the ``International Computer Virus and Security Conference'', held in New York City each March. In 1992, technical talks were given by representatives from Germany(3), Bulgaria, Belgium, England(2), Iceland, Russia, Australia, Mexico, and Israel. [Lefkon93] Authors of anti-virus hardware and software can also be found in China, India, Taiwan, Japan, Malasia, several CIS (the former Soviet Union) countries, and others.
It is clear from computer virus information alone, that many countries of security interest to the US have knowledge and technology in the computer virus arena that could be directed specifically to disrupt the DII.
In one recent paper, over 30 countries are given excellent ratings in computer-communications espionage, meaning they almost certainly have sufficient expertise to corrupt computer and network data and disrupt operations. Among these countries are India, Taiwan, Republic of Korea, China, Japan, and South Africa. [Madsen93]
A talk by Wayne Madsen presented at IFIP SEC '90 (International Federation of Information Processing Societies annual Computer Security Conference in Finland) in 1990 provided a rating of various countries' ability to engage in computer `hacking', and the information that intelligence services were apparently becoming engaged in economic intelligence for business organizations. [Schweizer93]
Project Rehab, operated by Germany beginning in 1988, is a computer and network intrusion research effort which has accessed computer systems in the US and other countries. The project depends on `hacker' techniques and other research, and has approximately 36 computer specialists and senior intelligence officials assigned. A primary focus is on cataloging network addresses and establishing pathways for later use. [Schweizer93]
More details regarding potential adversaries and their capabilities would be helpful in performing assessments in this area, but that is beyond the scope of this effort.
In many cases, disruption is not detected at all. For example, in over 100 legitimate computer virus experiments, no user has ever noticed the presence of a computer virus. [Cohen94-2]
The vast majority of known information system attacks were first detected by attentive users noticing unusual behavior. This is widely known in the computer security community and is supported by virtually every source that discusses the issue. For example, over 2,000 computer viruses have been detected in the last 2 years by the research community, and almost all of them were detected by users noticing anomalies. The Internet virus of 1988 was detected when users noticed dramatic network slowdowns. [Spafford89] [Rochlis89] Hundreds of other failures in national telecommunications networks and individual systems are first detected by user complaints. [FCC-NRC-93] [NRC91] [NRC89] In major bank frauds involving electronic funds transfers, it is common for the first detection to be at the next bank audit, typically several months later.
Indirection between cause and effect dramatically increases the time required to track an attack to the source. Whereas total denial of services to an entire system is generally noticed quickly and total denial of services to an infrastructure is widely noticed almost right away, business disruption caused by subtle denial of services or corruptions may be far harder to detect and associate with a cause. For example, suppose a disruption in the form of subtle denial of services caused orders placed for certain replacement parts to be ignored by the output routines in the order fulfillment subsystem in the supply and logistics system. Orders would be placed, and the computer would indicate that the orders had been processed and shipped, but no shipments would arrive. Similarly, disruption in the form of subtle corruption could transform airplane engine part numbers into similar part numbers indicating different components, perhaps canteen cups. The order would be processed, but the resulting shipment would contain the wrong parts. It would probably be blamed on a data entry error, and if it only happened 10% of the time, the cause might go unnoticed for a long time.
Another subtle disruption approach is to slowly increase the level of denial of services over time so that the operators become acclimated to the slower and slower pace over a long period of time.
Differentiating natural disaster from other causes is generally not too difficult because natural disasters are easily detected on any wide scale. Differentiating accident from mischief from malice is yet another problem. The Internet virus was apparently an accident, and yet clearly many believe it was mischief and a few still believe it was malicious. Many disruptions are treated as accidental to avoid investigation. Almost no current organization has a way to tell one sort of disruption from another.
Limiting damage often takes too long to be effective. In the case of the IBM Christmas card virus of 1987, several days after the attack was launched, it was widely noticed, and over the next several days, IBM staff members tried unsuccessfully to disconnect their internal networks from the global networks. [IBMconv] [Cohen94-2] A defense against the Internet virus was only devised after over a full day of effort by people nationwide, and implementation of the work-around took several days. [Spafford89] [Rochlis89]
Recovery is sometimes impossible, while in other cases it takes from days to weeks. For example, a company in Germany was the subject of extortion from a hacker(1988-89), who showed them a few lines of program code which would have caused the gradual corruption of all inventory records. They did not find the altered code for several weeks. [Ginn89] The Chicago telephone center fire in 1989 took months to recover from, and tens of thousands of customers were without service for extended periods. [NRC91]
If the recovery process is improperly performed, many other problems can result. Audit trails may be lost thus preventing accurate determination of cause. The `recovered' system may be more vulnerable to disruption than the original. The recovery process may itself cause disruptions.
It may seem contradictory that efficiency and effectiveness do not always act in concert, but there is a very strong case to be made for introducing inefficiency into systems in order to make them more effective, particularly against disruptions.
In war, efficiency is even more counter to effectiveness, especially in the area of technology. It is precisely the standards we use to make technology efficient that make it easy to attack. [Creveld91-2] (pp316-320)
Based on observations made during this study, the authors believe that response to attacks is characterized by thresholds of detection and response capacity.
By lowering thresholds of detection, the defender is likely to detect more attacks, but the number and likelihood of false positives will also increase, and so will the cost of responding to the relatively minor incidents. By increasing the threshold of detection, response resources may be concentrated on the most important incidents, but a small incident with widespread impact may not be noticed until the damage becomes severe.
This leads to the issue of attack and defense. Given the option of a directed attack against a specific target or a more general attack which increases the overall `noise' level, the thresholding scheme employed for defense has a substantial impact on the optimal attack decision. It is always possible for an attacker to remain below the threshold of detection for any imperfect detection system, so a fixed threshold system leaves the defender open to noise-based attack. Similarly, a substantial directed attack will sound off any capable detection system and generate a response, but it may also be possible to create the appearance of substantial attack in order to force the defender to respond more strongly than necessary, this creating an environment where the defender constantly `cries wolf'. In either situation, a fixed response level is easily exploited, so a flexible and adaptive response is necessary in order to be effective.
In addition to detection thresholds, there is a response capacity inherently limited by the available response resources. In a human-based response system such as the one currently in place in the DoD, response time lags further and further behind as the number of incidents increase, eventually leading to a situation where important attacks are not noticed for a substantial amount of time. Increasing human resources is quite expensive and is only effective when the level of attack warrants the number of respondents. It takes a long time to train experts in this field, and there are relatively few of experts available and woefully few places where new experts can be trained.
An attacker can alternatively create and not create attacks so as to force a defender to waste resources with an overblown defensive capability, or an attacker can use attacks to determine response characteristics and work out ways to overwhelm the defense.
This area is particularly amenable to analysis based on reflexive control. To form a strong defense, the flexibility must be designed so as to prevent this sort of analysis.
Physical attacks are widely varied and cannot be adequately covered here, but certain recent technologies are particularly important to understanding the nature and scope of emerging physical threats.
Cars parked about 300 meters from an electromagnetic pulse (EMP) generator test had coils, alternators, and other controls disabled. The former Soviet Union developed an EMP weapon before its breakup, and nuclear EMP hardening has proven ineffective against this weapon. [Fulghum93-2] In the US, a Los Alamos EMP generator produced a 12-16 million amp pulse, with a rise time 400 nanoseconds. Some 16 x 40 inch generators have produced about 30 million amps of current. [Fulghum93]
FAA Federal Aviation Administration) measurements at one high density US airport peaked at 14,000 volts per meter from surveillance and satellite tracking radars. The FAA set a 200 v/meter no adverse effects limit for one aircraft, partly due to rapid movement of both aircraft and radar beam. [AvWeek]
The Ground Wave Emergency Network is the only US strategic defense communications system hardened to survive a high-altitude electromagnetic pulse (HEMP). [AvWeek2]
There is some difficulty in deciding whether enough shielding has been used against electromagnetic interference (EMI). EMI was suspected in Army Blackhawk helicopter crashes, since the Navy version has more shielding and fewer crashes. [Brewer89]
In an extreme example, one US patent describes a means and method for altering noise levels which is capable of disrupting atmospheric communications over vast areas of the Earth. Experiments performed in Alaska and elsewhere appear to demonstrate the ability to disrupt all ground-based, airborne, and space-based communications using signals transmitted through the air. [Eastlund87]