As discussed in Chapter 5, one of the ways to use a taxonomy is to determine the relative frequency of occurrences in the taxonomy categories. In this chapter, the taxonomy of computer and network attacks is used to determine the relative frequency of various kinds of attack activity. This activity was recorded in the methods of operation (MO) and corrective actions (CA) fields in the CERT^®/CC records (see Chapter 4).

Recording of the method of operation and corrective action data was not systematic or complete. As a result, this information is incomplete. Some valuable information, however, can be obtained by determining the relative frequency that various methods of operation and corrective actions appear in the CERT^®/CC incident records. This chapter presents a summary of the classification of key words describing the methods of operation found in the CERT^®/CC records. This classification uses the taxonomy developed in Chapter 6 (Figure 6.9). The complete methods of operation data are given in Appendix A. This chapter also includes a summary of corrective actions found in the CERT^®/CC incident records (with the complete data in Appendix B). An additional section discusses some of the things the CERT^®/CC records do not include, such as information about computer viruses.

8.1. Methods of Operation

As discussed in Chapter 4, the data extracted from the CERT^®/CC incident records included a field for methods of operation. In this field, key words were placed that described the various methods recorded. These key words also are instances in the categories of the attack taxonomy (Figure 6.9). In each category shown in Figure 6.9, the total occurrences was determined, along with the average starting date for the incidents involved. For example, the well-known toolkit called rootkit was recorded in 68 incidents beginning at the end of January, 1994. The mean starting date for these 68 incidents was March 19, 1995. This contrasts with the mean starting date of October 24, 1993 for all incidents, which is a year and a half earlier. This indicates that, in terms of the CERT^®/CC incident records, rootkit was a relatively new tool.

This type of information is interesting in several respects. First, it gives some indication of the relative importance of the method. In the above example, rootkit appeared in 1.6% of the incidents, which makes it relatively more important than the chasin or gimme tools , which appeared in 1.0% and 0.3% of the incidents respectively. Second, some indication can be seen of the placement of the method in time relative to other methods. For example, incidents in which chasin was recorded had an mean starting date of September, 1994, which indicates chasin is an older problem than rootkit. The gimme tool is even earlier, with a mean starting date in December, 1993. Finally, some indication of a trend may be found in the relationship of the mean of the start dates for the incidents which include a particular method, and the mean starting date for all incidents. For example, a mean starting date prior to October, 1993 (the mean starting date for all incidents), may indicate the prevalence of that particular method has been reduced over time.

In the CERT^®/CC records, more information was found about Tools and Access (see Figure 6.9), than the other categories. Very little information was in the records about the beginning and ending categories, Attackers and Objectives. The following sections give a summary of the methods of operation information available in the CERT^®/CC records in each of the Figure 6.9 categories. More detailed information is given in Appendix A. It should be remembered that incidents typically included multiple attacks and therefore multiple methods of operation and corrective actions. In other words, the categories were not mutually exclusive when multiple attacks were considered. More specifically, in the figures presented in the remainder of this chapter and in Appendices A and B, the frequencies in the figures (number of occurrences) do not necessarily add up between categories and sub-categories.

Large black squares indicate the mean reporting date of the incidents in that category. The first and last reporting dates are indicated by the vertical line. The number of incident records which record the particular corrective action are given by the numbers at the bottom of each column in the chart. The letters and numbers at the bottom of the chart indicate the specific methods of operation or groups as follows:

A - All Incidents B - All Attackers 1 - Hackers 2 - Vandals - former employees

8.1.1. Attackers - Very little information is found in the CERT^®/CC records about who the attackers have been. Usually references in the records were not specific. Examples are "the intruder was identified," "the attackers were found at xxxxxx," or "the system administrator has talked to the intruder." Only 35 (0.8%) of CERT^®/CC incident records are more specific. These incidents are shown in column B of Figure 8.1 which shows the range of reporting dates for the incident reports that contain information about attackers. This figure (and other similar figures in this chapter and Appendices A and B) plots vertical lines showing the initial reporting date and the final reporting date in each of the categories. The large black squares indicate the mean reporting date in that category. For comparison purposes, all of these figures plot the range for all incidents in the far left column. The data for all figures are listed in Table 8.1 at the end of this section.

