8
Category 5—Illustrative Crosscutting Problem-Focused Research Areas

While Chapters 4, 5, 6, and 7 address specific focus areas, this chapter presents a number of problems whose solutions will involve research described in all of those chapters.

8.1
SECURITY FOR LEGACY SYSTEMS

Organizations make large investments in making systems work properly for their business needs. If system deployment is complex or widespread, many organizations are highly reluctant to move to systems based on newer or more current technologies because of the (often quite considerable) work that would inevitably be required to get the new systems to work as well as the older systems worked. However, because legacy systems—by definition—embody design and architectural decisions made before the emergence of the current threat environment, they pose special challenges for security. That is, when new and unanticipated threats emerge, legacy systems must be retrofitted to improve security—and this is true even when careful design and attention to security have reduced the number of potential security vulnerabilities in the original legacy system.

In this context, the challenge is to add security without making existing software products, information assets, and hardware devices any more obsolete than is necessary. Research to support this goal has three components:



The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 181
Toward a Safer and More Secure Cyberspace 8 Category 5—Illustrative Crosscutting Problem-Focused Research Areas While Chapters 4, 5, 6, and 7 address specific focus areas, this chapter presents a number of problems whose solutions will involve research described in all of those chapters. 8.1 SECURITY FOR LEGACY SYSTEMS Organizations make large investments in making systems work properly for their business needs. If system deployment is complex or widespread, many organizations are highly reluctant to move to systems based on newer or more current technologies because of the (often quite considerable) work that would inevitably be required to get the new systems to work as well as the older systems worked. However, because legacy systems—by definition—embody design and architectural decisions made before the emergence of the current threat environment, they pose special challenges for security. That is, when new and unanticipated threats emerge, legacy systems must be retrofitted to improve security—and this is true even when careful design and attention to security have reduced the number of potential security vulnerabilities in the original legacy system. In this context, the challenge is to add security without making existing software products, information assets, and hardware devices any more obsolete than is necessary. Research to support this goal has three components:

OCR for page 181
Toward a Safer and More Secure Cyberspace Research is needed to address the relatively immediate security needs of legacy systems, as these systems will be with us for a long time to come. It is worthwhile to expend some significant effort to create new systems and networks that are explicitly designed to be secure, at least for critical systems whose compromise would have high consequences. Research on clean-slate designs for secure and attack-resilient architectures will show what can be achieved when these efforts are relieved of the need to fit into an insecure existing framework, and it may be that new design approaches will make it possible to achieve performance, cost, and security goals simultaneously. Research effort should be explicitly focused on easing the transition path for users of today’s information technology applications to migrate to secure-by-design systems in the future—a path that is likely to take years or decades to accomplish even after such “from-the-start secure” systems are designed and initially deployed. (Box 8.1 presents further discussion of this point.) One key issue in the security of legacy systems is patch management. Tinkering with existing legacy systems—for whatever reason—can result in severe operational problems that take a great deal of time and effort to resolve, but fixing security problems almost always requires tinkering. Therefore, operational managers are often faced with choosing between the risk of installing a fix to some vulnerability (that is, the installation of the patch may disrupt operations or even introduce a new vulnerability) and the risk of not installing it (that is, attackers might be able to exploit the vulnerability). Further, the installation of a patch generally necessitates a set of new tests to ensure both that the vulnerability has been repaired and that critical operational functionality has not been lost. If it has been lost, a new cycle of patch-and-test is needed. These cycles are both costly and inherently time-consuming, and consequently many systems managers avoid them if at all possible. Such dilemmas are exacerbated by the fact that it is often the very release of a fix that prompts an attack.1 One area of research thus suggested is the development of a methodology that will help operational managers decide how to resolve this dilemma. 1 This paradoxical situation results from the fact that the release of a fix is publicized so that it can be disseminated as widely as possible. The publicity about the fix can alert would-be attackers to the existence of the vulnerability in the first place, and the fix itself can usually be “disassembled” in order to reveal the nature of the original vulnerability. Because some installations will not install the fix, would-be attackers gain opportunities that would not otherwise become available.

OCR for page 181
Toward a Safer and More Secure Cyberspace BOX 8.1 Issues in System Migration One important dimension of security for legacy systems involves strategies for migrating to systems that are more inherently secure. In this context, it is often the case that a migration strategy needs only to preserve existing assets. For example, a user may have a large investment in data files of a given format that are required for a given version of a program. A new version that is more inherently secure may well require files of a different format. One strategy to preserve assets may be to require the new version to open all files in the old format. A different strategy may call for a conversion utility to convert old files to the new format. The first strategy might be deemed a requirement for backward compatibility—that is, the new system should operate as the old one did in a manner that is as transparent as possible to the user. But all too often, the requirement for full backward compatibility complicates the security problem—backward compatibility may, explicitly or implicitly, call for building in the same security vulnerabilities in an attempt to preserve the same functional behavior. (For example, a large fraction of the Windows XP system code base is included for backward compatibility with Windows 98 and Windows 2000—a fact that is well recognized as being responsible for many vulnerabilities in XP.) In the second approach, the migration to a more secure system is made easier by the weaker requirement that only the data assets of the earlier generation be preserved (or made usable) for the new system. The duplication of all functional behavior is explicitly not a requirement for this approach, although it remains a significant intellectual challenge to determine what functional behavior must and must not carry over to the new system. Another fact about system migration is that with distributed systems in place, it is very difficult, from both a cost and a deployment standpoint, to replace all the legacy equipment at once. This means that for practical purposes, an organization may well be operating with a heterogeneous information technology environment—which means that the parts that have not been replaced are likely still vulnerable, and their interconnection to the parts that have been replaced may make even the new components vulnerable. The result of this tension is often that no meaningful action for security improvement takes place. A second area of research relevant to the security of legacy systems is that of program understanding. Program-understanding tools are essential for addressing security issues that arise in legacy systems for which documentation is poor and original expertise is scarce. The reason is that legacy systems continue to play essential operational roles long after their technological foundations are obsolete and after the departure of the individuals who best understand the systems. But as new security issues arise in these legacy systems, a detailed understanding of their internal operation and of how actual system behavior differs from intended behavior is necessary in order to address these issues. Tools that help new analysts

