Trust In Cyberspace, Chapter 4, Nat'l Academy Press, 1999


	Trust in Cyberspace Committee on Information Systems Trustworthiness, National Research Council (1999) 352 pages 6 x 9



	4 Reinventing Security

	Introduction Increasing the immunity of a networked information system (NIS) to hostile attacks is a broad concern, encompassing authentication, access control, integrity, confidentiality, and availability. Any solution will almost certainly be based on a combination of system mechanisms in addition to physical and personnel controls.¹ The focus of this chapter is these system mechanisms—in particular, what exists, what works, and what is needed. In addition, an examination of the largely disappointing results from more than two decades of work based on what might be called the "theory of security" invites a new approach to viewing security for NISs—one based on a "theory of insecurity"—and that, too, is discussed.

	¹Personnel security is intrinsic in any NIS, since some set of individuals must be trusted to some extent with regard to their authorized interactions with the system. For example, people manage system operation, configure external system interfaces, and ultimately initiate authentication of (other) users of a system. In a similar vein, some amount of physical security is required for all systems, to thwart theft or destruction of data or equipment. The physical and personnel security controls imposed on a system are usually a function of the environment in which the system operates. Individuals who have access to systems processing classified information typically undergo extensive background investigations and may even require a polygraph examination. In contrast, most employers perform must less stringent screening for their information technology staff. Similarly, the level of physical security afforded to the NISs that support stock markets like the NYSE and AMEX is greater that that of a typical commercial system. Although physical and personnel controls are essential elements of system security, they are largely outside the scope of this study.



	110 trust in cyberspace

	The choice of system security mechanisms employed in building an NIS should, in theory, be a function of the environment, taking into account the security requirements and the perceived threat. In practice, NISs are constructed with commercial off-the-shelf (COTS) components. What security mechanisms are available is thus dictated by the builders of these COTS components. Moreover, because most COTS components are intended for constructing a range of systems, their security mechanisms usually are not tailored to specific needs. Instead, they reflect perceptions by a product-marketing organization about the requirements of a fairly broad market segment.² The task faced by the NIS security architect, then, is determining (1) how best to make use of the given generic security mechanisms and (2) how to augment those mechanisms to achieve an acceptable level of security. The NIS security architect's task is all the more difficult because COTS products embody vulnerabilities, but few of the products are subjected by their builders to forms of analysis that might reveal these vulnerabilities. Thus, the NIS security architect will generally be unaware of the residual vulnerabilities lurking in a system's components. This chapter's focus on security technology should not be misconstrued—an overwhelming majority of security vulnerabilities are caused by "buggy" code. At least a third of the Computer Emergency Response Team (CERT) advisories since 1997, for example, concern inadequately checked input leading to character string overflows (a problem peculiar to C programming language handling of character strings). Moreover, less than 15 percent of all CERT advisories described problems that could have been fixed or avoided by proper use of cryptography. Avoiding design and implementation errors in software (the subject of Chapter 3) is an essential part of the security landscape. Evolution of Security Needs and Mechanisms In early computing systems, physical controls were an effective means of protecting data and software from unauthorized access, because these systems were physically isolated and single-user. The advent of multiprogramming and time-sharing invited sharing of programs and data among an often closed community of users. It also created a need for mechanisms to control this sharing and to prevent actions by one user

	²Some COTS products do allow a system integrator or site administrator to select from among several options for security facilities, thereby providing some opportunity for customization. For example, one may be able to choose between the use of passwords, challenge-response technology, or Kerberos for authentication. But the fact remains that COTS components limit the mechanisms available to the security architect.



	reinventing security 111

	from interfering with those of another or with the operating system itself. As computers were connected to networks, sharing became even more important and access control problems grew more complex. The move to distributed systems (e.g., client-server computing and the advent of widespread Internet connectivity) exacerbated these problems while providing ready, remote access not only for users but also for attackers from anywhere in the world. Closed user communities are still relevant in some instances, but more flexible sharing among members of very dynamic groups has become common. See Box 4.1 for a discussion of threats from within and outside user communities. The evolution of computing and communication capabilities has been accompanied by an evolution in security requirements and increased demands on security mechanisms. Computing and communication features and applications have outpaced the ability to secure them. Requirements for confidentiality, authentication, integrity, and access control have become more nuanced; the ability to meet these requirements and enforce suitable security policies has not kept up. The result: successful attacks against NISs are common, and evidence suggests that many go undetected (U.S. GAO, 1996). The increasing use of extensible systems and foreign or mobile code (e.g., Java "applets" and ActiveX modules delivered via networks) further complicates the task of implementing NIS security. Of growing concern with regard to controlling critical infrastructures is denial-of-service attacks, which compromise availability. The attack may target large numbers of users, preventing them from using a networked information system, or may target individuals, destroying their ability to access data, or may target a computing system, preventing it from accomplishing an assigned job. Only recently have denial-of-service attacks become a focus of serious countermeasure development. Clearly, these attacks should be of great concern to NIS security architects. Access Control Policies It is common to describe access controls in terms of the policies that they support and to judge the effectiveness of access control mechanisms relative to their support for those policies. This might leave the impression that access control policies derive from first principles, but that would be only partly true. Access control policies merely model in cyberspace notions of authorization that exist in the physical world. However, in cyberspace, programs—acting on behalf of users or acting autonomously—and not the users themselves are what interact with data and access other system objects. This can be a source of difficulty since actions by users are the concern but action by programs is what is governed by the policy.



	112 trust in cyberspace

	BOX 4.1 Insiders Versus Outsiders A debate has raged for some time over whether the major threat to system security arises from attacks by "insiders" or by "outsiders." Insiders have been blamed for causing 70 to 80 percent of the incidents and most of the damage (Lewis, 1998). But independent of the reliability of this estimate, it is clear that insiders do pose a serious threat. Two questions then arise: What is the definition of insider? How is damage assessed? There are three plausible definitions for an insider: 1. A person with legitimate physical access to computer equipment. Thus, a janitor is an insider, but a burglar or casual visitor is not. 2. A person with some sort of organizational status that causes members of the organization to view requests or demands as being authorized. In this view, a purchasing agent is an insider, but a vendor is not. 3. A person with some level of privilege or authority with regard to the computer system. This characterization is particularly difficult to assess in today's networked environment. A casual Internet user accessing a vendor's Web site and running a well-known attack would, in the eyes of most observers, constitute an "outsider" attack. And if the administrator of the Web site used authorizations to make mischief, that would generally be viewed as an "insider" attack. But what of the vendor who is granted putatively limited privilege on a corporate network and then attempts to increase that privilege or otherwise gain information about competitors? It is equally unclear whether a traditional spy or saboteur, operating from the inside at the behest of an outside organization, is an "insider," an "outsider," or yet a third class of entity. Assessing damage from attacks is equally problematic. Overestimation of damage is rife when prosecution or insurance claims are involved. Perhaps the most egregious case of overestimation occurred in connection with the so-called "Knight Lightning" case. A prosecutor claimed that a particular item of intellectual property was worth $70,000, but closer examination showed that copies were sold by its owners for $30.00 and that the information in the document was made available, again by its owners, in other forms for free (Sterling, 1992). On the other hand, damage is (it is rumored) allegedly underreported in the financial community to avoid loss of customer confidence. Only recently have commercial institutions begun to come forward, albeit under the cloak of anonymity (War Room Research LLC, 1996). Arguably, the nature of the reporting process inflates the relative numbers of insider incidents, as they are often easier to discover and report. Sophisticated outsider attacks leave minimal traces and force those suspecting an attack to go to great lengths to convince authorities that one is under way (Stoll, 1989). Furthermore, insider attacks, when discovered, tend to be prosecuted more energetically and to gain more publicity than other forms of white-collar crime (Schwartz, 1997). Various estimates add to the confusion. The Federal Bureau of Investigation estimated total



	reinventing security 113

	damages to the U.S. economy from computer crime to be on the order of $300 billion. Yet reported damages totaled "only" $100 million (War Room Research LLC, 1996). If the otherwise unverified estimate of 70 percent insider damage is accurate, then the possible range of damages is $70 million to $210 billion. A more accurate estimate will not be possible until comprehensive reporting mechanisms are in place and are used. Most would classify as insiders embezzlers and disgruntled employees operating alone or as part of a conspiracy who mount frauds and destroy data. But the insiders who can cause the most damage are the administrators of the network and its attached computers. They typically have both the knowledge and the authority to alter, copy, or destroy data, cover their tracks by modifying audit logs, and then modify audits and other information to direct suspicion at other individuals. Organizations today tend to array their defenses around the perimeter of their computing network and rely on deterrence mechanisms, such as audits, to discourage insider attacks. Fine-grained access control is absent inside these perimeters because it can get in the way of users, especially during emergencies. Technical controls on the actions or authorities of administrators are minimal. There is, however, a growing concern about the inherent limitations of perimeter security (see the section titled "Firewalls" in this chapter). As a result, some organizations are turning to internal network-access controls as a way of buttressing perimeter security. Ironically, this latter access-control technology is more consistent with the traditional meaning of the term "firewall" as imposing unbreachable partitions in a structure. Intrusion-detection systems frequently are advocated for combating the insider threat, as well as for detecting outsider attacks that have successfully breached perimeter defenses. These systems collect data on computer and network usage, apply pattern matching or heuristics, and trigger alarms if they detect what appears to be a pattern of improper activity.¹ When directed toward insiders, intrusion-detection systems have proved deficient. The amount of data that must be collected imposes a performance penalty and, in many cases, raises concerns about improper workplace surveillance. Although the assumption underlying most heuristics for recognizing improper activity is that users exhibit fairly constant patterns of behavior, this assumption is generally invalidated, for example, during emergencies, the very time when a deluge of security alarms is least tolerable. Adept users can also subvert a heuristic by making gradual shifts in their behavior, such as slowly increasing the number of files accessed each day so that file accesses that once would trigger an "improper browsing" alarm are now treated as normal. The insider threat is a classic example of security as a management problem. Technical defenses tend to be expensive, cumbersome, or largely ineffective. The most practical solution is to know the people who have significant authority on the system and to work to maintain their loyalty to the organization. ¹Most of these systems look for specific attack "signatures" rather than attempt to detect deviation from nominal behavior. In this sense, such systems are much like antivirus programs.



	114 trust in cyberspace

	The evolution of access control policies and access control mechanisms has attempted, first, to keep pace with the new modes of resource sharing supported in each subsequent generation of systems, and, second, to repel a growing list of attacks to which the systems are subjected. The second driving force is easily overlooked, but crucial. Access controls can enforce the principle of least privilege.³ In this fashion, they prevent and contain attacks. Before suggesting directions for the future, it is instructive to examine the two basic types of access control policies that have dominated computer security work for over two and a half decades: discretionary access control and mandatory access control. Discretionary access control policies allow subjects, which model users or processes, to specify for objects what operations other subjects are permitted to perform. Most of the access control mechanisms implemented and deployed enforce discretionary access control policies. Individual users or groups of users (or computers) are identified with subjects; computers, networks, files or processes, are associated with objects. For example, read and write permissions might be associated with file system objects (i.e., files); some subjects (i.e., users) might have read access to a given file while other subjects do not. Discretionary access control would seem to mimic physical-world policies of authorization, but there are subtleties. For instance, transitive sharing of data involving intermediary users or processes can subvert the intent of discretionary access control policies by allowing a subject to learn the contents of an object (albeit indirectly) even though the policy forbids (direct) access to that object by the subject. Mandatory access control policies also define permitted accesses to objects for subjects, but now only security administrators, rather than individual users, specify what accesses are permitted.⁴ Mandatory access control policies typically are formulated for objects that have been labeled, and the policies typically are intended to regulate information flow from one object to another. The best-known example of mandatory access controls arises in connection with controlling the flow of data according to military classifications. Here, data are assigned classification labels (e.g., "top secret" and "unclassified") and subjects are assigned clearances; simple rules dictate the clearance needed by a subject to access data that have been assigned a given label.

	³The principle of least privilege holds that programs and users should operate using the least set of privileges necessary to complete the job. ⁴In fact, there exist policies that are mandatory access control but user processes do have some control over permissions. One example is a policy in which a user process could irrevocably shed certain permissions.



	reinventing security 115

	Mandatory access controls can prevent Trojan horse attacks; discretionary access controls cannot. A Trojan horse is a program that exploits the authorization of the user executing a program for another user's malicious purposes, such as copying information into an area accessible by a user not entitled to access that information. Mandatory controls block such attacks by limiting the access of all programs—including the Trojan horse—in a manner that cannot be circumvented by users. Discretionary access controls are inherently vulnerable to Trojan horse attacks because software executing on behalf of a user inherits that user's privilege without restriction (Boebert and Kain, 1996). Shortcomings of Formal Policy Models Despite the lion's share of attention from researchers and actual support in deployed system security mechanisms, many security policies of practical interest cannot be formulated as discretionary and mandatory access control policies. Discretionary and mandatory access control focus on protecting information from unauthorized access. They cannot model the effects of certain malicious or erroneous software, nor do they completely address availability of system resources and services (i.e., protection against denial-of-service attacks). And they are defined in an access control model—defined by the Trusted Computer System Evaluation Criteria (U.S. DOD, 1985)—that has only limited expressive power, rendering the model unsuitable for talking about certain application-dependent access controls. The access control model defined by the Trusted Computer System Evaluation Criteria, henceforth called the DOD access control model, presupposes that an organization's policies are static and have precise and succinct characterizations. This supposition is questionable. Organizations' security policies usually change with perceived organizational needs and with perceived threat. Even the Department of Defense's policy—the inspiration for the best-known form of mandatory access control (Bell and La Padula, 1973)—has numerous exceptions to handle special circumstances (Commission on Protecting and Reducing Government Secrecy, 1997). For example, senior political or military officials can downgrade classified information for diplomatic or operational reasons. But the common form of mandatory access control does not allow nonsensitive objects to be derived from sensitive sources, because the DOD access control model does not associate content with objects nor does it (or can any model) formalize when declassifying information is safe.⁵ Policies

	⁵This also means that the underlying mathematical model is unable to capture the most basic operation of cryptography, in which sensitive data become nonsensitive when enciphered.



	116 trust in cyberspace

	involving application-specific information also cannot be handled, since such information is not part of the DOD access control model.⁶ At least two policy models that have been proposed do take into account the application involved. The Clark/Wilson model (Clark and Wilson, 1987) sets forth rules for maintaining the integrity of data in a commercial environment. It is significant that this model contains elements of the outside world, such as a requirement to check internal data (e.g., inventories) with the physical objects being tabulated. The "Chinese Wall" model (Brewer and Nash, 1989) expresses rules for separating different organizational activities for conformance with legal and regulatory strictures in the financial world. Still, from the outset, there has been a gap between organizational policy and the 1970s view of computing embodied by the DOD access control model: users remotely accessing a shared, central facility through low-functionality ("dumb") terminal equipment. And, as computing technology advanced, the gap has widened. It is significant that, in a glossary of computer security, Brinkley and Schell (1995) use a passive database (a library) as the example and include the important passage: . . . the mapping between our two `worlds': 1. The world independent of computers, of people attempting to access information on paper. 2. The world of computers, with objects that are repositories for information and subjects that act as surrogates for users in the attempt to access information in objects. Processes, for example, are complex, ephemeral entities without clear boundaries, especially in the distributed and multithreaded systems of today. A modern computing network comprises independent computers that are loosely linked to each other and to complexes of servers. And modern programs likely have their own access controls, independent of what is provided by the underlying operating system and the DOD access control model. An access control model that does not capture this aspect of computing systems is fatally flawed. Subsystems more and more resemble operating systems, and they should be treated as such. To be sure, a subsystem cannot exceed permissions granted to it by an underlying operating system. And even though

	⁶It should be noted that a formal access control model of a complex application has been defined, and the corresponding implementation subjected to extensive assurance activity. The exercise explored many issues in the construction of such models and is worth study. See Landwehr et al. (1984) for details.



	reinventing security 117

	the resources that a subsystem protects are the user's own, that protection serves an important function. Moreover, even if the access control model did capture the policies of subsystems, there still remains the problem of composing those policies with all the other policies that are being enforced. Such composition is difficult, especially when policies are in conflict with each other, as all too often is the case. The object abstraction in the DOD access control model also can be a source of difficulty. Real objects seldom have uniform security levels, despite what is implied by the DOD access control model. Consider a mailbox with multiple messages. Each message may have field-dependent security levels (sensitive or nonsensitive message body, sensitive or nonsensitive address list, and so on), and there may be multiple messages in the mailbox. What is the level of the mailbox as a whole? The alternative is to split messages so that individual fields are in individual objects, but that leads to a formulation that could be expensive to implement with fidelity. The all-or-nothing nature of the DOD access control model also detracts from its utility. Designers who implement the model are forced to err on the side of being restrictive, in which case the resulting system may be unusable, or to invent escapes, in which case knowing that a system adheres to the model has limited practical significance. In the battle between security and usability, usability loses. Moreover, since the DOD access control model does not account for contemporary defensive measures, such as virus scans, approaches to executable content control, or firewalls, the system architect who is bound by the model has no incentive to use these technologies. Deploying them makes no progress toward establishing that the system is consistent with the model and, in addition, transforms the model into an incomplete characterization of the system's defensive measures (thereby again limiting the model's practical utility). Evidence that DOD has recognized some of the problems inherent in building systems that enforce the DOD access control model appears in the new DOD Goal Security Architecture (DGSA; see Box 4.2). DGSA does not legislate that only the DOD access control model be used; instead it supports a broad set of security policies that go far beyond the traditional information-flow policies. DGSA also does not discourage DOD end users from employing the latest in object-based, distributed systems, networks, and so on, while instituting rich access control, integrity, and availability policies. However, DGSA offers no insights about how to achieve an appropriate level of assurance that these policies are correctly implemented (despite upping the stakes significantly regarding what security functionality must be supported). Thus it remains to be seen if the DGSA effort will spur significant progress in system security.



	118 trust in cyberspace

	BOX 4.2 DOD Goal Security Architecture The DOD Goal Security Architecture (DGSA) (DISA, 1996) has evolved over the last decade as a series of architecture documents. Most of the principles have remained constant during this evolution. DGSA is oriented toward supporting a range of access controls and integrity policies in an object-oriented, distributed-system environment. The range of security policies to be supported goes far beyond the Bell-La Padula information flow security policy that has dominated DOD security for more than 20 years. Multiparty authorization, multilevel objects, originator control of release, role-based authorization, and variable levels of availability are among the security features offered by DGSA. DGSA embraces commercial off-the-shelf (COTS) products and commercial network resources. Commercial networks can readily be employed through the use of (conventional, high-assurance) network security devices. But there is the matter of achieving availability in excess of what most commercial users seek.¹ If commercial networks are vulnerable to disruption on a global or targeted basis, then DOD communications traversing these networks would be vulnerable to denial-of-service attacks. Use of COTS operating systems and applications raises questions about how to create multilevel information objects and how to enforce appropriate information flow security, as labeling is generally not supported in such commercial offerings. Perimeter security devices (e.g., firewalls and guards) are limited in the granularity at which they can enforce data separation, especially in the absence of labels. At present, DGSA must be viewed more as a list of goals than as an architectural specification. Available (COTS) technology and even research and development prototypes lag far behind what DGSA calls for. Most of the goals will require substantial research, and some of the goals may be unattainable relative to credible, national-level threats. Moreover, DGSA still embodies a notion of "absolute protection" despite the practical impossibility of attaining that. An excellent overview of DGSA, including a characterization of some of the research and development challenges it poses, is offered by Feustel and Mayfield (1998). ¹Commercial users with high real-time communication availability concerns do not now depend on the Internet. For example, U.S. stock exchanges employ redundancy at multiple layers to achieve sufficient availability using commercial communications. See Chapter 2 for additional discussions of vulnerabilities in the public telephone network and Internet.

	A New Approach One can view the ultimate goal as the building of systems that resist attack. Attackers exploit subtle flaws and side effects in security mechanisms and, more typically, exploit interactions between mechanisms. Testing can expose such previously hidden aspects of system behavior, but no



	reinventing security 119

	amount of testing can demonstrate the absence of all exploitable flaws or side effects. An alternative to finding flaws in a system is to demonstrate directly that the system is secure by showing the correspondence between the system and some model that embodies the security properties of concern. One problem (system security) is thus reduced to another (model security) presumably simpler one. Sound in theory, success in this endeavor requires the following: 1. Models that formalize the security policies of concern. 2. Practical methods for demonstrating a correspondence between a system and a formal model. But the arguments given earlier suggest that suitable formal models for NIS security policies, which invariably include stipulations about availability and application semantics, do not today exist and would be difficult to develop. Moreover, establishing a correspondence between a system and a formal model has proved impractical, even for systems built specifically with the construction of that correspondence in mind and for which analysts have complete knowledge and access to internals. Establishing the correspondence is thus not a very realistic prospect for COTS components, which are not built with such verification activities in mind and, generally, do not offer the necessary access to internals. Experience has taught that systems—and, in particular, complex systems like NISs—can be secure, but only up to a point. There will always be residual vulnerabilities, always a degree of insecurity. The question one should ask is not whether a system is secure, but how secure that system is relative to some perceived threat. Yet this question is almost never asked. Instead, notions of absolute security, based on correspondence to formal models, have been the concern. Perhaps it is time to contemplate alternatives to the "absolute security" philosophy. Consider an alternative view, which might be summarized in three "axioms": 1. Insecurity exists. 2. Insecurity cannot be destroyed. 3. Insecurity can be moved around. With this view, the object of security engineering would be to identify insecurities and move them to less exposed and less vulnerable parts of a system. Military cryptosystems that employ symmetric-key cryptography illustrate the approach. Radio transmissions are subject to interception, so they are enciphered. This encryption does not destroy the insecu



	120 trust in cyberspace

	rity (disclosure of message contents) but rather moves the insecurity to the cryptographic keys, whose compromise would lead to the disclosure of intercepted transmissions. The keys must be distributed. And they are, subject to elaborate physical controls and auditing that are impractical for radio transmissions.⁷ So, the use of encryption moves insecurity from one part of the system to another and does so in a manner that decreases the overall vulnerability of the system relative to some perceived threats. (In a world where monitoring radio transmissions was difficult but kidnapping diplomatic couriers bearing cryptographic keys was easy, the perceived threats would be different and the encryption solution no longer would be appropriate.) Vulnerability assessments provide a well-known way to identify system insecurities. Here, attack by an adversary is simulated using a team whose technical and other resources are comparable to the actual threat. The team undertakes an unconstrained search for vulnerabilities, examining the system in its context of use and attempting to exploit any aspect of the system, its implementation, or its operational context to cause a security breach. A methodical approach to this process is described in Weissman (1995). Vulnerability assessment has the advantage that all aspects of the system are stressed in context. But it does have disadvantages. No overt evidence of security is presented. The approach is potentially quite costly, because assessment must be carried out on a per system basis. And finally, systematic methods do not yet exist for predicting how vulnerabilities and attacks can propagate in systems. Were it possible to analyze vulnerability and attack propagation, designers could begin to think about a design philosophy based on relocating insecurities, to move them away from threats. The result would be a methodology especially attractive for securing NISs—an alternative to the "absolute security" philosophy. Findings 1. Existing formal policy models have only limited utility because they concern only some of the security properties of interest to NIS builders. To the extent that formal models are useful (as descriptive vehicles and for inferring consequences from policies) further development is needed to remove the limits of existing policies, both with regard to the system model and with regard to what types of security are captured. 2. Demonstrating the correspondence between a system and a formal model is not a practical approach for gaining assurance that an NIS is

	⁷Although even these precautions do not guarantee security, as the celebrated "Walker Case" showed (Kneece, 1986).



	reinventing security 121

	resistant to attack. An alternative to this "absolute security" philosophy is to identify insecurities and make design changes to reposition them in light of the nature of the threat. Further research is needed to determine the feasibility of this new approach to the problem. 3. Some practical means for evaluating the security characteristics (both security features and residual vulnerabilities) of COTS system components is essential. Evaluation must not be so costly or time-consuming that vendors will shun it or that evaluated products will be obsolete (relative to their nonevaluated counterparts). Identification and Authentication Mechanisms Identification is an assertion about an entity's identity. In the simplest case, this assertion could be a claim that the entity makes. Authentication refers to the process by which a system establishes that an identification assertion is valid. A number of authentication mechanisms are commonly used in practice; each has advantages and disadvantages. Historically, the mechanisms have been characterized as something you know, something you have, or something you are. The latter refers to innate biological properties of the user and therefore is not applicable for computer-to-computer authentication.⁸ Network-based Authentication Network-based authentication relies on the underlying network (and possibly the host computer) to authenticate the identity of the source of network traffic. The reliability of the approach is thus closely tied to characteristics of the underlying network. For example, Chapter 2 discusses the ease with which Internet Protocol (IP) addresses in the Internet and caller ID information in the public telephone network (PTN) can be forged, and so using these for authentication would probably be imprudent. When implemented with a moderate degree of assurance, network-based authentication can be appealing. It relies on a third party—the network provider—rather than burdening end users or servers. The network provider arguably even has a business incentive to provide such a service and may be able to justify larger investments in the development of a high-assurance service than any single client of that service could. But positioning an authentication service at the network provider is not consistent with the principle of least privilege and thus is a questionable design choice.

	⁸Attempts have been made, though, to use "signatures" of analog radio devices.



	122 trust in cyberspace

	Cryptographic Authentication Secure forms of authentication for an NIS generally rely on cryptography.⁹ While many different schemes are used, all involve possession of a secret by the entity being authenticated. If this secret is compromised, then so is the authentication process. The simplest form of cryptographic authentication is based on an implicit property of encryption: if an entity does not possess the proper key, then encrypted messages sent or received by that entity decrypt into random bits. More-sophisticated forms employ cryptographic protocols—stylized exchanges between two or more parties—to authenticate callers and to distribute short-term cryptographic keys. But the design of such protocols is a subtle business, and flaws have been found in many published protocols (Abadi and Needham, 1994). A major advantage of cryptographic authentication is that it can provide continuous authentication, whereby each packet sent during a session is authenticated. The alternative is to validate the identity of an entity only at the time the authentication process is invoked (typically at the start of a session), but that alternative is vulnerable to session "hijacking" whereby an attacker impersonates a previously authenticated entity (Joncheray, 1995). As the sophistication of attackers increases, the need for continuous authentication has become more critical. Cryptographic authentication can be based on symmetric (conventional) or on asymmetric (public-key) cryptosystems. For deployment in large-scale contexts, both types of cryptosystems typically require the use of a trusted third party to act as an intermediary, and the existence of this third party constitutes a potential vulnerability. For symmetric cryptosystems, the third party (e.g., a Kerberos key-distribution center is discussed later in this chapter) is usually accessed in real time as part of the key-distribution process; for asymmetric cryptosystems, interaction with this third party (e.g., a certification authority) can be offline. Cryptographic authentication mechanisms require the possession, and thus storage, of a secret or private key. For a human user, if no auxiliary storage is available, such as a smart card or other hardware token, the secret/private key is commonly derived from a conventional password. If this is done, the cryptographic communications protected by this key can be attacked using password guessing (Gong et al., 1993). Such attacks have been reported against S/Key (Haller, 1994) and Kerberos (Neuman and Ts'o, 1994). Although techniques to guard against the attacks are known (Bellovin and Merritt, 1992; Gong et al., 1993), they are rarely employed.
	⁹Cryptographic-based authentication is usually based on authentication and integrity algorithms (e.g., digital signatures and keyed one-way hash functions, not on encryption algorithms).



	reinventing security 123

	Token-based Mechanisms An authentication technique that has gained popularity over the last few years is use of so-called hardware tokens. A number of different types of hardware tokens are available. All contain a cryptographic key in (nominally tamper-resistant) storage. Some use the key to encrypt a local (current) clock value; others use the key to transform a challenge supplied by the server; and still others execute a complete cryptographic protocol. Some sort of personal identification number (PIN) or password is usually required in order to enable a hardware token. Because an attacker is assumed not to have access to the token itself or to its memory contents, such a PIN is not susceptible to dictionary and other forms of password-guessing attacks unless the token has been stolen. Theft is further discouraged by employing a counter to trigger erasure of the hardware token's key storage after a few incorrect entries. Tokens that can be electrically connected to a user's computer, such as smart cards, Java rings, and PC cards, are often used to support cryptographic authentication protocols. The degree of tamper resistance provided by these tokens varies widely, so their resistance to attacks involving physical theft is uneven. Hardware tokens are evolving into full-fledged, personal cryptographic devices, capable of providing services beyond authentication. Biometric Techniques Biometric authentication techniques rely on presumed-unique characteristics of individuals: voice-print systems, fingerprint readers, retinal or iris scanners, and so forth. Apart from questions about the reliability of the methods themselves, principal disadvantages of biometric techniques are the cost and availability of suitable input devices and the unwillingness of people to interact with such input devices. Few computers come equipped with fingerprint-scanning hardware, and few people are willing to subject their eyes to retinal scanning. Consequently, biometric authentication is employed only in high-threat settings. When used across a network environment, cryptography must complement the biometrics, since a recording of a thumbprint transmitted across a network is just as susceptible to interception and replay as a plaintext, reusable password. As personal computers and workstations have acquired more sophisticated audio-visual interfaces, there is renewed interest in employing biometric authentication technology in the network environment. For example, a growing number of computers now come equipped with microphones, and low-cost video cameras are also becoming more common. However, a limitation is the need for security of the capture medium. For example, biometric authentication data offered by a personal computer



	124 trust in cyberspace

	could have been generated by the presumed scanning device or it could be a bit string supplied by an attacker. Thus, to the extent that it is possible to generate bit strings that appear to be valid biometric data, these systems are vulnerable. Moreover, possession of the template needed to validate a biometric scan, plus knowledge of the algorithm used to create that template, probably provides enough information to generate such bit strings (for any user whose template is compromised); disclosure of template data stored at any biometric authentication server could compromise use of that biometric technique for the affected users, forever! Findings 1. Network-based authentication technology is not amenable to high-assurance implementations. Cryptographic authentication represents a preferred approach to authentication at the granularity that might otherwise be provided by network authentication. 2. Cryptographic protocols are difficult to get right. Legitimate needs will arise for new cryptographic authentication protocols (e.g., practical multicast communication authentication), but the technology for verifying these protocols is far from mature. Further research into techniques and supporting tools should be encouraged. 3. The use of hardware tokens holds great promise for implementing authentication. Cost will be addressed by the inexorable advance of digital hardware technology. But interface commonality issues will somehow have to be overcome. The use of PINs to enable hardware tokens is a vulnerability that the use of biometrics could remove. When tokens are being used to sign data digitally, then an interface should be provided so that a user can know what is being signed. 4. Biometric authentication technologies have limitations when employed in network contexts. Still, for use in a closed NIS, biometric techniques that employ existing (or envisioned) interfaces in personal computers (e.g., microphones, low-cost cameras) are worth exploring. Cryptography and Public-Key Infrastructure It is impractical to provide strong physical, personnel, and procedural security for a geographically distributed, heterogeneously administered computing system like an NIS. Cryptographic mechanisms, however, can provide security for this setting. They have not been widely deployed, especially in large-scale distributed systems. So even where the theory is well understood, there is much to be learned about the practical aspects of deployment and use. The discussion that follows outlines some of the problems that will have to be confronted by NIS developers.



	reinventing security 125

	BOX 4.3 Basic Cryptographic Services Preserving confidentiality of data. This service is implemented by the sender encrypting the data and the receiver decrypting that data. Wiretappers see only encrypted data, which (by definition) reveals nothing about the original data. Protecting the integrity of data. This service is implemented by using a message integrity code (MIC), a relatively short (fixed-size) value computed by the sender of data and validated by the receiver. The MIC is a complex function of both the data being protected and a cryptographic key. Authenticating parties in a conversation. This service is frequently implemented using a challenge/response protocol, in which one party picks a random number and challenges the other to encrypt (or decrypt) it. Only parties with knowledge of a secret key are able to satisfy the challenge. Nonrepudiation of message origins. This service allows the receiver of a message not only to authenticate the sender but also to prove to a third party that the message came from that sender.

	The subject of cryptography ranges from foundational mathematics to applied engineering topics, and a great deal of reference material exists (Schneier, 1996; CSTB, 1996; Menezes et al., 1996). For this report, familiarity with some basic cryptographic services, as sketched in Box 4.3, will suffice. The two fundamental types of cryptographic systems are secret-key (or symmetric key) cryptography and public-key (or asymmetric key) cryptography. Secret-key cryptography has been known for thousands of years. Public-key cryptography is a relatively recent invention, first described in the public literature¹⁰ in 1976. With secret-key cryptography, the key used to encrypt a message is the same as the key used to decrypt that message, and the key used to compute the message integrity code (MIC) is the same as the key used to verify it. This means that pairs of communicating parties must share a secret, and if that secret becomes known to some third party, then that third party becomes empowered (1) to decrypt and modify messages in transit undetectably and (2) to generate spurious messages that appear to be authentic. Arranging for both parties of a conversation—and nobody else—to know a secret is one of the central challenges in cryptographic system design.

	¹⁰A recent disclosure indicates that the best-known public-key techniques were actually invented first in a classified setting several years before their development in the academic community (see <http://www.cesg.gov.uk>).



	126 trust in cyberspace

	With public-key cryptography, different keys are used to encrypt and decrypt messages, and the decryption key cannot be derived from the encryption key. Similarly, different keys are used to generate an integrity check and to verify it, and the generation key cannot be derived from the verification key. The keys used for decryption and integrity-check generation are called private keys; they are kept secret and generally known only to a single party. The keys used for encryption and integrity-check verification are called public keys; these can be freely published (hence the name "public-key cryptography"). Having separate public and private keys simplifies the distribution of keys, especially in large systems. Public-key cryptography can implement cryptographic services that cannot be built with secret-key cryptography.¹¹ For example, a digital signature is an integrity check that can be verified by any party. (An integrity check generally can be verified only by the intended recipient of a message.) Digital signatures can be implemented using public-key cryptography—a private key is used by the sender to "sign" the message and that sender's public key (which is accessible to all) is used to verify the signature—but not by using secret-key cryptography.¹² Versatility does have its cost. Public-key cryptography is considerably more (computationally) expensive to use than secret-key cryptography. Therefore, most cryptographic systems that make use of public-key cryptography are, in fact, hybrids. For confidentiality, public-key cryptography is employed to encrypt a secret key that, in turn, is used with secret-key cryptography to encrypt data. And, to compute a digital signature of a message, a digest¹³ of the message is computed and only the digest is signed. This hybrid approach minimizes the number of public-key operations required. Even so, it requires cryptographic algorithms that keep pace with communications transmission speeds.

	¹¹Note that not all public-key algorithms can offer both confidentiality protection and integrity protection. For example, the Diffie-Hellman algorithm (Diffie and Hellman, 1976) cannot support signatures, and the Digital Signature algorithm cannot support encryption. ¹²Several signature schemes have been developed based on secret-key cryptography, but they are too cumbersome to be seriously considered for "real" systems. ¹³A message digest function is more comparable to a secret-key cryptographic algorithm in its performance and technology. It computes a collision-proof fixed-length "checksum" of any message. "Collision-proof" means that it is practically impossible to find two messages with the same checksum. Because it is collision-proof, a given message digest has only one corresponding message (that one can find), and signing it is as secure as signing the entire message.



	reinventing security 127

	Findings 1. Application programming interfaces (APIs) for cryptographic services will promote greater use of such services in NISs. Cryptographic services are an extremely effective means for solving certain security problems in geographically distributed systems. 2. Faster encryption and authentication/integrity algorithms will be required to keep pace with rapidly increasing communication speeds and to deploy this technology in a wider range of applications, such as authentication, integrity, and confidentiality for multicast groups. The Key Management Problem The security of a cryptographic system depends, in large part, on the security of the methods and practices used to generate and distribute keys. For small systems, keys can be distributed by manually installing them. But this solution does not work for larger systems. There are two well-known approaches to the key-distribution problem in medium to large-scale systems: key-distribution centers (for secret-key cryptography) and certification authorities (for public-key cryptography). Key-Distribution Centers A key-distribution center (KDC) is an online automated secret-key provider. The KDC shares a secret distribution key with every party it serves, so its storage requirements are linear in the number of its clients. If client A wants to talk with client B, then that fact is communicated to the KDC. The KDC then randomly generates a new secret (session) key for A and B to use, and distributes that session key, encrypted under both the distribution key it shares with A and the distribution key it shares with B. The messages sent by the KDC must be both integrity and confidentiality protected, and they must give the identities of the parties who will be using the session key (so that each party can securely know the identity of the other). Variations of this protocol satisfy additional requirements, but all variants require that the KDC be online and all involve the KDC having access (at one time or another) to each session key generated. The requirement that the KDC be online means that to serve client systems having stringent availability requirements, the KDC itself and the communications links to it must be highly available. Because the KDC has had access to all session keys, it is an ideal target for an attacker trying to decipher previously intercepted traffic. Some KDC designs are especially vulnerable, because they employ long-term key distribution keys. Undetected KDC penetrations are



	128 trust in cyberspace

	the most serious, as the attacker is then free to impersonate any client of the KDC and (in some designs) to read old messages. Certification Authorities With public-key cryptography, the challenge is distributing the public keys in a secure fashion.¹⁴ Confidentiality is not an issue because public keys are not secret, but integrity protection is. If A wants to send an encrypted message to B and A can be misled by an attacker about B's public key, then A can be tricked into encrypting messages for B using the attacker's public key. The encrypted message would then be accessible only to the attacker. The solution is to employ a trusted third party called a certification authority (CA). The CA uses public-key cryptography to sign certificates; each certificate binds a subscriber identity to a public key. If A knows the public key of the CA and A has a CA-signed certificate binding a public key to subscriber identity B, then A can verify the CA's signature on the certificate to determine whether the certificate is genuine. And provided the CA is careful about authenticating each subscriber's identity before issuing certificates, a CA-signed certificate binding a public key to subscriber identify B becomes a reliable way for A to learn B's public key. CAs are, in some respects, easier to secure than key-distribution centers. In theory, CAs do not have to be online or highly available. A certification authority need only be available to issue certificates when new parties are being added to the system and, therefore, offline CA operation is feasible. Offline operation is even preferable, because it makes access by attackers more difficult, thereby helping to preserve CA security. But in practice, an increasing number of CAs are being operated online—fast response time for issuing certificates is important to (would-be) subscribers, and online operation is the only way to keep response time low. Even so, exploiting a compromised CA is considerably more difficult than exploiting a compromised KDC. Once a CA has been compromised, it can sign and issue bogus certificates. But that behavior in no way compromises previously signed or encrypted traffic. Moreover, if certificates are being posted publicly anyway, then a CA that suddenly posts uncharacteristically large numbers of certificates will arouse suspicion. Compromise of a CA does become problematic when certificates are used for authentication by an authorization system. Sometimes access control data are even stored in certificates. Covert compromise of a CA then can be a serious matter because the attacker can then grant access permissions.

	¹⁴Distributing the private keys, since each is known to a single party, is not necessary.



	reinventing security 129

	A certificate should be revoked whenever the corresponding private key has been compromised or the attributes that the certificate is binding to a public key are no longer accurate. For example, a certificate containing access control data must be revoked whenever access control permissions described in that certificate are changed. Implementing timely revocation of certificates requires some sort of service that is highly available, so that users can check the status of a certificate just before use. This server availability requirement somewhat offsets the arguments in favor of CAs (and public-key cryptography) over KDCs (and secret-key cryptography): the CA may not need to be highly available, but public-key cryptography, like secret-key cryptography with its KDC, does need to have some form of highly available service (for checking about revocations). Actual Deployments of Large-scale Key-Distribution Centers and Certification Authorities The U.S. DOD first developed KDC-based key management systems in the early 1970s. The STU-II secure telephone system, which served about 40,000 users, was perhaps the largest system deployed by the U.S. government that was based on KDC technology. STU-II was superseded by the STU-III system in the early 1980s; STU-III uses public-key certificates and serves more than 500,000 users. Instances of the Kerberos system (Neuman and Ts'o, 1994) and OSF/DCE (an industry standard for UNIX-based distributed systems that uses Kerberos) appear to be the largest-scale KDC deployments in the commercial sector. Pretty good privacy (PGP) (a secure e-mail technology) and Lotus Notes (a popular "groupware" product) probably represent the largest deployed public-key systems. Like OSF/DCE, Lotus Notes is usually employed on an interorganizational basis, so that the estimated 10 million certificates associated with Lotus Notes users are distributed over many organizations. Some PGP use is tied to cliques of users, but PGP also is used more globally to provide secure e-mail among an extremely broad set of users. The absence of a formal CA structure within PGP makes it difficult to determine connectivity among users. Numerous examples of inauthentic PGP keys resident in various public servers raise questions about the actual size of PGP's deployment. Web browsers employ server certificates, usually issued by public CAs (see below), in using the secure socket layer (SSL) protocol to establish encrypted, one-way, authenticated communication paths.¹⁵ This de

	¹⁵SSL also permits two-way authentication, through the use of client certificates, but this option is not often invoked.



	130 trust in cyberspace

	ployment of public-key cryptography has been crucial for providing the secure paths necessary to send credit card numbers and other sensitive data in support of e-commerce on the Internet. But the biggest demand for certificates promises to come from secure e-mail (e.g., S/MIME)¹⁶ available in version 4 of both the Netscape and Microsoft browsers and from client certificates used to authenticate users to servers. Deployment of the Secure Electronic Transaction (SET) protocol for credit card transactions over the Internet has been slower than expected, but ultimately it, too, could cause millions of certificates to be issued to the existing users of Visa, MasterCard, American Express, and Discover cards. Public-Key Infrastructure The term "public-key infrastructure" (PKI) is used in the literature, and especially in trade publications, for a collection of topics related to public-key management. Here, PKI refers to technical mechanisms, procedures, and policies that together provide a management framework for enabling public-key cryptography deployment in a range of applications: • The technical mechanisms generally include public-key digital signature and one-way hash algorithms, the syntax of public-key certificates and certificate revocation lists (CRLs), communication protocols for the issuance, reissuance, and distribution of certificates and CRLs, and algorithms for validating sequences of related certificates and associated CRLs. • The procedures generally concern issuance, reissuance, and requests for revocation of certificates, and the distribution of CRLs. • The policies encompass the semantics associated with digital signatures, the semantics of certificate issuance and revocation, the operation of certification authorities, legal liability concerns, and so on. Most of this management framework is concerned with certificates and, therefore, it is instructive to retrace their origin. When public-key cryptography was first described in the open literature, no mention was made of certificates—the public keys associated with identities were simply presumed to be available whenever needed. An MIT bachelor's thesis (Kornfelder, 1978) suggested the idea of a public-key certificate. But certificates only transform the problem of acquiring some subject's public key into the problem of acquiring some certificate issuer's public key (so that the certificate containing a subject's public key can be verified). The effort expended to acquire a certificate issuer's public key to verify a

	¹⁶See S/MIME Resources, available online at <http://www.rsa.com/smime/html/resources.html>.



	reinventing security 131

	certificate becomes leveraged if there are relatively few issuers and they sign certificates for many subjects. And most PKIs adopt this strategy. A commercial or governmental organization issues certificates to its employees, its customers, or the public in general. The organization also revokes certificates when appropriate. Notice, though, that the CA has now ascended to a somewhat more formal role in the management of certificates, concerned with preserving meaning or accuracy of the bindings in its certificates as well as with the mechanics of disseminating those bindings. Although PKIs based on CAs are the most common, they are not the only model for certificate issuance. Any user with a public key can issue a certificate whose subject is any other user. PGP works in this fashion; its certification model is called a web of trust. This user-centric model for certification has advantages. Initial deployment is especially easy, for example. But a web of trust also does not scale well to large numbers of subjects. In addition, with a diverse set of certificate issuers, certificates no longer will have a standard meaning—one user's standard of proof for issuing a certificate might not be the same as another's. Without agreement on certification policies, applications are unable to interpret certificates, and the goal of enabling deployment of public-key cryptography is undermined. Several models of PKI have started to emerge. First, companies such as VeriSign, CyberTrust, and CertCo offer PKI services to all comers. These same companies also offer so-called private-label CA services for other companies, acting as processing agents and issuing certificates on behalf of the other companies. Second, some organizations have started to issue their own certificates in support of Internet business models that call for identifying clients by certificates. Finally, there are companies issuing certificates for internal intranet use, irrespective of external customer requirements. The U.S. Postal Service has announced ambitions to become a CA on a grand scale. It has not yet realized these ambitions, but if it does, then a new category of certificate issuers will be born—one closer to government and for which new legal issues may arise and new customer benefits may be possible. Despite the competition among these models, there are good arguments (Kent, 1997) that users will require multiple certificates, issued by a variety of CAs. This suggests a world in which many CAs co-exist, both domestically and in the international environment. Given the minimal experience to date with PKIs, many aspects of PKI technology merit further research. This research should focus not only on the issuer (CA) aspects of PKI, but also on the client or consumer side. Most applications that make use of certificates, for example, have poor certificate-management interfaces for users and system administrators;



	132 trust in cyberspace

	the result is an unnecessary operational vulnerability. Toolkits for certificate processing are not much better. The development of Intel's common data security architecture (CDSA) as an application program interface (API) for a variety of cryptographic services does not alleviate the problem, as the complex issues associated with certificate validation are below the level of this specification. The CA models described all focus on binding a public key to an identity, and that identity is presumed to have some real-world semantics. Another approach to certificate use is embodied by what are called "key-centric" systems, such as the Secure Distributed Security Infrastructure (SDSI), in which all names bound to public keys are viewed as having only local significance, for the syntactic convenience of users. The Simple Public-Key Infrastructure (SPKI) working group of the Internet Engineering Task Force (IETF) is attempting to codify these notions into an Internet standard. However, no products that make use of certificates have adopted SPKI or SDSI notions. Findings 1. Obstacles exist to more widespread deployment of key management technology. Some of the obstacles are understood; others will become apparent only as large-scale deployments are attempted. 2. Although PKI technology is intended to serve very large populations with diverse administrative structures, issues related to timely notification of revocation, recovery from compromise of CA private keys, and name space management all require further attention. Network Access Control Mechanisms Operating system access control mechanisms manage the use and sharing of resources implemented and managed by that operating system. Analogous mechanisms have been developed for network resources —subnetworks, physical and logical channels, network services, and the like. Interest in such network access control mechanisms is relatively new, probably because the need for them became apparent only after networks started playing a central role. This section examines several mechanisms commonly used today to effect access control in networks and makes recommendations regarding additional research. Closed User Groups Virtual circuit data networks, such as X.25, frame relay, and asynchronous transfer mode (ATM) networks, often include a mechanism for



	reinventing security 133

	controlling whether network subscribers should be permitted to communicate. In closed user groups (CUGs), subscriber communication is controlled based on network authentication (i.e., identities represented by network layer addresses), although in some instances other information may come into play as well. For example, inbound versus outbound call initiation (and reverse charging) may be parameters to an access control list check. However, CUGs usually are limited to entities on a single network that are implemented in a single networking technology, managed by a single administration. In an Internet environment, which increasingly characterizes the networked world, the single-network restriction means that CUGs will become increasingly irrelevant.¹⁷ Virtual Private Networks Virtual private networks (VPNs) have been implemented both for data and for voice. The idea is to use a public network and to create the illusion of a network comprising transmission and switching resources that are devoted exclusively to subscribers of the VPN. The Centrex service offered by local telephone companies is one example; it is usually implemented through administrative controls in central office switches. In data networks, a VPN can be supported in a similar manner. However, VPNs implemented in this way are vulnerable to wiretapping attacks conducted on the underlying real network and to administrative configuration errors. To prevent wiretapping, cryptographic protocols can be employed at either the network or Internet layer. Many such schemes have been developed and deployed over the last 20 years, supported by government-funded programs. The first packet network VPN technology was the private line interface (PLI) developed by Bolt, Beranek, and Newman in the mid-1970s (BBN, 1978). The PLI was approved to protect classified data for transmission over the ARPANET, creating a VPN for a set of DOD Secret-level subscribers. Later examples of such technology (developed with government funding or for government use) include the BCR and Blacker (KDC-based VPN systems), the Xerox XEU and the Wang TIU (manually keyed LAN VPN systems), and the Motorola NES and Caneware (certificate-based, Internet VPN systems). In the commercial arena, various systems have also been developed and deployed, including systems for use with X.25 and ATM networks, as well as those for Internet devices. Although VPN-enabled products have been available from vendors, they typically employ proprietary proto

	¹⁷However, by relying on cryptography, a virtual private network can circumvent this single-network limitation.



	134 trust in cyberspace

	cols, making interoperability across vendor product lines difficult. Moreover, many VPN-enabled products employ manual key-management, and that prevents their deployment in larger-scale settings. The adoption of the Internet Protocol Security (IPsec) protocol standards (see Chapter 2) is expected not only to increase the number of products incorporating cryptographic VPN capabilities but also to ensure interoperability and promote the use of automated (certificate-based) key management protocols. Widespread use of VPN technology in the Internet will almost surely follow. IPsec cryptographically protects traffic between subscribers. Because IPsec operates at the Internet layer, it can protect traffic across any local area network or wide area network technology, and it can be terminated at end systems (e.g., personal computers, workstations, or servers) as well as at security gateways (e.g., firewalls). Access control in IPsec is based on cryptographic authentication, effected initially through key distribution and on a continuing basis through the use of a keyed message authentication function. The granularity of access control is determined by local policy and can range from subnet-level protection to per-user and per-application controls. IPsec is also noteworthy because it includes an optional anti-replay facility, which prevents certain forms of denial-of-service attacks. This not only has intrinsic value but also constitutes important recognition that network security is more than just an extension of access control. However, other degradation or denial-of-service attacks—namely those directed at the switching and transmission media that implement a VPN—are not prevented by IPsec, nor can they be by any VPN implementation. A VPN cannot defend against attacks directed at the resources used to build the VPN. Firewalls Firewalls (Cheswick and Bellovin, 1994; Chapman and Zwicky, 1995) are a defensive mechanism typically deployed at the boundary of a trusted and an untrusted computer network (Appendix H briefly describes the four basic kinds of firewalls). Safe—or presumed safe—messages transit the firewall; others are blocked. Thus, computers inside the boundary are protected from (some) attacks originating at computers located outside the boundary. In theory, firewalls should not be necessary. If a single computer can be hardened against attacks, then, in principle, all computers can be. And if all computers on a network are hardened, then there is no need for an additional perimeter defense. In practice, firewalls do offer benefits. First, hardening computers against attack is not simple. And systems



	reinventing security 135

	often must run commercial off-the-shelf protocols for which a perimeter defense is the only protection available. As an example, even when cryptographic authentication can be provided in a product, vendors often choose to use more vulnerable network-based authentication. For such products, users have no choice but to rely on add-on protective measures such as firewalls. A second, more subtle, benefit of firewalls concerns vulnerabilities resulting from software that contains bugs. The best cryptography in the world cannot protect a service if at one end of the connection is an attacker and at the other end is software whose bugs make compromise possible. Since today's software invariably does have bugs, with no solution in sight (see Chapter 3), prudence suggests blocking system access by outsiders. Firewalls allow access by insiders while denying access to outsiders. Third, it is easier to administer software on one or a small number of firewalls than to do so for the entire collection of workstations, personal computers, and servers composing an organization's computing network. Physical access to a computer's console might be necessary for setting or checking its configuration, for example. Moreover, a firewall can provide a network security administrator with a single point of policy control for an entire network. Thus, while configuration and policy errors on individual computers are not eliminated by deploying a firewall, its presence does reduce outside exposure and thereby prevents those errors from being exploited. Finally, firewalls often are deployed to present a defense in depth. Even if a system is believed to be secure, with proper authentication and presumed-reliable software, a firewall can provide a layer of insurance. Limitations of Firewalls Firewalls can enforce only policies defined in terms of restrictions on inbound and outbound traffic. For example, a policy stipulating that all outbound e-mail is logged could be enforced using a firewall: an authorized mail gateway (which presumably does the logging) would be the only computer whose e-mail packets are passed to the outside, and all other machines would send their e-mail to that gateway for forwarding to the outside. But there are limits to what can be accomplished using restrictions on inbound and outbound traffic. For example, an insider prevented from communicating directly with a Web server—a policy implemented by restricting outbound traffic to port 80—could set up a Web proxy server that monitors port 8000 (say) on some machine outside the firewall. Traffic to port 8000 would not be blocked by the firewall, so the insider could now surf the Web using the outside proxy. More generally, firewalls cannot protect against inside attacks (see Box 4.1). Also, using



	136 trust in cyberspace

	firewalls is pointless when paths exist to the outside that bypass those firewalls: an authorized link to some outside organization, an unprotected modem pool, or even a careless employee dialing out to an Internet Service Provider. The decision regarding what protocols are allowed to pass through the firewall is critical for success. An air gap is a more secure and cheaper solution if no protocols are being allowed to send packets through the firewall. Some protocols will be allowed through but as the number of such protocols increases, so do the chances that an attack could be waged by exploiting a flaw in one of them. The transmission of executable content provides a further challenge for firewalls. For example, macros in Microsoft Word or Excel attachments to messages can be dangerous as well as difficult to filter. Similarly, mailers (from a wide variety of vendors) are susceptible to buffer overflow attacks when overly long file names appear in attachments (CERT Advisory CA-98.10, August 1998¹⁸). A single filter, at the firewall, can protect a whole network of machines. Other limitations of firewalls come from the protocol layer at which the firewall operates. There are four basic types of firewalls: packet filters, circuit relays, application gateways, and dynamic (or stateful) packet filters. The first three correspond to layers of the protocol stack; the fourth tends to incorporate features of both network and application layer systems. Attacks conveyed using protocol layers higher than the one at which the firewall operates cannot be blocked by the firewall, because the firewall cannot filter those messages. For example, a packet-filter firewall operating at the Internet layer is unable to defend against weaknesses in an application layer protocol such as the Simple Mail Transfer Protocol (SMTP). Similarly, an application-layer firewall that did monitor SMTP packets could not protect against attacks conveyed by e-mail attachments, since such attachments only have interpretations above the layer at which SMTP operates—an e-mail application cognizant of attachment types would have to be involved in that defense. The utility of a firewall is also limited by the use of end-to-end cryptography. It is obviously impossible for a firewall to inspect the contents of an encrypted packet, so encrypted packets cannot be blocked. Similarly, address translation and other forms of packet modification that some firewalls use are not possible if a packet is going to be cryptographically authenticated. The usual solution is to terminate cryptographic associations at the firewall. In some cases, multiple levels of cryptographic protection are used, with an outer layer permitting passage through the firewall and the inner layer being end to end.

	¹⁸CERT advisories are available online at <http://www.cert.org>.



	reinventing security 137

	In addition to the intrinsic limitations of firewalls by virtue of what they do, there are pragmatic limitations by virtue of how they are built. Most firewalls are implemented as applications on top of standard operating systems and, consequently, are vulnerable to attacks directed at the underlying operating system. A firewall developer may strip out those portions of an operating system that are considered sources of vulnerabilities, but given the size and complexity of a modern operating system, only limited forms hardening will be achieved in this way. The alternative, building the firewall on a custom operating system, introduces the possibility of new vulnerabilities that have not been detected and remedied through the examination and experience of a large community of users. Perhaps for this reason and the cost, only a small number of the firewalls that have been developed employ custom operating systems. Many firewalls operate application "proxies," and all of the concerns cited later in this chapter regarding application security apply to them. Moreover, it is common for an application proxy to be developed using existing application code as a base. In such cases, vulnerabilities in the base application may be preserved in the proxy. Also, modifications to application code needed to convert it into a proxy, or an incomplete understanding of the application protocol, can be a source of vulnerabilities. Guards Guards have been used in military computing systems for two decades to control the flow of classified electronic information. Most often they are used to permit the flow of information from a lower-sensitivity environment to a higher-sensitivity enclave in support of mandatory