Half of the 35 incidents in Figure 8.1 mention specific individuals (the 18 incidents in column 1). Most of these intruders were identified by location (Dutch, Danish, Australian, Portland hackers), or the by the intruder's nickname. One of the "Dutch" hackers in an incident beginning in 1989 was identified by name, and three incidents beginning in 1993 mention Kevin Mitnick. The incidents that mention specific individuals (column 1 in Figure 8.1) generally occurred earlier than either the average of all incidents with attacker information (column B), or the average of all incidents. This is not the same for the 17 incidents which mention that the intruder was a former employee. These incidents occurred, on average, later in the data as shown in column 2 of Figure 8.1. The incidents involving former employees were classified in the taxonomy as vandals.

There are several possible reasons the CERT^®/CC records do not contain more information about attackers. One possibility is that the attackers are rarely identified. This may not be the case because many of the incidents make reference to intruders being identified. A more likely possibility is related to the method of operation of the CERT^®/CC itself. The CERT^®/CC provides Internet users "real time" assistance with security incidents. Once an incident is under control, the interaction with the CERT^®/CC and the sites involved is reduced. Less information is recorded toward the end of the incident, perhaps because this is not needed in order for the CERT^®/CC to perform its duties. This may also be the same reason that little information is found in the CERT^®/CC records on corrective actions as discussed in Section 8.2.

8.1.2. Tools - The second block in the taxonomy of Figure 6.9 is Tools. In Chapter 6, six categories of tools were described. Figure 8.2 shows the first, mean and last reporting date for CERT^®/CC incident reports containing keywords referring to tools. A total of 778 incidents (18.1% of all incidents) reported the use of some tool.

From these records, the largest category of tools was scripts or programs (661 incidents, 15.4% of all incidents, 85.0% of tools). These consisted primarily of Trojan horses (450 incidents, 10.5% of total, 57.8% of tools) and sniffers (245 incidents, 5.7% of total, 31.2% of tools). As can be seen in Figure 8.2, Trojan horses were used throughout the period of this research. The average reporting date was near the average for all incidents. Sniffers, on the other hand, were first reported in the second half of 1990, and their average reporting date was around a year later. Trojan horses were recorded in the CERT^®/CC records as occurring in at least 45 different programs. The most common program was login which accounted for 56% of the Trojan horses recorded (in 251 incidents, 5.8% of total). Two other common programs for Trojan horses were telnet (70 incidents, 1.6% of incidents, 15.6% of Trojan horses), and ps (53 incidents, 1.2% of incidents, 11.8% of Trojan horses). See Appendix A for further details.

Large black squares indicate the mean reporting date of the incidents in that category. The first and last reporting dates are indicated by the vertical line. The number of incident records which record the particular corrective action are given by the numbers at the bottom of each column in the chart. The letters and numbers at the bottom of the chart indicate the specific methods of operation or groups as follows:

A - All Incidents 2 - keystroke logging 6 - denial-of-service tools 9 - to get root

B - All Tools 3 - Trojan horse 7 - sniffer F - All Autonomous Agents

C - All User commands 4 - password cracker E - All toolkits 10 - worm

D - All Scripts or Programs 5 - to get root 8 - scanners 11 - virus

1 - logic bomb

It is interesting to note that the CERT^®/CC records contain very few references to autonomous agents such as worms, and viruses. This may indicate these agents were of little use on the Internet during this period. This also may reflect that reports of these agents were not generally sent to the CERT^®/CC. This is discussed further in Section 8.3.

Another tool that was found on average later in the CERT^®/CC records was toolkits. As Figure 8.2 shows, toolkits were found generally in the same time frame as sniffers, which may indicate that toolkits and sniffers were generally used together. Some toolkits are known to contain sniffers and other tools such as Trojan horses.

Keywords describing toolkits (185 incidents, 4.3% of total, 23.8% of tools) were slightly less frequent than sniffers. The two general categories of toolkits were tools designed to exploit privileged or root access (such as rootkit), which were mentioned in 77 incidents (1.2% of total, 9.9% of tools), and scanners (such as ISS, and SATAN), mentioned in 111 incidents (2.6% of total, 14.3% of tools). These tools appeared relatively late in the CERT^®/CC records. Toolkits to exploit root were not mentioned in the records until the middle of 1992, and scanners did not appear until 1993. One other category of tools worth noting is password cracking programs (such as crack) which were first recorded in the CERT^®/CC records at the beginning of 1992 (52 incidents, 1.2%).