OCR for page 181
Toward a Safer and More Secure Cyberspace understand flows of control and data can facilitate such understanding and the “reverse-engineering” of legacy systems. 8.2 THE ROLE OF SECRECY IN CYBERDEFENSE Should the inner operations of security mechanisms be kept secret or not? It is widely assumed in much of the unclassified research community— especially the community associated with open-source software—that the correct answer to this question is “No.” This answer is based on the idea that secrecy prevents the security community from examining the mechanism in question and in so doing eliminates the opportunity for a rigorous peer review (e.g., finding flaws in results, verifying results independently, and providing [open] building blocks that others can build on [thereby fostering research progress]).2 There is a further belief in this community that a weak system can usually be compromised without knowledge of what is purportedly secret.3 In the classified cybersecurity community, the opposite view is much more prominent. In this view, secrecy of mechanism throws up an additional barrier that an adversary must penetrate or circumvent in order to mount a successful attack, but in no event is secrecy the only or even the primary barrier that should be established. Vendors, even of products for civilian use, also have an interest in keeping implementations secret (under existing trade secret law). Both points of view have merit under some circumstances, and a number of researchers have sought to reconcile them. For example, Spafford argued in 1996 that unless an exploit is actually being used in a widespread manner, it is better not to publish details of a flaw, because to do so would result in a much larger risk of exposure.4 This is true even if a fix is available, since the mere availability of a fix does not guarantee—nor even nearly guarantee—that the fix will be installed. Some will not hear of the fix; some will not be able to install it because of certification requirements; some will not have the expertise to install it; some will fear the subsequent breakage of some essential element of system functionality. More recently, Swire has argued that secrecy is most useful to the defense on the first 2 Spafford goes so far as to argue that open-source development is an issue that is orthogonal to security. See http://homes.cerias.purdue.edu/~spaf/openvsclosed.html. 3 A related argument applies to data and history. Whether data and development history are protected by national security classifications or trade secrets, their unavailability to the community at large prevents the community from using that data and history to understand why systems fail or the origins of a particular kind of bug or flaw. 4 Eugene Spafford, “Cost Benefit Analyses and Best Practices,” Practical Unix and Internet Security, Simson Garfinkel and Eugene Spafford (eds.), O’Reilly Press, Cambridge, Mass., 2003.

OCR for page 181
Toward a Safer and More Secure Cyberspace occasion of an attack on a computer system but that it is far less effective if an adversary can probe the defenses repeatedly and learn from those probes.5 The National Research Council itself commented on this tension in 1998 (Box 8.2). Additional research should be done to shed more light on appropriate uses of secrecy in cybersecurity. Presuming that there are some circumstances in which secrecy is an asset to cyberdefense, an additional research question arises: To what extent is it possible to keep any mechanism secret when it is widely deployed? What technological approaches can be used to increase the likelihood that a widely deployed mechanism can be kept secret? 8.3 INSIDER THREATS The majority of cybersecurity research efforts are focused on making it more difficult for “outside” adversaries to compromise information systems. But, as the cases of Robert Hanssen and Aldrich Ames suggest, insiders can pose a considerable security risk as well. Indeed, much of the past 10 to 15 years of U.S. counterintelligence history suggests that the threat to national security emanating from the trusted insider is at least as serious as the threat from the outsider.6 Insiders can be in a position to do more harm to services and resources to which they have authorized access than can outsiders lacking such access; these concerns are particularly important in contexts in which safe operation depends on good decisions being made by systems operators. Insiders can also leverage their authorized access to obtain information to extend their access. The compromised insider presents a more difficult security challenge than that posed by hostile outsiders. The first rule about security is to keep hostile parties away, and the insider, by definition, has bypassed many of the barriers erected to keep him or her away. Moreover, a compromised insider may work with outsiders (e.g., passing along information that identifies weak points in an organization’s cybersecurity posture). Compromised insiders fall into two categories—knowing and unknowing. Knowingly compromised insiders—those that know they are 5 Peter Swire, “A Model for When Disclosure Helps Security: What Is Different About Computer and Network Security?,” Journal on Telecommunications and High Technology Law, Vol. 2, 2004. 6 For this report, the term “insider” is used to denote an individual in an authorized position whose actions can materially affect the operation of the information technology systems and networks associated with critical infrastructure in a negative way. Since not all “insiders” pose a threat, the terms “inappropriately trusted insider” or “compromised insider” are used to mean an insider with the willingness and motivation to act improperly with respect to critical infrastructure. The term “outsider” refers to an individual who is not in the position of an “insider.”

