 |
|
This chapter presents policy implications of this research and recommended actions for Internet users, suppliers, response teams and the U.S. government. This includes an estimate of the likelihood an Internet domain or host will be involved in an incident. This chapter also presents an analysis of the information policies of the U.S. government and Internet incident response teams, and recommends changes to these policies. 14.1. General Implications of This Research Security is a problem on the Internet. The thousands of successful break-ins described in this research are a testimony to that. Numerous authors -- scholars and sensationalists alike -- go even farther by describing the Internet as a dangerous place in terms of security. But just how much of a problem does this research say security really is on the Internet? As stated in Chapter 1, the answer to this question is important for two reasons. First, with information about Internet security problems, we could determine to what extent, and in what areas, government programs and policies should be instituted to protect the Internet. Second, trends over time could indicate the effectiveness of these policies and programs. Because it shows the state of security on the Internet, this research is also important for Internet users, suppliers, and response teams. It provides all of these Internet participants indications of what they should and should not be doing on the Internet because of potential security problems. It can also indicate whether increased user awareness, more secure software and hardware, improved security tools, and increased incident response capacity, lead to desired changes in incident trends. What this research shows is a mixed message. On the positive side, this research clearly shows that the state of Internet security is not as bad as some authors have proposed. Both in terms of the absolute numbers of incidents, and in the growth of these incidents, the numbers are lower than reported in popular literature and in the Press. More importantly, response teams and researchers are not as unaware of Internet security activity as some authors have argued. As shown in Chapter 12, the most serious incidents on the Internet are reported and successfully dealt with. In addition, none of the incidents were tremendously destructive. In fact, very few instances were recorded of destructive attacks. Most attacks were in the category of a nuisance (although some were a big nuisance), and not something more destructive or harmful. Nevertheless, on the negative side, security incidents were clearly not dropping to zero. As shown in Chapter 7, the rate of growth of Internet incidents was less than the growth of Internet hosts by 7%. But, stated another way, this means that the growth of Internet incidents in absolute terms was nearly at the same pace as the growth of the Internet. If these trends were to continue indefinitely, the number of Internet incidents may eventually drop in absolute terms, but clearly not for a very long time. To put this in perspective, we can use the estimates of total Internet incident activity in Chapter 12 to see how likely we are to be involved in an Internet incident. In Table 12.13, the number of total Internet incidents per year for 1995 was estimated to be between 1,200 and 22,800. The average number of sites per incident was 6.5, which means an estimate of the number of sites involved in an incident per year is between 7,800 and 148,000. In July, 1995, the number of Internet domains was estimated to be around 120,000, and the number of Internet hosts to be around 6.64 million. This yields the very rough estimates in Table 14.1.
This table shows that, according to these estimates, a typical Internet domain is involved in no more than around one incident per year. In terms of hosts, the estimates of Table 14.1 show that a typical Internet host is involved in no more than around one incident in every 45 years. The CERT®/CC records show that some sites and hosts are apparently more attractive because they were involved in many incidents each year. This means that for the average, less attractive, domains and hosts, the probability of being involved in an incident is even lower. In addition, as shown by this research, many of the Internet incidents are minor and often do not involve successful break-ins. As such, the rate at which domains and hosts are involved in serious incidents is even lower. For example, at Site A only 7% of incidents involved root break-ins. If this were similar throughout the Internet, then the maximum rate that any one domain would be involved in a root break-in would be around once in 10 years (instead of once in 0.8 years), and any individual host around once in 540 years (instead of once in 45 years). These rates of occurrence are similar to other risks that we take reasonable precautions for. The following are several examples:
Table 14.2 compares these examples with the Internet security risks. The conclusion we can draw from this is that there is a steady, but relatively small, level of Internet security incidents. Internet users should take reasonable security precautions, just as they would take for other risks in their lives. In addition, Internet suppliers should produce and distribute products that provide users with reasonable security, and the U.S. government and Internet response teams should institute programs and procedures to mitigate Internet security problems.
The following sections discuss these implications in more detail. 14.2. Implications for Internet Users This year you will most likely not be the victim of a violent crime, have your house robbed, or your car stolen. But you might. Because of this, you are likely to take reasonable precautions to protect yourself and your property. This research shows the same is true of the Internet. Unlike what some authors have proposed, if you are an Internet user, this year you are most likely not going to be the victim of an Internet attack. But you might. Because of this, you should take reasonable precautions to protect the files on your computer, and to protect your data as it transits the Internet. Two analogies illustrate this point. Take, for example, convenience stores. They get robbed sometimes. This could clearly be prevented with a "fortress" security system of physical barriers and armed guards. But then how convenient would that store be to shop in? Instead of ensuring no risk of robbery, the convenience store owner typically takes reasonable precautions against robbery in order reduce that risk, but accepts some risk in order to ensure the store is still convenient to shoppers. An Internet user can be perfectly secure from Internet attack by simply disconnecting from the Internet. But then, this user would no longer be an Internet user. Instead of taking this no risk strategy, it is probably more appropriate to take reasonable precautions and accept a level of risk that depends on that user's individual needs. A second analogy is the mail system. We view the mail system as generally being secure enough to send a personal letter, or to send a check to pay a bill. On the other hand, most people do not send cash or valuables through the mail unless special precautions are taken. We also don't usually send sensitive personal information on a post card, and instead, we enclose it in an envelope. Sometimes a letter is lost, but not often. In some ways, the Internet is a less secure system than the U.S. Postal Service ("snail mail" in the computer vernacular). E-mail is sent across the Internet in clear text that could be read by other users. On the other hand, Internet e-mail is usually a lot quicker, and perhaps more convenient and inexpensive. As such, users may be willing to accept the higher security risk when using the Internet in order to have the capabilities. Prudent users of the Internet, however, should take precautions in two ways. First, they should take reasonable precautions to protect their files stored on their local computer or stored on the network. And second, they should take reasonable precautions to protect their data in transit on the Internet. For each user of the Internet, the reasonable level of precautions may be different, and it depends on that user's needs. 14.2.1. Basic Precautions All Users Should Take to Protect Files - There are three basic precautions that all Internet users should take. The first precaution is to back up important files. This will not prevent an incident, but it may reduce the impact if a user is involved an incident. Which files should be backed up can easily be determined if a user imagines losing the original files. For example, if a user's files are stored on the local hard drive, what would the user lose that is important if the hard drive files were lost? Software can usually be reloaded, but a user's personal files may be lost permanently if they are not stored elsewhere. How many backups a user should make and where they should be stored depends on how important the files are. The files for this dissertation were an extreme example, but I was determined not to lose any of the files, so I backed up all files to hard drives on four different computer systems (in different locations) and three sets of floppy disks. For most users, one backup to floppy disks or to a hard drive on a separate computer is probably sufficient. The second security precaution that all users should take is to have a good password for the access controls to their network. Unlike backing up files, this action may prevent an incident. This research showed that 22% of all incidents in the CERT®/CC records involved problems with passwords. Good passwords have the following characteristics: 1) eight or more characters, 2) both uppercase and lowercase letters, 3) punctuation or other special characters, 4) easily remembered (no need to write down), and 5) can be typed quickly [RuG91:61; GaS96:63]]. Having a good password will help protect a user from having his account and files accessed under most conditions. What it will not protect against is an intruder who gains access to the root level on the computer system, which would allow bypassing the account access controls. As shown in this research, however, this does not happen often. A good password can also be compromised if it is sent over the Internet in the clear, which may allow it to be read by sniffer software. One precaution that a user can take to minimize this problem is to change passwords periodically. This research shows, however, that this is unlikely to do much good. This is because of a combination of the low likelihood of a user's password being sniffed, and that actual incidents are of short duration. The likelihood that a user's password is going to be sniffed is low for several reasons. First, many users do not send their password over the Internet in the clear because they do not sign into systems over the Internet (they only sign in locally). Second, as Chapter 8 indicated, even though passwords were identified as a problem in 22% of all incidents, only 245 incident records mentioned sniffers specifically (5.7%). As was discussed earlier in this chapter, a typical Internet domain is involved in an incident no more than around once a year. On the other hand, the rate at which a typical domain is involved in an incident where a sniffer is used is probably significantly less. Using this criteria, users could safely go years without changing passwords. If, however, a user's password is sniffed from the network, then any resulting problems will occur in a relatively short period of time. The average duration of incidents involving root or account break-ins was 23.4 days, for incidents recording password problems, 8.6 days, and incidents recording sniffer use, 17.3 days. Using these figures, a user should change passwords every few days so that if the password is compromised, any resulting problems will be minimized. But then, as stated above, the incidents don't happen very often. Some site administrators require users to change passwords every few months. As was discussed above, this is too long a period to reduce problems if a password is actually sniffed, and it is too frequent based on the probability of an incident taking place at any particular site. This research seems to indicate that changing passwords every few months is generally not appropriate. Instead, site administrators should probably ask users to change passwords only if their site is compromised, or if the site administrator determines the user has a weak password (such as through the use of a password cracking program). One caveat is that users who frequently sign in over the Internet (send their password in the clear over the Internet) should consider changing their password frequently. A third precaution that all users should take is to ensure that permissions on files that can be accessed by others are set properly. An example of files that could be accessed by others are files in a Unix account. The Unix operating system maintains a set of permissions on each file that establishes permission to read, write, or execute the file by the file owner, a group of users, or all users. If a user does not want other users to read his files, then the permissions for each file must be set to prevent this. This is not just a concern for Unix users. As operating systems become more network capable, such as Windows NT, the same capabilities and concerns arise. 14.2.2. Advanced Precautions to Protect Files - Users may elect to take further precautions for files that are particularly sensitive. If the concern is unauthorized disclosure, files could be encrypted. Another alternative is to store files off-line from the network. 14.2.3. Precautions to Protect Data in Transit - Almost all Internet traffic is sent "in the clear." This means that it can be read by software on any host computer through which the network packets are routed. This should be of little concern to most Internet users because most of the packets traveling on the Internet contain data that is not sensitive from the user's viewpoint, and is not of interest to Internet attackers. Three types of information traveling across net that are sensitive to users, and of interest to Internet attackers, are discussed in the following paragraphs. The first type of sensitive information traveling across the Internet is user name, password, and IP address combinations. These data are the primary targets of sniffer programs operated by Internet attackers. These are read by the sniffer program and typically recorded in a file intended to be retrieved later by the attacker. These combinations can then be used to break into the user's account. A solution to this problem is to have these data sent across the Internet in a secure manner, such as by encrypting them first. Currently, an individual user cannot do anything about this, except, as noted above, to change passwords frequently. What is required is for suppliers to provide a more secure procedure for logging in across the network, as discussed in the next section. The two other types of sensitive information traveling across the Internet are sensitive user identifications, and files sensitive to the user. Users should take one of two precautions, either encrypt the information or don't send it across the Internet. Examples of sensitive user identifications are social security number, address, phone number, personal data, and perhaps most sensitive of all, credit card numbers. In general, none of these data should be sent across the Internet unless they are encrypted at the source (prior to being sent across the Internet). An example of a file that would possibly be sensitive to the user is e-mail containing personal information or sensitive business information. If a user wants to ensure this information is kept confidential, then it must either be encrypted, or sent some other way (such as through the U.S. mail). Pretty Good Privacy (PGP) is an e-mail encryption program available on the Internet that can provide encrypted e-mail. 14.2.4. Additional Considerations for Commercial Internet Users - A commercial Internet user may have more security concerns than individual users, because commercial users may have more connections to the Internet, and may have more assets exposed to the Internet. Commercial users should conduct some form of risk analysis to determine the cost effective level of security they should have. 14.2.5. Summary of the Implications for Internet Users - This research shows that Internet users are not likely to be the victim of an Internet attack. They should, however, take reasonable precautions to protect the files on their computers, and to protect data as it transits the Internet. For each user of the Internet, the reasonable level of precautions may be different, and it depends on that user's needs. All Internet users should take the following basic security precautions: 1. Back up important files. 2. Use a good password for network access controls. 3. Ensure permissions are set properly on files that can be accessed by others. 4. Encrypt, or store off-line, files that are particularly sensitive. 5. Do not send sensitive user identifications, such as a social security number, address, phone number, personal data, or credit card number across the Internet unless it is encrypted at the source (prior to being sent across the Internet). 6. Use an encryption program, such as Pretty Good Privacy (PGP), if you want e-mail to be private. An additional recommendation for commercial Internet users is as follows: 7. Conduct some form of risk analysis to determine the cost effective level of security. There was no indication in this research that these simple precautions would not be effective in preventing most Internet attacks. 14.3. Implications for Internet Suppliers Internet suppliers include both commercial vendors that supply hardware and software used to access the Internet, and organizations such as the Internet Society and its member organizations that help establish standards for Internet protocols. As noted in the previous sections, this research gave no indication that simple precautions would not be effective in preventing most Internet security problems. Suppliers of Internet products should ensure their protocols and products conveniently provide Internet users with capability to take these simple precautions as described it the previous section. The CERT®/CC incident records clearly indicate specific problem areas with respect to Internet security that should be corrected by Internet suppliers. These problems are as follows: 14.3.1. Password Problems - Two significant problems related to passwords were indicated in the CERT®/CC records. First, user name, password and IP address combinations are sometimes sent in the clear across the Internet. Packet sniffers may be used by Internet attackers to read these combinations. Internet suppliers should provide protocols and software that encrypt these data at the source, or provide alternative systems that do not require passwords to be sent in the clear across the Internet. The second password problem that continues to be a concern is access to password files for password cracking. CERT®/CC records shows that, though this problem was declining among severe incidents, it continued to be a problem for smaller incidents. Internet suppliers should provide protocols and software that prevent access to files of encrypted passwords, or provide an alternative system that does not require encrypted passwords to be stored in files on systems accessible across the Internet. 14.3.2. Shipping Software in an Insecure State - There are repeated examples, in the CERT®/CC records, of Internet attacks that successfully took advantage of software that was shipped to users in an insecure state. This includes default passwords for system accounts, default permissions on files, and a default trusted-host configuration. Suppliers of systems should discontinue this practice. Software should always be shipped in a secure state. 14.3.3. Additional Actions Suppliers Should Take - The CERT®/CC records for the period of this research showed that denial-of-service attacks were a small problem. However, the rate of growth of these incidents was greater than the rate of growth of Internet hosts. In addition, other than the small number of incidents, there was no indication that users on networks and hosts connected to the Internet could successfully prevent denial-of-service attacks. This is an area where further investigation is warranted. Internet suppliers should develop protocols and programs with reasonable protections against denial-of-service attacks. An additional area that Internet suppliers should investigate is user privacy. Development of protocols and programs that provide reasonable privacy for such user programs as e-mail should be accelerated to provide this capability in the near term. 14.3.4. Summary of Implications for Suppliers - CERT®/CC incident records clearly indicate specific problem areas with respect to Internet security that should be corrected by Internet suppliers. The recommended corrections are as follows:
14.4. Implications for the Government This research has shown that there are security problems on the Internet. But just the existence of problems does not necessarily justify government intervention. If the free market provides the necessary solutions, then government intervention is not required, or desirable. In fact, in some circumstances, government intervention may make matters worse. Although information about the actual state of Internet security has been limited, the government already intervenes in four ways. First, the government provides incident response through funding of the CERT®/CC and other agencies in the Department of Defense (DoD), such as AFCERT, ASSIST, DISA, and NAVCIRT (see Chapter 3). Second, through the CERT®/CC, other response teams, and other agencies, such as the National Institute of Standards and Technology (NIST), and the National Security Agency (NSA), the government controls information related to Internet security. Third, the government affects Internet security through the rules and regulations of such agencies as NIST, NSA and DoD. And finally, the government influences research and development through funding and participation in such organizations as the Internet Society. With improved information about the state of Internet security, we may be able determine whether these interventions have been effective. Potentially, we could also determine to what extent, and in what areas, government programs and policies should be changed to improve the security of the Internet. Trends over time could possibly be used to determine the effectiveness of current and future policies and resources. Most of the current government interventions concern providing or controlling information. This is the most common and basic method of government intervention. The next section presents the theoretical justification for government intervention in providing information to the Internet community. This is followed by a discussion of what government policies should be, based on the results of this research. 14.4.1. The Government's Role in Providing Information - The key insight into the operation of free markets is attributed to Adam Smith, the author of the Wealth of Nations. He postulated that "if an exchange between two parties is voluntary, it will not take place unless both believe they will benefit from it [Fri78:13]." The "belief" of the parties that leads to a voluntary transaction between them is based on their information about the transaction. The primary signaling mechanism providing information in such free market transactions is the price system. Prices send information between customers and suppliers about the value of goods and services. If there is unhindered flow of information to both customers and suppliers, then this price mechanism helps enable efficient market outcomes. However, if customers and suppliers do not have the same information about prices, quality, and other aspects of goods and services, the result may be an inefficient outcome -- a market failure -- due to asymmetric information [McB96:611]. For the price system to perform its signaling function perfectly, information must be costlessly shared among all individuals . . . Obviously, perfection is rarely achieved. The critical issue will be how consequential the asymmetries in information are [StZ78:298]. The market for computer security, just like other markets, is based on the flow of information about suppliers, customers, products and services. The sources of information include customers and suppliers, but also other organizations which have information about computer security. These other organizations include the press, educational institutions, governmental organizations, sites on the World Wide Web, and attackers. If there are consequential differences in information available to suppliers and customers, the market can become inefficient. An example might be if suppliers are aware of security problems in hardware and software, but customers are not, then customers may purchase more insecure products than they would if they had known of the security problems. In summary, if information is not shared costlessly among all prospective participants in a market, then the market will have asymmetries of information that may lead to inefficient outcomes [StZ78:321]. Under this condition, the government may be required to intervene. 14.4.2. Government Information Policies and the Computer Security Market - During the history of the Internet, the government has maintained a very high level of confidentiality regarding Internet security. This policy has been controversial, because it has resulted in an asymmetry of information, where information about security incidents and vulnerabilities may be known by attackers, suppliers, government agencies, and response personnel significantly better than it is known by the average user of the Internet. It is possible that users would make different purchasing decisions if they had more information about Internet security problems and incidents. It is also possible that suppliers would offer products and services with greater security if more information was available, particularly to their ultimate customers, Internet users. On the other hand, this high level of confidentiality may have several beneficial effects. First, it may protect individual sites from adverse publicity that may result if security problems or incidents at that site were made public. Second, it may protect individual sites from further attacks. This is because, as the CERT®/CC records show, attackers spread information about site insecurities, which may then be used by other attackers. Withholding information may help prevent this. Third, withholding information may result in attackers having more difficulties finding insecurities to exploit. Finally, and perhaps most importantly, strict rules of confidentiality may result in more reports of incidents being given to government agencies, such as the CERT®/CC. The net benefit of the effects resulting from the government's confidentiality policy is difficult to determine and the subject of debate. Some view the government policies as too restrictive because they leave attackers more informed than users and site administrators [ShM96:116]. Others, such as CERT®/CC personnel, maintain that stricter confidentiality results in more security. The issue of what information should be released to the public is discussed in Section 14.4.4. 14.4.3. Funding of Incident Response Supported by This Research - This research does not provide any conclusive evidence that current government interventions in support of Internet security should be changed in any significant way. On the other hand, this research shows the value of obtaining more information about Internet activity, of promoting Internet security, and of funding incident response teams, particularly the CERT®/CC. As stated before, information about Internet security activity provides information for the setting of national policy. Problems that arise can be targeted for policies and programs. Without information, this simply cannot be done properly. Funding of incident response teams, particularly the CERT®/CC, was shown to be important by this research. As this research has shown, most of the significant security activity gets reported to the CERT®/CC. In addition, the CERT®/CC is the single point where information about Internet security incidents is gathered. Because of these reasons, the CERT®/CC, and to a lessor extent, other response teams, act as our "eyes" to see into the Internet security world. This research supports the view that the CERT®/CC is our only real source for comprehensive and timely information on Internet security incidents in four important areas. First, their records show the state of the art in practical Internet intrusion techniques. Many authors present information about what attacks are possible on the Internet, but the CERT®/CC records show what attackers have found actually works. Second, CERT®/CC personnel and their records can provide information about security problems which can focus government actions. Third, these records can be used to determine the result of those actions. And fourth, CERT®/CC response personnel could provide warning of significant security events. They currently provide this to the Internet community through CERT® advisories. They could also, however, provide more detailed information to government intelligence and law enforcement agencies that could focus their attention on developing problems. A recent Defense Science Board (DSB) Report confirmed a national security need for warning of significant Internet events as follows: The essence of tactical warning is monitoring, detection of incidents, and reporting of the incidents. Monitoring and detection of infrastructure disruptions, intrusions, and attacks are also an integral part of the information warfare (defense) process. Providing an effective monitoring and detection capability will require some policy initiatives, some legal clarification, and an ambitious research and development program . . . . All intrusions and incidents should be reported so that patterns of activity can be established to aid in strategic indications and warning. The FCC requirement to report telephone outages of specified duration affecting more than a specified number of customers serves as a model in this regard [DSB96:55] This research shows that requiring the reporting of all intrusions and incidents may not be necessary because most significant incidents are already reported. For the CERT®/CC to be effective in providing tactical warning, however, the information they provide will have to be accurate and timely. Two additional recommendations of the DSB are to: 9b. Develop techniques and tools for modeling, monitoring, and management of large-scale distributed/networked systems. 9c. Develop tools and techniques for automated detection and analysis of localized or coordinated large-scale attacks [DSB96:16]. These are additional capabilities that can be provided by the CERT®/CC and, to a lessor extent, by other response teams (see Chapter 3 for a list of other response teams). The DSB recommends the establishment of two centers for Information Warfare - Defense (IW-D). They recommend the first be located at the National Security Agency (NSA), with Central Intelligence Agency (CIA) and Defense Intelligence Agency (DIA) support. This center would provide strategic indications and warning, current intelligence and threat assessments [DSB96:12]: There may, in fact, be a need to form a National Center for Indications and Warning. This center would gather and analyze monitoring data continuously. The data would be derived from commercial infrastructure systems as well as government. The center could be charged with searching for and detecting early signs and precursors of a wide scale, coordinated attack and with providing warnings to U.S. government and private sector organizations [DSB96:63]. The second center would be located at the Defense Information Systems Agency (DISA), with National Communications System (NCS), NSA and DIA support. This second center would provide tactical indications and warning [DSB96:13]. It is unlikely an operations center at DISA or NSA would receive much timely information directly from the Internet community. This is because most of the Internet is not within the area of control or responsibility of the DoD or NSA. In addition, monitoring of Internet activity within the U.S. may be completely outside the responsibility and authority of the DoD and NSA. As such, either this responsibility should be given to the CERT®/CC (or similar organization), or these operations centers should establish strong and timely liaison with the CERT®/CC and, to a lessor extent, other response teams. In summary, because there is this growing need for information on Internet security incidents, and because the CERT®/CC is our only real source for comprehensive and timely information on Internet security incidents, this research supports continued funding of the CERT®/CC. More specifically, the research supports increased funding for the CERT®/CC, because of its capability to provide timely strategic and tactical indications and warning, and because of the increase in total Internet security activity. 14.4.4. Other Government Policies Supported by This Research - This research supports government policies in two additional areas. First, the government should encourage Internet users to take the security precautions summarized in Section 14.2.5. Internet suppliers should also be encouraged to improve Internet security through the steps summarized in Section 14.3.4. Second, this research shows that the government should take reasonable precautions to protect government data (just as other users). In addition, some government data is too sensitive to be available on the Internet, unless special precautions are taken. Stated another way, government employees should be required to take the same reasonable security precautions as other Internet users (summarized in Section 14.2.5). 14.5. Implications for Response Teams The business of Internet incident response teams is information. They gather information relevant to Internet security, study that information, and selectively release information to the Internet community. This section presents an analysis of response team information policies based on theory and experience with this research. This analysis specifically examines the confidentiality policy of the CERT®/CC, but it is also generally applicable to other response teams. It begins with a discussion of the objectives of incident response, examines alternatives, and recommends changes to information release policies. 14.5.1. Objectives of Incident Response - As discussed in Chapter 3, the CERT®/CC, and other response teams, provide products and services to the Internet in three areas: operations, education and training, and research and development. These are information producing activities in keeping with the three aspects of the CERT®/CC's charter, which is stated as follows (repeated from Chapter 3): The CERT® charter is to work with the Internet community to facilitate its response to computer security events involving Internet hosts, to take proactive steps to raise the community's awareness of computer security issues, and to conduct research targeted at improving the security of existing systems [CER96:1]. The underlying motivation for the CERT®/CC charter, and the charter of other response teams, is to improve the security of the Internet. That is also the first objective of this research - to provide the suppliers and customers in the Internet community with more information about the history of Internet security incidents, security of Internet-related products and services will improve. Other objectives are also important. These objectives can be summed up as follows: Objective #1 - Improve the security of Internet products and services Objective #2 - Protect Internet sites from adverse publicity Objective #3 - Protect Internet sites from attacks Objective #4 - Gather information about Internet security problems and incidents These are conflicting objectives. For example, if our only objective was the first one, to improve the security of Internet products and services, we would consider a policy of full disclosure of all incident response information. The intention would be to put pressure on Internet suppliers to improve the security of their products and services. This would likely, however, also result in undesirable outcomes, such as adverse publicity for sites identified, an increase in attacks at sites identified as being vulnerable, and increased reluctance to report vulnerabilities and incidents. Other conflicts emerge if different objective are emphasized. Maintaining sources of information clearly has to be the most important of these objectives. If incident response personnel lose their sources of information, then they will have no information to use to improve Internet products and security, and to protect Internet sites from attack, except what information they can generate themselves. These objectives will be used to value the alternative courses of action discussed in the next section in order to develop recommendations. 14.5.2. Possible Alternative Courses of Action - Providing information is a common approach used by the government to improve the working of a market [StZ78:310], as discussed in Section 14.4.1. As discussed, operation of the CERT®/CC is one measure the government is already taking to improve the operation of the Internet market by supplying information. The following analysis determined whether the amount and form of the information released by the CERT®/CC should be increased. The information kept confidential by the CERT®/CC generally falls into three categories which will be treated as being mutually exclusive: site names, incident activity, and vulnerabilities. In the following sections, alternative courses of action will be presented in each of these categories. After a description of each alternative, predictions will be given of possible outcomes from the adoption of each alternative. 14.5.2.1. Disclosure of Site Names - Throughout the CERT®/CC records, actual site names were recorded. These included sites that reported incidents, other sites that were involved incidents but that were not aware of or did not report such involvement, and sites that were involved in incident response. Of course, the simple revealing of a site name is not sensitive. The Internet Domain Name System (DNS) generally makes site names publicly available. The specific restricted information is the association of a site name with either a vulnerability or with an incident. CERT®/CC policy has been for there to be no association of site names with vulnerabilities or incidents. Not only did this mean that no site name associations were publicly released, but that site names were not revealed to other sites involved in the same incidents, unless a site specifically authorized the disclosure. Possible alternatives to this policy are as follows: 14.5.2.1.1. Alternative 1.1 - Full Disclosure of Site Names - adoption of this alternative would eliminate all restrictions on the disclosure of site names. How this might actually be accomplished is open to speculation. One possibility would be to periodically release lists of sites with known vulnerabilities, and sites involved in known incidents. The primary reason to adopt such an approach would be to put pressure on site administrators and Internet suppliers to improve site security and to improve the security of products and services. It is likely that system administrators of sites on the Internet would react to adverse publicity by securing their sites. This may be particularly true with sites that were vulnerable, but had not yet been attacked. This is because the public disclosure of the vulnerability may lead to attacks, since attackers would now have the information. Other things being equal, these attacks (or the potential for them) may pressure site administrators and, in turn, Internet suppliers. This may result in Internet suppliers providing products and services with improved security. It is unlikely, however, that "other things" would be equal. Sites are very reluctant to reveal vulnerabilities or their involvement in incidents. Evidence of this can be seen in the very small number of incidents on the Internet that have been publicly reported. If sites were willing to be publicly identified, more information would have been publicly released. Under this policy, however, reporting vulnerabilities or incidents to a response team would be essentially equivalent to releasing the information publicly, since that is what the response team would do. The likely result of this policy would, therefore, be a reduction in information reported to response teams, and because of that, there would likely be little information for response teams to release publicly. The final problem with this alternative would be the real possibility of response teams being held responsible for damage that resulted from attacks following disclosure of site information, unless there were special laws that protected the response teams from such liability. In summary, the primary result of full disclosure of site names with known vulnerabilities and known incidents would be a reduction in the information available to the response teams. Those sites that were publicly identified, however, would be more likely to take increased security precautions. The larger effect would logically be the first because, if a response team has little information reported to it, then there will be few sites that are publicly reported. In other words, since response teams rely on voluntary disclosure from sites, the benefits of full disclosure would likely be overwhelmed by the cost due to the loss of information. 14.5.2.1.2. Alternative 1.2 - Partial Disclosure of Site Names - An alternative to full disclosure of site names would be to disclose only some site names. Using this proposal, response teams could establish, for example, that site names would not be reported unless the sites did not correct known vulnerabilities, take steps to secure their sites, or cooperate in incident response. This would provide sites an incentive to take timely corrective actions in order to avoid publicity. Liability problems for response teams would be reduced, as well as the amount of attacks that would result from the public disclosure. Other things being equal, this would result in greater security. The incentives for quick action by site administrators would, perhaps, be less than if Alternative 1.1 were chosen, because there would be less adverse publicity. This proposal, however, also suffers from the same problem that the first proposal does: there would be less information flowing to response teams because of the threat of disclosure. The benefits of partial disclosure would likely be overwhelmed by the loss of information. 14.5.2.1.3. Alternative 1.3 - Delayed Disclosure of Site Names - A second alternative to full disclosure of site names would be to disclose site names only after some period of time. After that period of time, either all site names would be disclosed, or only some subset. For example, response teams could establish that site names would not be reported unless the sites did not correct known vulnerabilities, take steps to secure their sites, or cooperate in incident response. This would provide sites the incentive to correct vulnerabilities and secure sites in a timely manner. Again, other things being equal, this may result in greater security. As with Alternative 1.2, the incentives for quick action by site administrators may be less because there would be less adverse publicity. On the other hand, this may be partially offset by the incentive to move quickly. This proposal, however, also suffers from the same problem that the first two proposals do: there may be reduced information flowing to response teams because of the threat of disclosure. The benefits of delayed disclosure would likely be overwhelmed by the cost due to the loss of information. 14.5.2.1.4. Alternative 1.4 - No Disclosure of Site Names - The fourth alternative is disclosure of site names only with specific authorization from the sites involved. The disclosures would only be to other sites involved in incidents. There would be no disclosure of sites with known vulnerabilities. This alternative represents the status quo. This alternative should provide sites the least problems with reporting. If strictly adhered to, these confidentiality requirements should minimize concerns about adverse publicity and the possibilities for continued or increased attacks. Response teams could maximize the information they receive, although there would be less pressure on sites to increase security (other things being equal). 14.5.2.1.5. Recommended Alternative for the Disclosure of Site Names - As stated earlier, gathering basic information about Internet security problems and incidents (objective #4) is key to fulfilling the charter of the CERT®/CC and other response teams. Alternative 1.4 should provide the most information to response teams. In addition, because of the loss of information, it is unclear that any of the other alternatives would result in increased security. They would also expose sites to adverse publicity and the potential for increased attacks. Therefore, it is recommended that there be no disclosure of sites names that appear in response team records or are otherwise reported to response teams (the status quo). 14.5.2.2. Disclosure of Incident Activity - This research has involved the disclosure of incident activity during the period from the formation of the CERT®/CC in 1988 to the end of 1995. The records themselves, however, were not disclosed, but rather a summary of data extracted from the incident records, along with a classification and analysis of these data. This is the first time such data have been released by the CERT®/CC or any other response team. This in itself was a change in policy. In the past, the CERT®/CC has generally released no information about actual incidents, except to the sites involved. Even when this information was released to these sites, it was limited only to information of concern specifically to that one site. Among the participants, only incident response teams were generally able to see the actual scope of the incidents. The exception to this was twelve CERT® advisories which give some information about specific incidents. The possible alternatives to this policy of limited disclosure of incident activity are discussed below. Disclosure of site names was treated as a separate issue in the previous section. As such, each of the alternatives below assumes that whatever material is released, it will not contain site names. The possible alternatives are as follows: 14.5.2.2.1. Alternative 2.1 - Disclosure of Incident Summaries - As described in Chapter 4, incidents reported to the CERT®/CC were tracked in summary files kept on-line at the CERT®/CC. Once a week, closed incident records were removed from the on-line file and archived, and a copy of all open summaries was archived in a separate file. A similar process is probably used by other response teams. Adoption of this alternative would involve the releasing of these summaries on a periodic basis, perhaps weekly as they are archived. All of these files, however, would have to have all site names removed. Experience with the files for this research showed that removing most of these site names is relatively easy, but completely removing references to site names is a difficult process. This is because the site names are not always accurately recorded, and they can be embedded anywhere in the records. Assuming the files could be sanitized of site information on a regular basis, this research has also shown that the files would be of limited use. In order to determine the extent of an incident, other CERT®/CC files had to be searched for relationships. This same process would have to be done to form incidents out of the summary files if they were publicly released (the same process may have to be done with the records of other response teams). This entire process makes this alternative impractical and of limited value. Any imperfections in removing the site names could also result in problems with liability and with sites becoming reluctant to provide information to response teams. 14.5.2.2.2. Alternative 2.2 - Creation and Disclosure of Incident Files - A second alternative would be for response personnel to combine summaries together to form the incidents, as was done for the incidents studied in this research. This would eliminate the need for others to piece together the incidents. Instead, this would be done by personnel who have the most knowledge about an incident and would, therefore, be able to accomplish this task. While this would be an improvement over the first alternative, it would also have similar problems. Site names would have to be eliminated from the files to be released, and any imperfections in removing the site names could result in problems with liability and with sites becoming reluctant to provide information to response teams. It would likely also have limited value in terms of the objectives for this analysis. This entire process makes this alternative impractical and of limited value. 14.5.2.2.3. Alternative 2.3 - Development and Disclosure of Incident Data based on Incident Summaries - An alternative to the release of summary files would be to follow the data development process of this research further and develop and release data summary files and statistics. Response personnel would group the summary files together into incidents, extract data from these incidents (see Section 4.3), eliminate sites names, and then use a classification scheme, such as the taxonomy developed for this research, to classify, analyze and summarize these data. The files of extracted data as well as the data analysis would be released to the public. There are two primary advantages to this alternative. Incident activity data would be released to the public in a useful, summary form and, the elimination of site names would be easier and more accurate. On the other hand, this research has shown this process to be difficult and time consuming. The next alternative addresses this concern. 14.5.2.2.4. Alternative 2.4 - Development and Disclosure of Incident Data based on a Taxonomy - This alternative would involve the release of information that is similar to Alternative 2.3, but the information would be generated in a different manner. By way of background, the research for this dissertation involved the examination and classification of incident records well after the incidents were closed. The information available for the process of constructing incident records, data extraction, and classification was limited to what was written into the summary files. During an incident, however, response personnel generally are more knowledgeable about the characteristics of the incident. More importantly, if information is missing, response personnel could take steps during the incident to acquire that information. For example, if an incident summary shows evidence of an intruder attempting access at a site, but no information about the level of success, response personnel could ask the site for more information about whether the attacks were successful at the root or account level. While response personnel may not always be able to obtain that information, they would be more successful than anyone either not involved in the incident, or attempting to determine this information after the incident was closed. As such, this alternative proposes to have response personnel extract data and classify an incident while the incident is still open. Response personnel could gather data as recommended in Chapter 13. Sites involved would be sanitized, as was done in this research, so that the actual site names are not revealed. Recording of these data should be simple for response personnel, since they should have the information readily available. The use of an agreed-upon classification scheme (taxonomy) would be necessary. A possibility would be to use the taxonomy developed for this research. A better approach, and one advocated here, would be to use this taxonomy on an experimental basis over some period of time, with the intention of making practical improvements to the taxonomy. The goal would be to develop an accepted and simple scheme for data extraction and classification. The files of recorded data, as well as an analysis of these data would be released to the public. This alternative has a positive outcome with respect to all of the objectives identified in Section 14.5.1, with significantly less work required by response personnel than other alternatives. Release of these data would provide more information to suppliers and customers, which may result in improvement in the security of Internet sites, products, and services. Individual sites would be protected from adverse publicity and further attacks. The release of these data may also make sites more likely to report information to response teams, because they would see the value in helping the data response teams release to be more complete and accurate. 14.5.2.2.5. Alternative 2.5 - Limited Disclosure of Incident Activity - The final alternative considered was to make no change in current official policy. Under this alternative, the only incident activity information released would be high-level summary information released in CERT® advisories, and limited information to the sites involved in an incident. In light of the release of the information in this dissertation, it appears that CERT®/CC personnel are in favor of releasing more incident activity information, which achieves more of the objectives than this alternative. 14.5.2.2.6. Recommended Alternative for the Disclosure of Incident Activity - Development and disclosure of incident data based on a taxonomy (Alternative 2.4), has a positive outcome with respect to all of the objectives. It achieves this with less work than other alternatives, and is, therefore, the preferred choice. Under this alternative, response personnel would take steps during the incident to extract data, eliminate site references, and classify the incident using the categories of a taxonomy. The files of recorded data, as well as any analysis of these data, would be released to the public. A suggested approach to implementation would be to first develop and implement a program at the CERT®/CC. This would be followed by development and implementation at other response teams. A suggested schedule is as follows: 1. Methodology development at the CERT®/CC - During this period, CERT®/CC personnel would build on this current research, particularly the taxonomy, to develop a process for data extraction, classification, analysis and public release. 2. Trial implementation at the CERT®/CC - The process for data extraction, classification, analysis and public release should initially be fully implemented at the CERT®/CC for all incidents. During this trial period, CERT®/CC personnel would evaluate the process and the data generated, and implement improvements. 3. Methodology development with other response teams - After the trial period at the CERT®/CC, other FIRST response teams should be brought into the program. CERT®/CC personnel should meet with members of these other response teams and aid in the development of programs for their teams. Processes should also be developed for coordinating, sharing, reconciling, and analyzing information across the teams. 4. Trial implementation at other response teams - Another trial period should follow, this time involving CERT®/CC and other response teams. During this trial period, all teams would evaluate the process and the data generated, and coordinate and implement improvements. 5. Public release and formalization - After the development and trial periods are satisfactorily completed, other response teams, law enforcement agencies, and possibly other groups, should be encouraged to join this data generation and release process. The end result of such an implementation would be the release of information that response teams, law enforcement agencies, analysts, policy makers, customers, and suppliers could use to improve the security of the Internet. For example, one possible use for a policy maker would be to see the results of policy changes. In this case, a policy change could be implemented and then the results could be tracked in the incident activity data. 14.5.2.3. Disclosure of Vulnerabilities - The disclosure of vulnerabilities is the most controversial of the three areas of information that might be released by response teams. There is general agreement that site names should not be released, and there should be general agreement on the release of more information about incident activity. Disclosure of vulnerabilities is more difficult to agree on. If both the existence and the technical details of all vulnerabilities were fully disclosed, this would undoubtedly result in suppliers making a greater effort to secure their products. This would be because more attackers would probably be exploiting these vulnerabilities. As to whether this would lead to more or less security is unclear (and hotly debated). There is certainly an asymmetry of information between attackers, response personnel, suppliers and customers when it comes to vulnerabilities. But just the existence of an asymmetry does not mean that policies should be implemented to change that asymmetry. A policy change could end up being detrimental to Internet security. One possible alternative would be to have a layered and timed disclosure of vulnerabilities. In this case, only suppliers and others who could "repair" vulnerabilities would initially have full disclosure to them. After a "work-around" or patch were available, partial disclosure would be given to sites so their vulnerabilities could be eliminated. After some period of time, full disclosure would be made to put pressure on sites and suppliers to repair their vulnerabilities and to supply more secure products and services. This research did not provide more information or greater insight into the possible disclosure of vulnerabilities. The research was of incident activity and not specifically vulnerabilities. These data could potentially be used for such studies, particularly if it were more complete (such as would be the case if Alternative 2.4 were implemented). For example, this research did not compare the disclosure of a vulnerability compared to its exploitation in Internet incidents (research recommended in Chapter 15). As such, it is recommended that response teams reexamine their policies toward the release of vulnerability information with the objective of seeing the degree to which more disclosure would benefit the Internet community. 14.5.3. Other Implications for Response Teams - As was shown by this research, response teams get information on only part of the incidents that take place on the Internet. Total Internet activity can be estimated in several ways as discussed in Chapter 12. These estimates can be improved through a program involving voluntary reporting of incident activity at selected Internet sites as recommended in Section 12.3.2. Response personnel should also evaluate the taxonomy for computer and network attacks developed for this research as discussed in Chapter 13. 14.6. Implications for the CERT®/CC Previous sections and chapters have discussed several recommendations for actions by the CERT®/CC. These recommendations are summarized in this section. One recommendation that has not been discussed previously is for the CERT®/CC to publicly release the summary data set from this research. The data set developed for this research yielded valuable information about the state of Internet security. The analysis presented in this dissertation, however, is only a small part of what could potentially be done with the data. This is discussed further in Chapter 15. In order to allow other researchers to use these data, it is recommended that the CERT®/CC make this data set available on line at www.cert.org. A summary of the recommendations for the CERT®/CC from this research is as follows: 1. Maintain only one internal incident summary for each incident, open or closed. 2. Record a standard set of keywords and phrases that are defined, systematic and consistent, in each summary, such as reporting date, starting date, ending date, number of reporting sites, reporting sites, number of other sites, other sites, number of messages, attackers, tools, vulnerabilities, level, results, objectives, and corrective actions. 3. Classify each incident according to the worst level of unauthorized access or use. 4. Post the data set used in this research on line at www.cert.org. 5. Evaluate the taxonomy for computer and network attacks. 6. Develop and implement a program to better estimate total Internet incident activity. Such a program should involve the voluntary reporting of all incident activity at representative Internet sites. This program should include coordination and/or participation from other response teams and related organizations, such as DISA and AFIWC. 7. Estimate average number of attackers per incident, and their typical activity, in cooperation with personnel from DISA, AFIWC, and other response teams, in order to improve estimates of total Internet incident activity. 8. Do not disclose sites names that appear in the CERT®/CC records or are otherwise reported to the CERT®/CC (this is the status quo). 9. Disclose incident data based on a taxonomy. Suggested steps are as follows: 1. Methodology development at the CERT®/CC 2. Trial implementation at the CERT®/CC 3. Methodology development with other response teams 4. Trial implementation at other response teams 5. Public release and formalization 10. Reexamine policies toward the release of vulnerability information with the objective of seeing the degree to which more disclosure would benefit the Internet community. 14.7. Summary of Policy Implications and Recommendations This research clearly shows that the state of Internet security is not as bad as some authors have proposed. Both in terms of the absolute numbers of incidents, and in the growth of these incidents, the numbers are lower than popularly thought. In addition, most attacks were in the category of a nuisance (although some were a big nuisance), and not something more destructive or harmful. Internet security incidents were, however, clearly not dropping to zero. The growth of Internet incidents in absolute terms was nearly at the same pace as the growth of the Internet. Table 14.3 shows that, according to estimates from this research, a typical Internet domain is involved in no more than around one incident per year. In terms of hosts, the estimates of Table 14.3 show that a typical Internet host is involved in no more than around one incident in every 45 years. At the same time, however, it should be noted that some sites and hosts are more attractive to attack and may be involved in many incidents each year.
Given this steady but relatively small level of Internet security incidents, the average Internet user is not likely to be the victim of an Internet attack. Internet users should, however, take reasonable precautions to protect their files and data in transits on the Internet. Recommendations for all Internet users are as follows: 1. Back up important files. 2. Use a good password for network access controls. 3. Ensure permissions are set properly on files that can be accessed by others. 4. Encrypt, or store off-line, files that are particularly sensitive. 5. Do not send sensitive user identifications, such as a social security number, address, phone number, personal data, or credit card number across the Internet unless it is encrypted at the source (prior to being sent across the Internet). 6. Use an encryption program, such as Pretty Good Privacy (PGP), if you want e-mail to be private. An additional recommendation for commercial Internet users is as follows: 7. Conduct some form of risk analysis to determine the cost effective level of security. Recommendations for Internet suppliers are as follows:
Recommendations for the U.S. government are as follows: 1. Increase funding for incident response, particularly the CERT®/CC. 2. Encourage Internet users to take simple security precautions. 3. Encourage Internet suppliers to improve Internet security. 4. Require government employees to take reasonable security precautions to protect sensitive data. Recommendations for Internet response teams are as follows: 1. Do not disclose sites names reported to response teams (the status quo). 2. Disclose incident data based on a taxonomy. 3. Reexamine policies on the release of vulnerability information with the objective of seeing the degree to which more disclosure would benefit the Internet community. 4. Evaluate the taxonomy for computer and network attacks developed for this research. Recommendations for the CERT®/CC are as follows: 1. Maintain only one internal incident summary for each incident, open or closed. 2. Record a standard set of keywords and phrases that are defined, systematic and consistent, in each summary, such as reporting date, starting date, ending date, number of reporting sites, reporting sites, number of other sites, other sites, number of messages, attackers, tools, vulnerabilities, level, results, objectives, and corrective actions. 3. Classify each incident according to the worst level of unauthorized access or use. 4. Post the data set used in this research on line at www.cert.org. 5. Evaluate the taxonomy for computer and network attacks developed for this research. 6. Develop and implement a program to better estimate total Internet incident activity. Such a program should involve the voluntary reporting of all incident activity at representative Internet sites. This program should include coordination and/or participation from other response teams and related organizations, such as DISA and AFIWC. 7. Estimate average number of attackers per incident, and their typical activity, in cooperation with personnel from DISA, AFIWC, and other response teams, in order to improve estimates of total Internet incident activity. 8. Do not disclose sites names that appear in the CERT®/CC records or are otherwise reported to the CERT®/CC (this is the status quo). 9. Disclose incident data based on a taxonomy. Suggested steps are as follows: 1. Methodology development at the CERT®/CC 2. Trial implementation at the CERT®/CC 3. Methodology development with other response teams 4. Trial implementation at other response teams 5. Public release and formalization
10. Reexamine policies toward the release
of vulnerability information with the objective of seeing the
degree to which more disclosure would benefit the Internet community.
 [14]
 |