Only 3 incidents in the CERT^®/CC records make specific references to intruders using user commands. This is clearly not a reflection of their frequency of use. For example, Chapter 7 indicated that 1,618 incidents were classified as access attempts. Of these, 1,080 incidents were more specifically classified as login attempts (see Appendix A), which is assumed to be initiated by user commands. It appears that CERT^®/CC personnel did not usually record when intruders were using user commands, and that it is likely that user commands actually were the most common tool. Intruders, after all, must use some tool, and only 775 of the incidents (18.0%) mention other tools. If we assume the intruders in the remaining incidents used user commands, they were then used in a minimum of more than 80% of the incidents.

There was no mention in any of the CERT^®/CC records of the use of the other two categories of tools: Data taps, or Distributed tools. Data taps are physical taps and not attacks across the Internet, which makes them much less likely to be reported to the CERT^®/CC. Distributed tools do not appear in the CERT^®/CC records until after the period of this research.

8.1.3. Access - The majority of method of operation information in the CERT^®/CC records concerned the access block of the taxonomy. Most incidents (4,078 incidents, 94.9%) recorded some information about access. Referring to Figure 6.9 in Chapter 6, the access block has three parts. The middle part classifies incidents as either being unauthorized access, or unauthorized use, which was already discussed in Chapter 7. Some information is contained in the records as to which type of account was accessed. They are discussed at the end of this section. The type of account accessed may give some indication of the files that were accessed, but other than this, the CERT^®/CC records contain little direct information about which processes and files were involved in the CERT^®/CC incidents. Which processes and files were involved in an incident were, to a certain extent, implied by the other information about the incident. For example, information that a telnet vulnerability was exploited for an attack would perhaps indicate that a telnet process was involved. The use of sniffers would indicate that data in transit was accessed. Trying to determine the processes and files involved in the incidents using this implicit information was not attempted as part of this research.

Large black squares indicate the mean reporting date of the incidents in that category. The first and last reporting dates are indicated by the vertical line. The number of incident records which record the particular corrective action are given by the numbers at the bottom of each column in the chart. The letters and numbers at the bottom of the chart indicate the specific methods of operation or groups as follows:

A - All Incidents 4 - netfind 10 - uucp 16 - mem

B - All Access 5 - motd 11 - chfn/chsh 17 - history

C - All Vulnerabilities 6 - shutdown 12 - bin/shell 18 - password vulnerability

1 - install 7 - .forward 13 - configuration 19 - mult

2 - rcp 8 - emacs 14 - fparel 20 - trusted hosts

3 - autofinder 9 - tftp 15 - ftp

The first of the three parts in the access block of the taxonomy concerns vulnerabilities. Figures 8.3 through 8.6 present these vulnerabilities in order according to the average reporting date of the incidents which recorded those vulnerabilities. Nearly half of the incidents in the CERT^®/CC records mention specific vulnerabilities (1,948 incidents, 45.3%). There was generally not enough information to determine whether the vulnerabilities were due to design or implementation problems, as divided in Figure 6.9. Some information on vulnerabilities due to configuration errors was available and is discussed in Section 8.1.3.5.

8.1.3.1 Password Vulnerabilities - The most frequently recorded vulnerability involved various problems with passwords, which were mentioned in 938 incidents (21.8%, column 18, Figure 8.3). There were 16 different combinations of keywords that indicated password problems. Most of the password vulnerabilities were in three categories: password files, generally indicating that a password file had been copied (592 incidents, 13.8%, 63.1% of password vulnerabilities), password cracking, which indicated that passwords had been determined by the operation of a password cracking tool (448 incidents, 10.4%, 47.8% of password vulnerabilities), and weak passwords, which could be easily guessed (156 incidents, 3.6%, 16.6% of password vulnerabilities). It is interesting to note that password cracking was recorded as an exploited vulnerability in nearly an order of magnitude more incidents than the tools used for the cracking (448 incidents mentioning password cracking, compared to 52 incidents mentioning password cracking tools). See Appendix A for further details.