OCR for page 181
Toward a Safer and More Secure Cyberspace BOX 8.2 Secrecy of Design Secrecy of design is often deprecated with the phrase “security through obscurity,” and one often hears arguments that security-critical systems or elements should be developed in an open environment that encourages peer review by the general community. Evidence is readily available about systems that were developed in secret only to be reverse-engineered and to have their details published on the Internet and their flaws pointed out for all to see. But open-source software has often contained security flaws that have remained for years as well.1 The argument for open development rests on certain assumptions, including these: the open community will have individuals with the necessary tools and expertise, they will devote adequate effort to locate vulnerabilities, they will come forth with vulnerabilities that they find, and vulnerabilities, once discovered, can be closed—even after the system is deployed. There are environments, such as military and diplomatic settings, in which these assumptions do not necessarily hold. Groups interested in finding vulnerabilities here will mount long-term and well-funded analysis efforts—efforts that are likely to dwarf those that might be launched by individuals or organizations in the open community. Further, these well-funded groups will take great care to ensure that any vulnerabilities they discover are kept secret, so that they may be exploited (in secret) for as long as possible. Special problems arise when partial public knowledge about the nature of the security mechanisms is necessary, such as when a military security module is designed for integration into commercial off-the-shelf equipment. Residual vulnerabilities are inevitable, and the discovery and publication of even one such vulnerability may, in certain circumstances, render the system defenseless. It is, in general, not sufficient to protect only the exact nature of a vulnerability. The precursor information from which the vulnerability could be readily discovered must also be protected, and that requires an exactness of judgment not often found in group endeavors. When public knowledge of aspects of a military system is required, the acting on behalf of an adversary—are most likely associated with a high-end threat, such as a hostile major nation-state, and their motivations also vary widely and include the desire for recognition for hacking skills, ideological convictions, and monetary incentives. Knowingly compromised insiders may become compromised because of bribery, blackmail, ideological or psychological predisposition, or successful infiltration, among other reasons. By contrast, unknowingly compromised insiders are those that are the victims of manipulation and social engineering. In essence, unknowingly compromised insiders are tricked into using their special knowledge and position to assist an adversary. Regarding the knowingly compromised insider, a substantial body of experience suggests that it ranges from very difficult to impossible to identify with reasonable reliability and precision individuals who will

OCR for page 181
Toward a Safer and More Secure Cyberspace most prudent course is to conduct the entire development process under cover of secrecy. Only after the entire assurance and evaluation process has been completed—and the known residual vulnerabilities identified—should a decision be made about what portions of the system description are safe to release. Any imposition of secrecy, about either part or all of the design, carries two risks: that a residual vulnerability could have been discovered by a friendly peer reviewer in time to be fixed, and that the secret parts of the system will be reverse-engineered and made public, leading to the further discovery, publication, and exploitation of vulnerabilities. The first risk has historically been mitigated by devoting substantial resources to analysis and assurance. (Evaluation efforts that exceed the design effort by an order of magnitude or more are not unheard of in certain environments.) The second risk is addressed with a combination of technology aimed at defeating reverse-engineering and strict procedural controls on the storage, transport, and use of the devices in question. These controls are difficult to impose in a military environment and effectively impossible in a commercial or consumer one. Finally, there is sometimes a tension between security and exploitation that arises in government. Intelligence agencies have a stake in concealing vulnerabilities that they discover in systems that an adversary uses, because disclosure of such a vulnerability may lead the adversary to fix it and thus render it useless for intelligence-gathering purposes. If the vulnerability also affects “friendly” systems, a conflict arises about whether the benefits of exploitation do or do not outweigh the benefits of disclosure.    1See for example, Steve Lodin, Bryn Dole, and Eugene H. Spafford, “Misplaced Trust: Kerberos 4 Random Session Keys,” Proceedings of Internet Society Symposium on Network and Distributed System Security, pp. 60-70, February 1997. SOURCE: Adapted largely from National Research Council, Trust in Cyberspace, National Academy Press, Washington, D.C., 1998. actually take hostile actions on the basis of their profiles or personal histories. (For example, it is often hard to distinguish merely quirky employees from potentially dangerous individuals, and there is considerable anecdotal evidence that some system administrators have connections to the criminal hacker underground.) Thus, the identification of compromised insiders must rely on analyses of past and present behavior.7 (That is, it may be possible to infer intent and future behavior from usage signatures, 7 More precisely, the identification of a compromised insider depends first on identifying behavior or actions that are anomalous or improper, and then on associating an individual with that behavior or those actions. An intrusion-detection system typically flags anomalous behavior, and association of that behavior with an individual depends on higher-level systems issues, such as policies, radio-frequency indentification proximity sensors to autolock machines, authenticated systems logs, and so on.

OCR for page 181
Toward a Safer and More Secure Cyberspace although the consequences of false positives here may be quite high.) In other words, it is highly unlikely that general means for detecting potential spies and saboteurs will be developed; therefore, barriers to particular acts are necessary instead. The knowledge base about how to defend against compromised insiders is not extensive, at least by comparison with the literature on defending against “outsiders.” Still, there is general agreement that a multifaceted defensive strategy is more likely to succeed than is an approach based on any one element. Some of the relevant elements include the following: Technology. Authentication and access control are two well-known technologies that can help to prevent an insider from doing damage. Strong authentication and access controls can be used together to ensure that only authorized individuals gain access to a system or a network and that these authorized individuals have only the set of access privileges to which they are entitled and no more. As noted in Section 6.5, tools to manage and implement access-control policies are an important area of relevant research; with such tools available to and used by systems administrators, the damage that can be caused by someone untrustworthy and unaccountable can be limited, even if he or she has improper access to certain system components. Forensic measures (Section 7.3) and MAD systems (Section 5.2) can also play an important role in deterring the hostile activity of a compromised insider. For example, audit trails can monitor and record access to online files containing sensitive information or execution of certain system functions, and contemporaneous analysis may help to detect hostile activity as it is happening. However, audit trails must be kept for all of the users of a system, and the volume of data generally preclude comprehensive analysis on a routine basis. Thus, automated audit trail analyzers could help to identify suspicious patterns of behavior that may indicate the presence of a compromised insider. In addition, it may be more or less important to audit the records of an individual, depending on the criticality of the resources available to that person; automated tools to decide on appropriate audit targets would be helpful to develop. Note also that maintaining extensive logs may in itself pose a security risk, as they may be used to help re-create otherwise confidential or classified material that is in otherwise restricted data files. For instance, keystroke logs may contain passwords or formulae, and logs of references consulted may be used to reverse-engineer