Large black squares indicate the mean reporting date of the incidents in that category. The first and last reporting dates are indicated by the vertical line. The number of incident records which record the particular corrective action are given by the numbers at the bottom of each column in the chart. The letters and numbers at the bottom of the chart indicate the specific methods of operation or groups as follows:

A - All Incidents 4 - crontab 10 - misc/unknown 15 - news

B - All Access 5 - rwall 11 -rdist 16 - yp

C - All vulnerabilities 6 - dev 12 - rexd 17 - modload

1 - decode, uudecode 7 - expreserve 13 - x 18 - gopher

2 - telnet 8 - ping 14 - dns 19 - smtp

3 - bugs 9 - libc

8.1.3.2 SMTP - SMTP (Simple Mail Transfer Protocol), is the TCP/IP transport protocol for transferring mail messages between Mail Transfer Agents (MTAs) [LyR93:186]. The most well-known MTA is the sendmail program originally included in the Berkeley distribution of UNIX. Sendmail has the reputation of being the mailer that is the "most plagued with security problems" [GaS96:497]. This was confirmed in the CERT^®/CC incident records which contain 447 incidents with references to sendmail (Figure 8.5 column 8, 10.4% of all incidents, 22.9% of vulnerabilities), and an additional 15 incidents with references to SMTP (Figure 8.4 column 19, 0.4% of all incidents, 0.8% of vulnerabilities).

8.1.3.3 Mail - Related closely to the SMTP and sendmail vulnerabilities are those vulnerabilities associated with the keyword mail, which were recorded in 333 incidents (Figure 8.5 column 5, 7.7% of all incidents, 17.1% of vulnerabilities). This category includes mail spoofing (210 incidents), mail bombs (44 incidents), binmail (39 incidents), mailrace (36 incidents), and mail abuse (28 incidents). Further information is given in Appendix A.

8.1.3.4 Trusted hosts - Trusted host is described by Garfinkel and Spafford as follows:

Trusted host is a term that was invented by the people who developed the Berkeley UNIX networking software. If one host trusts another host, then any user who has the same username on both hosts can log in from the trusted host to the other computer without typing a password [GaS96:516].

The CERT^®/CC records indicate there were 249 incidents where a problem with an implementation of trusted hosts was recorded (Figure 8.3 column 20, 5.8% of all incidents, 12.8% of vulnerabilities). Appendix A indicates these problems primarily involved the use of the two files that are used to designate the trusted hosts. On a network basis, this is done in the hosts.equiv file, which was mentioned in 52 incidents (1.2% of all incidents, 2.7% of vulnerabilities). Individual users can establish trust for their username through the .rhosts file, which was mentioned in 210 incidents (4.9% of all incidents, 10.8% of vulnerabilities).

8.1.3.5 Configuration - Network software must be configured properly in order for it to be secure. Some investigators have concluded that improper configuration may be the cause of most UNIX security problems [GaS96:273]. Although configuration problems appear significant, they were not identified in the majority of CERT^®/CC incident records. Configuration was identified as a problem in a total of 244 incidents (Figure 8.3 column 13, 5.7% of all incidents, 12.5% of vulnerabilities). Of these, 158 incident records identify this problem through the keyword configuration, but an additional 96 incidents stated the configuration problem was specifically an open server which did not have proper access controls implemented to prevent its use (see Appendix A).

8.1.3.6 TFTP - Many early versions of TFTP, the trivial file transfer protocol, did not restrict access to certain directories [GaS96:506]. These insecure versions of TFTP could then be used by anyone on the Internet to transfer critical files, such as the system's password file. Figure 8.3 column 9 depicts the reporting dates of the 238 incidents which recorded the exploitation of TFTP vulnerabilities (5.5% of all incidents, 12.2% of vulnerabilities). It is interesting to note that the average reporting date for these incidents is nearly a year prior to the average for all incidents. Perhaps this indicates this vulnerability became less of a problem over time.

Large black squares indicate the mean reporting date of the incidents in that category. The first and last reporting dates are indicated by the vertical line. The number of incident records which record the particular corrective action are given by the numbers at the bottom of each column in the chart. The letters and numbers at the bottom of the chart indicate the specific methods of operation or groups as follows:

A - All Incidents 4 - irc 10 - time 15 - rsh/rlogin

B - All Access 5 - mail 11 - finger 16 - snmp

C - All vulnerabilities 6 - nis 12 - rpc 17 - autoreply

1 - inetd 7 - dump 13 - suid 18 - tcp

2 - icmp 8 - sendmail 14 - source hiding 19 - talk

3 - nfs 9 - lp

8.1.3.7 NIS - The Network Information Service (NIS) is a client/server system developed by Sun Microsystems to simplify the administration of network system files [Sob95:163]. On networks using NIS, important information, such as user names and passwords are maintained in a centralized database shared within the network. Exploitation of NIS was recorded as a method of operation in 103 of the CERT^®/CC incidents (Figure 8.5 column 6, 2.4% of all incidents, 5.3% of vulnerabilities). An additional 69 incidents recorded YP as a vulnerability (Figure 8.4 column 16, 1.6% of all incidents, 3.5% of vulnerabilities). YP was the name of the early version of the NIS. See Appendix A for additional details.

8.1.3.8 FTP - The File Transfer Protocol (FTP) has more security features than TFTP. It was still identified in 170 of the CERT^®/CC incident records (Figure 8.3 column 15, 4.0% of all incidents, 8.7% of vulnerabilities).

Large black squares indicate the mean reporting date of the incidents in that category. The first and last reporting dates are indicated by the vertical line. The number of incident records which record the particular corrective action are given by the numbers at the bottom of each column in the chart. The letters and numbers at the bottom of the chart indicate the specific methods of operation or groups as follows:

A - All Incidents 4 - login 10 - pipe 15 - domain

B - All Access 5 - utmp 11 - traceroute 16 - ps

C - All vulnerabilities 6 - udp 12 - http 17 - fork

1 - nntp 7 - majordomo 13 - ident 18 - syslog

2 - loadmodule 8 - mouse 14 - rexec 19 - windows nt

3 - portmap 9 - kernal

8.1.3.9 NFS - Appendix A shows that a variety of Network File System (NFS) commands were used by intruders in 138 attacks on the Internet summarized in the CERT^®/CC records (Figure 8.3 column 3, 3.2% of all incidents, 7.1% of vulnerabilities).

8.1.3.10 Other vulnerabilities - Appendix A gives details of other vulnerabilities identified in the CERT^®/CC records.

8.1.3.11. Types of Accounts - Figure 8.7 summarizes information in the CERT^®/CC records about the types of accounts attacked. As would be expected, user accounts were the most frequently identified (121 incidents, 2.8% of all incidents, 54.3% of identified accounts). Other accounts that were identified in multiple incidents included system accounts, (53 incidents, 1.2% of all incidents, 23.8% of identified accounts), sync accounts (38 incidents, 0.9% of all incidents, 17.0% of identified accounts), and guest accounts (35 incidents, 8.1% of all incidents, 15.7% of identified accounts). Sync and guest accounts became well-known vulnerabilities early in the period of the CERT^®/CC records [GaS96:228]. While both of these accounts continued to be problems throughout the period, the average reporting dates were well prior to the average for all incidents, which may indicate these vulnerabilities were being corrected.

Large black squares indicate the mean reporting date of the incidents in that category. The first and last reporting dates are indicated by the vertical line. The number of incident records which record the particular corrective action are given by the numbers at the bottom of each column in the chart. The letters and numbers at the bottom of the chart indicate the specific methods of operation or groups as follows:

A - All Incidents 2 - demo account 6 - me account 10 - user account

B - All Access 3 - guest account 7 - system account 11 - uucp account

C - All Type of account 4 - sync, sync account 8 - lp account 12 - nobody account

1 - parity account 5 - field, field account 9 - bin account

8.1.4. Results - The CERT^®/CC incident records contain 419 incidents with some information about the results category of the taxonomy (Figure 8.8, 9.7%). The largest category of these results was theft of service (Figure 8.3 column 3, 290 incidents, 6.7% of all incidents, 69.2% of results), which primarily consisted of FTP abuse (263 incidents, 6.1% of all incidents, 62.8% of results).