OCR for page 181
Toward a Safer and More Secure Cyberspace a secret process. Thus, logs may need to be protected to a level as high as (or higher than) anything else on the system. Organizations. In an environment in which most employees are indeed trustworthy, what policies and practices can actually be implemented that will help to cope effectively with the insider threat? Known organizational principles to deal with a lack of trust include separation of duties and mandatory job rotation and vacations, and are often used in the financial industry. Such principles often generate specific technical security requirements that are often not considered explicitly in technical discussions of security. (For example, separation of duties requires that one person not play two roles—a fact that requires that an organization’s security architecture to enforce a single identity for an individual rather than multiple ones.) Research is needed in how to define, describe, manage, and manipulate security policies. Systems can be abused through both bad policy and bad enforcement. Tools are needed to make setting and enforcing policy easier. For example, a particularly useful area of investigation would be to gain a more complete understanding of what sophisticated and successful systems administrators do to protect their systems. Encapsulating that knowledge and codifying it somehow would provide insight into what the best kinds of defense are. Management. Recent movements toward more-open architectures along with more collaboration and teamwork within and across institutions present management challenges. For example, certain information may be intended for distribution on a need-to-know basis, but given a shift toward more-collaborative exercises, determining who needs to know what and constraining the sharing of information to that end is difficult. In both business and government, there has been a significant movement toward embracing cooperation across organizations and sectors, but this, of course, introduces security problems. Legal and ethical issues. Many privacy and workplace surveillance issues need to be addressed when an organization determines how to implement tools to decrease the possibility of insider malfeasance. For example, many anomaly-detection systems require the collection of large amounts of data about the activities of individuals in order to establish a baseline from which deviations might detect anomalous behavior. Both the fact of such collection and how those data are handled have serious privacy implications, from both a legal and an ethical standpoint. One of the most important of these issues is that it is all too easy for an organization to be both very security-aware and

OCR for page 181
Toward a Safer and More Secure Cyberspace employee-unfriendly at the same time. That is, even if draconian security measures are legal (and they may be of questionable legality), the result may be an environment in which employees feel that they are not trusted, with a concomitant lowering of morale and productivity and perhaps higher turnover. For example, an environment in which employees police one another for violations of security practice may breed distrust and unease among colleagues. Conversely, an environment that provides trusted mechanisms for dispute resolution and justice can promote a greater sense of camaraderie. The interplay between employment laws and the need for system security is also a concern. For example, the termination of suspected individuals may not occur immediately, and thus such people may maintain access while the necessary paperwork goes through channels. Research is also needed to understand the circumstances under which an insider threat is (or is not) a concern serious enough to warrant substantial attention. Systems are often designed embedding unrealistic assumptions about insiders. For instance, it is common in networked enterprises to assume that one cannot and should not worry about insider attacks, meaning that nothing is done about insiders who might abuse the network. This approach leaves major security vulnerabilities in new networking paradigms in which individual user devices participate in the routing protocol. But in more traditional networking paradigms, individual user devices do not participate in the routing protocol, and thus this particular security vulnerability is of less concern. As for the unknowingly compromised insider, effective defenses against trickery are very difficult to deploy.8 Adversaries who engage in such trickery are experts at exploiting the willingness of people to be helpful—a process often known as “social engineering.” These adversaries use people to provide inside information, and they use people by taking advantage of situations that cause breakdowns in normal procedures. In short, they help human error to occur. For example, badges are often required for entry into a secure facility, and passwords are required to access the computer network. However, entry and access can often be obtained in the following manner: Walk up to the door carrying an armload of computers, parts, and dangling cords. Ask someone to hold the door open, and thank them. Carry the junk over to an empty cubicle, look for the password and log-in name that will be on 8 This discussion of social engineering is drawn largely from National Research Council, Information Technology for Counterterrorism: Immediate Actions and Future Possibilities, The National Academies Press, Washington, D.C., 2003.

OCR for page 181
Toward a Safer and More Secure Cyberspace a Post-it note somewhere, and log in. If you cannot log in, ask someone for help. As one guide for hackers puts it, just shout, “Does anyone remember the password for this terminal? … you would be surprised how many people will tell you.”9 The reason that social engineering succeeds is that, in general, people (e.g., employees of an organization) want to be helpful. It is important to counter social engineering if cybersecurity is to be achieved, but whatever that entails, the solution must not be based on extinguishing the tendencies of people to be helpful. The reason is that helpful people play a key role in getting any work done at all—and thus the research challenge is to develop effective techniques for countering social engineering that do not require wholesale attacks on tendencies to be helpful. Some of the approaches described above for dealing with the knowingly compromised insider are relevant. For example, compartmentalization or a two-person rule might be useful in combating social engineering. But as a general principle, approaches based on deterrence will not work—simply because deterrence presumes that the party being deterred knows that he or she is taking an action that may result in a penalty, and most people who are trying to be helpful don’t expect to be punished for doing so. 8.4 SECURITY IN NONTRADITIONAL COMPUTING ENVIRONMENTS AND IN THE CONTEXT OF USE As noted in Section 3.4.1.2, cybersecurity research that is situated in the context of use has a greater likelihood of being adopted to solve security problems that occur in that context. This section provides several illustrative examples. 8.4.1 Health Information Technology Health-related information spans a broad range and includes the medical records of individual patients, laboratory tests, the published medical literature, treatment protocols, and drug interactions, as well as financial and billing records and other administrative information. The deficiencies relate to not having the relevant information (even though it may be available somewhere) at the right time and in the right place to support good decision making. The intensive use of information technology (IT) to acquire, manage, analyze, and disseminate health care information holds great potential for reducing or eliminating these information 9 See “The Complete Social Engineering FAQ”; available at http://morehouse.org/hin/blccrwl/hack/soceng.txt.