Interestingly, disclosure of information was another large category of results (252 incidents, 5.9% of all incidents, 60.1% of results), which consisted primarily of software piracy (221 incidents, 5.1% of all incidents, 52.7% of results), and the nickname for pirate software, warez (73 incidents, 1.7% of all incidents, 17.4% of results). FTP abuse, software piracy, and warez are all related, so it makes sense that they were recorded in a similar number of incidents. Software piracy was not considered a security incident by the CERT^®/CC, and their reporting was not encouraged. As such, this category may be underreported in the CERT^®/CC records. In addition, very few other incidents reported anything else in the disclosure of information category.

There were 170 incidents in the CERT^®/CC records that gave information about the corruption of information (4.0% of all incidents, 40.6% of results), which primarily consisted of modifying or deleting logs (103 incidents, 2.4% of all incidents, 24.6% of results), or of deleting files (71 incidents, 1.7% of all incidents, 17.0% of results).

Large black squares indicate the mean reporting date of the incidents in that category. The first and last reporting dates are indicated by the vertical line. The number of incident records which record the particular corrective action are given by the numbers at the bottom of each column in the chart. The letters and numbers at the bottom of the chart indicate the specific methods of operation or groups as follows:

A - All Incidents 1 - corruption of information 3 - theft of service 4 - denial-of-service

B - All Results 2 - disclosure of information

Figure 8.8 shows only 6 incidents in the denial-of-service category. As stated in Chapter 7 and 11, the number of denial-of-service incidents, or incidents in which denial-of-service was mentioned in the CERT^®/CC records, was actually 143. The difference between these two numbers shows the lack of information in the CERT^®/CC records about actual results. In other words, the CERT^®/CC records recorded 143 denial-of-service attacks or attempts, but indicated actual denial-of-service resulted in only 6 incidents. It is not to say that the others did not result in successful denial-of-service, just that this information was not recorded in the CERT^®/CC records.

8.1.5. Objectives - The last figure in this series, Figure 8.9 shows the information available in the CERT^®/CC records concerning objectives. As with the attacker category on the opposite end of the taxonomy (Figure 6.9), little information was found in the CERT^®/CC records concerning objectives. Only 56 incident records (1.3%) mention the achievement of objectives. Of these, 44 incidents mentioned financial gain (1.0% of all incidents, 78.6% of objectives), which was primarily credit card fraud (27 incidents, 0.6% of all incidents, 48.2% of objectives). The other 12 incidents mentioned damage (0.3% of all incidents, 21.4% of objectives).

8.1.6. Summary of Methods of Operation - This research revealed the CERT^®/CC records to be inconsistent in the amount of information in the categories in the taxonomy for this research (Figure 6.9). Tools and Access had the most information, while the results category information was limited to only one type of attack, and little information was recorded about the beginning and ending blocks of the taxonomy, attackers and objectives.

Large black squares indicate the mean reporting date of the incidents in that category. The first and last reporting dates are indicated by the vertical line. The number of incident records which record the particular corrective action are given by the numbers at the bottom of each column in the chart. The letters and numbers at the bottom of the chart indicate the specific methods of operation or groups as follows:

A - All Incidents B - All Objectives 1 - financial gain 2 - damage

The data plotted above are given in numerical form in Table 8.1. More detailed information on the methods of operation is given in Appendix A. (NOTE: The "Delta" column indicates the differences between the mean report for that category and the mean report for all incidents).

8.2. Corrective Actions

As was stated earlier, the records of the CERT^®/CC are incomplete with respect to corrective actions taken during incidents. Of the 4,299 incidents, 63 incident records (14.7%) have no information on corrective actions. In another 2,848 incident records (66.2%), the only corrective action in the records, or that can be inferred from the records, is that the site or sites involved were notified.

Figure 8.10 and Table 8.2 summarizes the information about corrective actions from the 1,388 incidents (32.3%) that reported additional corrective actions. Appendix B presents these data in more detail. These corrective actions were classified into two broad categories: internal actions, and external actions. Internal actions are those actions that a system administrator might take to make a site or host more secure, such as restricting, configuring, or upgrading hardware or software, or by various preventive measures. External actions are those actions taken outside the organization, such as actions against the intruder, or actions involving law enforcement.