OCR for page 181
Toward a Safer and More Secure Cyberspace so on) to stay abreast of the health of their resources. However, inevitably one way of detecting a DDOS attack is by getting a call from a user that a given resource or Web site is unavailable. In any case, once detected, there are today several strategies for addressing a DDOS attack: Respond and block. This approach involves detecting and characterizing the attack and ideally gaining some kind of “signature” from the attack that can be shared with others who might be affected. This signature can then be used to filter the malicious network traffic, often by the Internet Service Provider (ISP) rerouting traffic for the victim through a “scrubber” node.19 In practice, if an attack is large enough, ISPs can “blackhole” offending IP addresses or eliminate their routes. That is, the outside path through which the malicious traffic comes can be shut down, thereby keeping at least the targeted service available to local clients. More importantly, this approach avoids collateral damage to other sites downstream of the chokepoint network link. Hide. In this response, a Web site’s true end points are hidden or are set up with very good filters. Traffic is then routed via an overlay network that hides the final destination and spreads the load. An example of this approach has been taken by Keromytis et al. in the design and implementation of Secure Overlay Services.20 Minimize impact. This approach involves simply trying to ride a DDOS attack out, either by adding more bandwidth or by using a content distribution network (e.g., Akamai) to lessen the load on a Web site’s resources (Box 8.3). Also, tools such as CAPTCHAs21 can be used to differentiate and filter legitimate traffic from illegitimate traffic. Many Web sites also choose to degrade their services to all users when under such an attack in order to continue providing what are seen as critical services to legitimate users. Make the attacker work. For attacks aimed at CPU time or memory consumption, a common strategy is to force the attacker to solve 19 Robert Stone, “An IP Overlay Network for Tracking DoS Floods,” in 9th Usenix Security Symposium, 2000; available at http://www.usenix.org/publications/library/proceedings/sec2000/full_papers/stone/stone.ps. 20 A.D. Keromytis, V. Misra, and D. Rubenstein, “SOS: Secure Overlay Services,” pp. 61-72 in Proceedings of ACM SIGCOMM, August 2002; available at http://citeseer.ist.psu.edu/keromytis02sos.html. 21 CAPTCHAs are an automated means for attempting to determine whether or not a computer or network user is a human being. (CAPTCHA is an acronym for “Completely Automated Public Turing Test to Tell Computers and Humans Apart.”) They often involve changing a graphic in such a way that a human can still determine what it shows, while a computer or bot would have trouble. For more information, see http://www.captcha.net.

OCR for page 181
Toward a Safer and More Secure Cyberspace BOX 8.3 Attack Diffusion As noted in Section 2.1 (Interconnected Information Technology Everywhere, All the Time) in this report, increased interconnection creates interdependencies and vulnerabilities. Nevertheless, it may also be possible to leverage such interconnections to defensive advantage. To illustrate the point, consider a denial-of-service (DOS) attack, which fundamentally depends on volume to saturate a victim.1 Interconnection could, in principle, enable the automatic diffusion of incoming traffic across multiple “absorption servers.” (An absorption server is intended primarily to absorb traffic rather than to provide full-scale services.) While no one would-be victim could reasonably afford to acquire a large enough infrastructure to absorb a large DOS attack, a service company could provide a diffusion infrastructure and make it available to customers. When a customer experienced a DOS attack, it could use its connectivity to shunt the traffic to this diffusion infrastructure. At least one company provides such a service today. But the approaches are not without potential problems. For example, the Domain Name System may be used to diffuse requests to one of a number of servers. But doing so reveals the destination address of individual absorption servers, which in principle might still leave them vulnerable to attack. Methods to hide the individual absorption servers are known, but they have potential undesirable effects on service under non-attack conditions. Further, automatic attack diffusion can conflict with occasional user or Internet service provider desires for explicit control over routing paths.    1David D. Clark, “Requirements for a Future Internet: Security as a Case Study,” December 2005; available at http://find.isi.edu/presentation_files/Clark_Arch_Security.pdf. some sort of puzzle. A good puzzle is hard to compute but relatively cheap to check. Examples include calculating a hash function where some bits of the input are specified by the defender, and the output has to have some number of high-order bits that are zeroes. Most such schemes are based on a 1992 proposal by Dwork and Naor22; adaptations to network denial-of-service attacks include TCP Client Puzzles23 and TLS Puzzles.24 22 Cynthia Dwork and Moni Naor, “Pricing via Processing or Combatting Junk Mail,” Proceedings of the 12th Annual International Cryptology Conference on Advances in Cryptology, 740: 139-147, Lecture Notes in Computer Science, Springer-Verlag, London, 1992. 23 A. Juels and J. Brainard, “Client Puzzles: A Cryptographic Countermeasure Against Connection Depletion Attacks,” pp. 151-165 in Proceedings of the 1999 Network and Distributed Security Symposium, S. Kent (ed.), Internet Society, Reston, Va., 1999. 24 Drew Dean and Adam Stubblefield, “Using Client Puzzles to Protect TLS,” Proceedings of the 10th Conference on USENIX Security Symposium, 10: 1, 2001, USENIX Association, Berkeley, Calif.; available at http://www.csl.sri.com/users/ddean/papers/usenix01b.pdf.

OCR for page 181
Toward a Safer and More Secure Cyberspace However, as with most areas of cybersecurity, attackers and defenders are locked in an ongoing arms race trying to stay abreast (or ahead) of each other’s techniques and tactics; developments are occurring at a rapid pace. Still, there are no ideal, comprehensive solutions for dealing with DDOS attacks, owing in large part to the sheer number and availability of attacking machines. Indeed, attackers are moving toward using ever-larger numbers of machines in their attacks (i.e., larger botnets), more evenly distributed around the Internet, and are attempting to make their attacks as indistinguishable as possible from legitimate traffic so as to confound the filters and response mechanisms used by defenders. There are three common motives for denial-of-service attacks: vandalism, revenge, and extortion. The different types of attacks suggest the need for different response strategies. Pure vandalism in some sense is the hardest to deal with, since it is typically an impulse crime committed without forethought and against more or less any site on the network. Fortunately, the effects are rarely long-lasting. More ominously, this type of attack may have fallen in importance not because of any substantive defensive measures but because of the shift by perpetrators to profit-motivated cybercrime. The second cause—revenge—is generally more annoying than serious. Typically, one hacker will annoy another; the offended party replies by launching a denial-of-service attack against the offender. These attacks—known as packeting—tend to be of limited duration; however, other users sharing the same access link are not infrequently affected as well. Profit-motivated DDOS attacks, and in particular extortion attacks, are in some sense easier to deal with. The targets are more predictable and hence can take defensive measures. Nonetheless, there is often insufficient time for a response. One common victim has been sports gambling Web sites, since they sell a time-sensitive product. (While online gambling is illegal in the United States, it is legal in other parts of the world, and U.S. companies often suffer collateral damage when flooding attacks against the gambling sites overload chokepoint network links.) Conventional law enforcement—“follow the money”—may be the most promising avenue, although the perpetrators generally employ money-laundering in an attempt to evade prosecution. 8.7.3 Research Challenges Research challenges in dealing with denial-of-service attacks focus on how to identify and characterize DDOS attacks and how to mitigate their

OCR for page 181
Toward a Safer and More Secure Cyberspace effects. In the first area, which includes the reliable detection of large-scale attacks on the Internet and the real-time collection and analysis of large amounts of attack-monitoring information, Moore et al. have developed a technique, known as backscatter, for inferring certain DOS activity.25 The technique is based on the fact that DDOS attackers sometimes forge the IP source address of the packets they send so that the packets appear to the target to be arriving from one or more third parties. However, as a practical matter, these fake source addresses are usually generated at random (that is, each packet sent has a randomly generated source address). The target, receiving a spoofed packet, tries to send an appropriate response to the faked IP address. However, because the attacker’s source address is selected at random, the victim’s responses are scattered across the entire Internet address space (this effect is called backscatter). By observing a large enough address range, it is possible to effectively sample all such denial-of-service activity on the Internet. Contained in these samples are the identity of the victim, information about the kind of attack, and a timestamp that is useful for estimating attack duration. The average arrival rate of unsolicited responses directed at the monitored address range also provides a basis for estimating the actual rate of the attack being directed at the target. There are several limitations to this technique. The most important is the assumption that attack packets appear to come from forged source addresses. While this was certainly true of the first generation of DDOS attacks, many attackers no longer bother with such forgery. While the exact extent of forgery is debatable, some experts claim that the large majority of attacks no longer use forged addresses. Two of the reasons are good; one, though, is cause for concern. First, operating system changes in Windows XP Service Pack 2 make address forgery harder. Second, a number of ISPs follow the recommendations in RFC 2827 and block (many) forged packets.26 Forgery is often unnecessary, however; source address-based filtering near the victim is rarely possible, and there are sufficiently many attack packets that effective tracing and response are difficult. The second area—mitigating the effects of DDOS attacks—spans a number of topics. One important topic is the development of better filters and router configurations. For example, the optimal placement of filters to maximize benefit and minimize negative impact is not easy to determine. Another example is the development of network-layer capabilities that 25 David Moore et al., “Inferring Internet Denial-of-Service Activity,” ACM Transactions on Computer Systems (TOCS), May 2006; available at http://www.caida.org/publications/papers/2001/BackScatter/usenixsecurity01.pdf. 26 P. Ferguson and D. Senie, RFC 2827, Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing, May 2000. Also known as BCP 38.

OCR for page 181
Toward a Safer and More Secure Cyberspace can be used to filter traffic efficiently. An example is the implementation of “pushback” configurations, an approach to handling DDOS attacks that adds functionality to routers so that they can detect and preferentially drop packets that probably belong to a DDOS attack, while also notifying upstream and downstream routers to do likewise.27 Such an approach requires coordination between various routers beyond that which is available through standard routing protocols. Another important topic relates to scale. Today’s solutions do not scale up to be able to address the numbers of attackers that are seen from today’s botnets. Therefore, one major research area is to develop scalable solutions for addressing DDOS attacks or for weathering them (e.g., content distribution networks). Other challenges involve developing ways to ensure that computers and their users are less susceptible to compromise by attackers or malicious code, thereby diminishing the resources available for attackers’ use in botnets. Additional DDOS-related research could also be useful in areas such as network protocols, network infrastructure, network flow analysis and control, metrics for measuring the impacts of DDOS attacks, and better forensic methods and techniques for tracing and catching attackers.28 Still another topic is organizational and institutional. Because certain promising approaches to dealing with DDOS attacks depend on cooperation between ISPs (some of which may be in different countries and subject to different laws), finding ways to encourage and facilitate cooperation is important.29 Research on this topic might include how responsibility and obligation for responding to attacks should be shared between ISPs and their customers; what kinds of business service model are needed; how to build formal collaborations for automated coordination among different sites, ISPs, and various agencies; and how to incentivize ISPs to deploy defensive measures. 27 For more information on pushback, see Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson, and Scott Shenker, “Controlling High Bandwidth Aggregates in the Network,” Computer Communications Review 32(3): 62-73, 2002. 28 For additional information on DDOS attacks, see Jelena Mirkovic et al., A Taxonomy of DDoS Attacks and DDoS Defense Mechanisms, Technical Report #020018, University of California, Los Angeles, Computer Science Department, available at http://www.eecis.udel.edu/~sunshine/publications/ucla_tech_report_020018.pdf [undated]; Xuhui Ao, Report on DIMACS Workshop on Large-Scale Internet Attacks, Center for Discrete Mathematics and Theoretical Computer Science (DIMACS), available at http://dimacs.rutgers.edu/Workshops/Attacks/internet-attack-9-03.pdf, 2003; and Rich Pethia, Allan Paller, and Eugene Spafford, “Consensus Roadmap for Defeating Distributed Denial of Service Attacks,” Project of the Partnership for Critical Infrastructure Security, SANS Institute, available at http://www.sans.org/dosstep/roadmap.php, 2000. 29 Xuhui Ao, Report on DIMACS Workshop on Large-Scale Internet Attacks, September 23-24, 2003; available at http://dimacs.rutgers.edu/Workshops/Attacks/internet-attack-9-03.pdf.