Large black squares indicate the mean reporting date of the incidents in that category. The first and last reporting dates are indicated by the vertical line. The number of incident records which record the particular corrective action are given by the numbers at the bottom of each column in the chart. The letters and numbers at the bottom of the chart indicate the specific methods of operation or groups as follows:

A - All Incidents 3 - Upgrade system hardware/software

B - All Corrective Actions 4 - Preventive Measures

C - All Internal Actions D - All External Actions

1 - Restrict system hardware/software 5 - Take action against intruders

2 - Configure system hardware/software 6 - Law enforcement

8.2.1. Internal Actions - Figure 8.10, columns C and 1 to 4 summarize the 1,137 CERT^®/CC incidents which recorded internal actions (26.4% of all incidents, 81.9% of corrective actions). The most frequently mentioned corrective action was to restrict hardware/software (674 incidents, 15.7% of all incidents, 48.6% of corrective actions). This included actions such as closing accounts (460 incidents, 10.7% of all incidents, 33.1% of corrective actions), filtering network traffic (162 incidents, 3.8% of all incidents, 11.7% of corrective actions), and disconnecting from the network (124 incidents, 2.9% of all incidents, 89.3% of corrective actions).

Related to restricting systems were actions to configure system hardware/software (447 incidents, 10.4% of all incidents, 32.2% of corrective actions). These actions primarily involved changing passwords (310 incidents, 7.2% of all incidents, 22.3% of corrective actions), securing servers/routers (140 incidents, 3.3% of all incidents, 10.1% of corrective actions), and restricting servers (38 incidents, 0.9% of all incidents, 2.7% of corrective actions).

The third category of actions to correct or improve systems were actions to upgrade system hardware/software (367 incidents, 8.5% of all incidents, 26.4% of corrective actions). The primary actions were to patch software (200 incidents, 4.7% of all incidents, 14.4% of corrective actions), reload software (161 incidents, 3.7% of all incidents, 11.6% of corrective actions), and upgrade software (81 incidents, 1.9% of all incidents, 5.8% of corrective actions).

The final category of internal actions were preventive measures (245 incidents, 5.7% of all incidents, 17.7% of corrective actions). The primary action was to increase monitoring (143 incidents, 3.3% of all incidents, 10.3% of corrective actions). Software programs were also used, such as cops (75 incidents, 1.7% of all incidents, 5.4% of corrective actions), crack (28 incidents, 0.7% of all incidents, 2.0% of corrective actions), and tripwire (26 incidents, 0.6% of all incidents, 1.9% of corrective actions).

8.2.2. External Actions - Figure 8.10, columns D, 5 and 6 summarize the 478 CERT^®/CC incidents which recorded external actions (11.1% of all incidents, 34.4% of corrective actions). These external actions were placed in two categories: actions against intruders (295 incidents, 6.9% of all incidents, 48.6% of corrective actions), and law enforcement (237 incidents, 5.5% of all incidents, 17.1% of corrective actions).

Actions against intruders included talking to intruders (273 incidents, 6.4% of all incidents, 19.7% of corrective actions), punishment (23 incidents, 0.5% of all incidents, 1.7% of corrective actions), and arrest (27 incidents, 0.6% of all incidents, 1.9% of corrective actions).

Law enforcement organizations identified included the police (141 incidents, 3.3% of all incidents, 10.2% of corrective actions), the FBI (110 incidents, 2.6% of all incidents, 10.2% of corrective actions), and the Secret Service (19 incidents, 0.4% of all incidents, 1.4% of corrective actions).

These data are summarized in Table 8.2. Further information about corrective actions can be found in Appendix B. (NOTE: The "Delta" column indicates the differences between the mean report for that category and the mean report for all incidents).

8.3. Some Things the CERT^®/CC Incidents Do Not Include

Chapter 7 and the previous sections of this Chapter have shown that the CERT^®/CC records are inconsistent in completeness with respect to the taxonomy of Figure 6.9. For some parts of the taxonomy, the CERT^®/CC records provided significant information. Very little information was found in the CERT^®/CC records for some of the other categories of the taxonomy.

Reasons for this disparity vary. One likely cause was the relationship between the information and the mission of the CERT^®/CC. As discussed previously, the CERT^®/CC has been responsible for incident response on the Internet