OCR for page 181
Toward a Safer and More Secure Cyberspace As one example, the entire community of ISPs would benefit from knowing the frequency of DOS attacks. ISPs are aware (or could be aware) of DOS attacks through the measurements that they ordinarily make in the course of their everyday operations, since sustained rates of packet drops by routers, observable via the simple network management protocol (SNMP), frequently indicate the existence of an attack. However, for competitive reasons, this information is rarely disclosed publicly, so the community cannot develop a complete picture of the situation. Research (or at least investigation) is needed to determine mechanisms that would encourage the disclosure of such data to an independent third party and the publication of a sanitized version of these data. 8.8 DEALING WITH SPAM Spam—what might loosely be defined as unsolicited e-mail sent en masse to millions of users—has evolved from a minor nuisance to a major problem for the Internet, both as a mechanism for delivering attacks (e.g., phishing) and as a means for propagating other types of attack (e.g., viruses). Spam is undesirable from the recipient’s standpoint because he or she must continually spend time and effort to deal with unwanted e-mails. In small volume, it would be easy to delete unwanted e-mails that can be identified from the header. But spam e-mail often uses deceptive headers in order to persuade users to open it (e.g., rather than saying “Subject: Viagra for sale,” the header will say “Subject: Greetings from an old friend”), and by some accounts, spam accounts for over 90 percent of e-mail sent on the Internet.30 Thus, it is not unreasonable to estimate that individuals spend hundreds of millions of person-hours per year in dealing with spam. Today, spam threatens to undermine the stability and usefulness of networked systems and to impose significant economic costs and lost productivity. Spending valuable time dealing with a nuisance is bad enough, but spam can also have serious consequences. For example, spam can clutter one’s mailbox so that desired e-mails are missed or other e-mails cannot be received; it forces ISPs or users to implement filters that may inadvertently filter wanted messages. Because spam can prevent a user from doing useful things in his or her computing environment, spam can be regarded as a kind of denial-of-service attack against individual users. Spam can cause harm. One risk is a form of online identity theft. Because it is easy to forge an electronic return address (so that an e-mail appears to have been sent from the forged address), spam senders often insert legitimate e-mail addresses (e.g., those harvested from online bul- 30 See, for example, http://www.postini.com/news_events/pr/pr011007.php.

OCR for page 181
Toward a Safer and More Secure Cyberspace letin boards, chat rooms, and the like) as the purported sender of their spam e-mail. The reputation of the legitimate e-mail user is thus compromised, and the spam also generates for the legitimate user a flood of “mailer-rejection notices” from e-mail systems that reject the spam e-mail for some reason. A second risk is that spam can compromise the integrity of the user’s computing environment, causing it to do things that are undesired from the user’s point of view. E-mail systems are often designed to allow users to open and execute e-mail attachments with a simple mouse click, or to access Web pages referenced in an embedded link, or to display images or messages formatted as “rich text.” Such functionality increases the convenience and enhances the utility of e-mail for the user. But when spammers exploit these features, the result can be that a hostile attachment is executed, a user-compromising Web page is accessed (merely by accessing it), or a trap door is opened simply by viewing the e-mail. It is true that clandestine applications can be delivered through many different mechanisms, and in principle there is nothing special about spam e-mail as a delivery mechanism. But in practice, the ease with which e-mail can be delivered suggests that e-mail—and payloads that it carries—will be used aggressively in the future for commercial purposes.31 Once compromised, the user’s computing environment becomes a platform for active threats such as the following: Divulging the personal information resident on the user’s computer. Especially common would be financial records that are stored by various personal money management systems, but in the future such information may include medical records. Such information could be used to target users with specific and personalized communications that may be threatening. An example of a targeted personal e-mail would be: “Did you know the odds of dying with your disease are much higher now?” Displaying advertisements by surprise (e.g., pop-under ads). Tracking the user’s information-seeking behavior (e.g., what Web sites have been visited). Today, the use of such traces is most often limited to identifying when a user is visiting a site that was visited in the past, but there is nothing in principle that prevents the entire 31 It is also true that the root cause of the problems caused by Trojan horses is insecurities in the user’s computing environment. Thus, one could argue, with considerable force and reason, that eliminating these insecurities would eliminate Trojan horse problems as well as a host of other problems. On the other hand, it is unrealistic to expect that such insecurities would ever be eliminated entirely. More to the point, users will not be relieved to know that the reason they are suffering from Trojan horses is that their operating systems are insecure.

OCR for page 181
Toward a Safer and More Secure Cyberspace trace from being made public knowledge. (For example, consider spyware from a group that opposes pornography that reports your use of sexually explicit Web sites to a public database.) Launching attacks on other computer systems without the user’s knowledge (e.g., as part of a botnet). From an institutional standpoint, spam consumes significant amounts of bandwidth, for which ISPs and network operators must pay. Indeed, large volumes of spam are in some ways indistinguishable from a denial-of-service attack. Thus, spam can have important security implications on a regional or national scale as well as being simply annoying to individual users. ISPs and users may also bear the cost and inconvenience of installing and maintaining filters to reduce spam volumes, as well as of maintaining a larger infrastructure to accommodate the vast amount of spam flowing through their networks (more servers, routers, adminstrators, floor space, power, and so on). (An interesting question is thus how the collective cost to individuals and business compares with the benefits gained collectively by the spam senders and those who actually buy something as a result of the spam.) Spam is only one dimension of a commercial environment that bombards citizens with junk mail (e.g., catalogs and endless advertising pieces); long, unsolicited voicemails on our telephone mail systems; and unwanted faxes. But spam is different from the others in at least two significant ways. First, the costs per message to transmit spam e-mail and similar electronic messages is much smaller by several orders of magnitude than that for postal mail or telephone calls. Second, spam can be more deceptive than junk snail mail (junk faxes and telemarketing phone calls are annoying but are small fractions of the total fax and phone traffic). Before it is opened, spam e-mail can have the identical look and feel of a legitimate e-mail from an unknown party. Policy makers at both the federal and state levels are seeking legislative remedies for spam, such as the CAN-SPAM Act of 2003 (17 U.S.C. 103). However, crafting appropriate and workable legislation has been problematic, with at least four separate dimensions that create difficulty: As a commercially oriented activity, some forms of spam do create some economic benefit. Some small fraction of the spam recipients do respond positively to unsolicited e-mail that promotes various products or services. In this regard, it is important to remember that unsolicited commercial e-mail does not consist solely of Nigerian bank fraud messages or ads for Viagra, but also includes ads for cars, software, sunglasses, and vacations. Furthermore, the economics of e-mail are such that if only a very small fraction of recipi-

OCR for page 181
Toward a Safer and More Secure Cyberspace ents of a given spam mailing respond positively, that is sufficient to make the sending of the original spam turn a profit. Defining spam through a legislative process is very difficult. What is spam for one person may be an interesting curiosity to another. Consequently, it is very difficult to develop regulations that capture the notion of spam in a sufficiently precise manner to be legally enforceable and yet sufficiently general that spam senders cannot circumvent them with technical variations. Spam can be sent with impunity across national borders. Regulations applying to domestic spam senders can easily be circumvented by foreign intermediaries. Spam is arguably a form of free speech (albeit commercial speech). Thus, policy makers seeking to regulate spam must tread carefully with respect to the First Amendment. In the long run, addressing the spam problem is going to involve technology and policy elements. One important technical dimension is the anonymity of spam. Because spam senders realize the unpopularity of the e-mail that they produce, today’s spam senders seek a high degree of sender anonymity to make it difficult or impossible for the recipient to obtain redress (e.g., to identify a party who will receive and act on a complaint). Thus, the provenance of a given e-mail is one element in dealing with the spam problem, suggesting the relevance of the attribution research of Section 5.1, “Attribution.” But even if the attribution problem itself is solved, there are complicating factors regarding spam. For example, as far as many people are concerned, the senders of e-mail fall into three categories—those known to the receiver to be desirable, those known to be undesirable, and those of an unknown status. Provenance—at least as traditionally associated with identity—does not help much in sorting out the last category. Moreover, botnets today send “legitimate” e-mail from compromised hosts—that is, if my computer is compromised so that it becomes a zombie in a botnet army, it can easily send spam e-mail under any e-mail account associated with my computer. That mail will be indistinguishable from legitimate e-mail from me (i.e., e-mail that I intended to send). Thus, preventing the compromise of a host becomes part of the complete spam-prevention research agenda. Yet another technical dimension of spam control is a methodology to examine content as well as origin of e-mails.32 That is, how can a computer be trained to differentiate spam from legitimate e-mail? Most 32 Joshua Goodman, Gordon V. Cormack, and David Heckerman, “Spam and the Ongoing Battle for the Inbox,” Communications of the ACM, 50(2): 24-33, 2007.

OCR for page 181
Toward a Safer and More Secure Cyberspace spam-recognition systems today have at least one machine learning component that performs such differentiation based on examples of both spam and nonspam e-mail. Much of the progress in antispam research has involved improving the relevant machine learning algorithms as spammers develop more sophisticated means for evading spam-detection algorithms. Other relevant factors entail obtaining more examples of different kinds of spam (so that new kinds of detection-evasion techniques can be taken into account by spam detectors) and doing so more quickly (so that spammers have smaller windows in which to propagate their new variants). Another dimension of spam-detection performance depends on the ability to extract the relevant content from the bits that actually constitute the e-mail. ASCII art, photographic images, and HTML encodings have all been used to evade filtering, with varying degree of success. Indeed, image-based spam, in which an e-mail contains an embedded image of a message, is quite common today. All of these methods are based on the fact that that extraction of the content is computationally intensive and thus impractical to perform on all incoming e-mails. Spam is, by definition, a collection of many e-mails with identical content. So spam might be identified by virtue of the fact that many copies of it are circulating on the Internet—and there are ways that institutionally based spam filters could be able to identify a given e-mail as being a part of this category. The obvious countermeasure for the spammer is to make each message slightly different, but in a way that does not alter the core message of the spam e-mail, which itself suggests another research problem of identifying messages as “identical in semantic content” despite small differences at the binary level. The economics of spam are also relevant. If the incremental cost of sending spam were higher, the volume of spam could be reduced significantly. But spammers are not the only parties to send e-mail in bulk—organizations with newsletters, for example, may send large volumes of e-mail as well. The imposition of a small financial cost per e-mail would do much to reduce spam, but it would be difficult to deploy and also would violate long-standing practices that make e-mail an effective mechanism of communication notwithstanding the spam problem. Other ways of imposing cost include requiring a time-consuming computation that makes it more difficult to send e-mails in bulk and requiring a proof that a human is involved in the sending of individual e-mails. How to impose costs on spammers, and only on spammers, remains an open technical and regulatory question. Finally, as new communications channels emerge, new forms of spam are likely to emerge. For example, spam text messages to mobile and instant message spam are two relatively newer forms of spam. Future

OCR for page 181
Toward a Safer and More Secure Cyberspace spam variants may include exploits related to location-aware devices (e.g., advertisements tied explicitly to the user’s location) and spam and spam-like payloads other than text delivered to mobile devices such as cellular telephones. An example of the latter is that with the increasingly popular use of voice-over-IP, junk phone calls (also known as SPIT, for spam over Internet telephony) may come to be a problem in the future. Research will be needed to address these new forms of spam as well.