Appendix B Selected Topics in Computer Security Technology

This appendix discusses in considerable detail selected topics in computer security technology chosen either because they are well understood and fundamental, or because they are solutions to current urgent problems. Several sections expand on topics presented in Chapter 3.

ORANGE BOOK SECURITY

A security policy is a set of rules by which people are given access to information and/or resources. Usually these rules are broadly stated, allowing them to be interpreted somewhat differently at various levels within an organization. With regard to secure computer systems, a security policy is used to derive a security model, which in turn is used to develop the requirements, specifications, and implementation of a system.

Library Example

A "trusted system" that illustrates a number of principles related to security policy is a library. In a very simple library that has no librarian, anyone (a subject) can take out any book (an object) desired: no policy is being enforced and there is no mechanism of enforcement. In a slightly more sophisticated case, a librarian checks who should have access to the library but does not particularly care who takes out which book: the policy enforced is, "Anyone allowed in the room is allowed access to anything in the room." Such a policy requires only identification of the subject. In a third case, a simple



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 246
Computers at Risk: Safe Computing in the Information Age Appendix B Selected Topics in Computer Security Technology This appendix discusses in considerable detail selected topics in computer security technology chosen either because they are well understood and fundamental, or because they are solutions to current urgent problems. Several sections expand on topics presented in Chapter 3. ORANGE BOOK SECURITY A security policy is a set of rules by which people are given access to information and/or resources. Usually these rules are broadly stated, allowing them to be interpreted somewhat differently at various levels within an organization. With regard to secure computer systems, a security policy is used to derive a security model, which in turn is used to develop the requirements, specifications, and implementation of a system. Library Example A "trusted system" that illustrates a number of principles related to security policy is a library. In a very simple library that has no librarian, anyone (a subject) can take out any book (an object) desired: no policy is being enforced and there is no mechanism of enforcement. In a slightly more sophisticated case, a librarian checks who should have access to the library but does not particularly care who takes out which book: the policy enforced is, "Anyone allowed in the room is allowed access to anything in the room." Such a policy requires only identification of the subject. In a third case, a simple

OCR for page 246
Computers at Risk: Safe Computing in the Information Age extension of the previous one, no one is allowed to take out more than five books at a time. In a sophisticated version of this system, a librarian first determines how many books a subject already has out before allowing that subject to take more out. Such a policy requires a check of the subject's identity and current status. In a library with an even more complex policy, only certain people are allowed to access certain books. The librarian performs a check by name of who is allowed to access which books. This policy frequently involves the development of long lists of names and may evolve toward, in some cases, a negative list, that is, a list of people who should not be able to have access to specific information. In large organizations, determining which users have access to specific information frequently is based on the project they are working on or the level of sensitivity of data for which they are authorized. In each of these cases, there is an access control policy and an enforcement mechanism. The policy defines the access that an individual will have to information contained in the library. The librarian serves as the policy-enforcing mechanism. Orange Book Security Models The best-known and most widely used formal models of computer security functionality, the Bell and LaPadula model and its variants (Bell and LaPadula, 1976), emphasize confidentiality (protection from unauthorized disclosure of information) as their primary security service. In particular, these models attempt to capture the "mandatory" (what ISO Standard 7498-2 (ISO, 1989) refers to as "administratively directed, label-based") aspects of security policy. This is especially important in providing protection against "Trojan horse" software, a significant concern among those who process classified data. Mandatory controls are typically enforced by operating-system mechanisms at the relatively coarse granularity of processes and files. This state of affairs has resulted from a number of factors, several of which are noted below: The basic security models were accurately perceived to represent Department of Defense (DOD) security concerns for protecting classified information from disclosure, especially in the face of Trojan horse attacks. Since it was under the auspices of DOD funding that the work in formal security policy models was carried out, it is not surprising that the emphasis was on models that reflected DOD requirements for confidentiality. The embodiment of the model in the operating system has been

OCR for page 246
Computers at Risk: Safe Computing in the Information Age deemed essential in order to achieve a high level of assurance and to make available a secure platform on which untrusted (or less trusted) applications could be executed without fear of compromising overall system security. It was recognized early that the development of trusted software, that is, software that is trusted to not violate the security policy imposed on the computer system, is a very difficult and expensive task. This is especially true if a security policy calls for a high level of assurance in a potentially "hostile" environment, for example, execution of software from untrusted sources. The strategy evolved of developing trusted operating systems that could segregate information and processes (representing users) to allow controlled sharing of computer system resources. If trusted application software were written, it would require a trusted operating system as a platform on top of which it would execute. (If the operating system were not trusted, it, or other untrusted software, could circumvent the trusted operation of the application in question.) Thus development of trusted operating systems is a natural precursor to the development of trusted applications. At the time this strategy was developed, in the late 1960s and in the 1970s, computer systems were almost exclusively time-shared computers (mainframes or minis), and the resources to be shared (memory, disk storage, and processors) were expensive. With the advent of trusted operating systems, these expensive computing resources could be shared among users who would develop and execute applications without requiring trust in each application to enforce the system security policy. This has become an accepted model for systems in which the primary security concern is disclosure of information and in which the information is labeled in a fashion that reflects its sensitivity. The granularity at which the security policy is enforced is determined largely by characteristics of typical operating system interfaces and concerns for efficient implementation of the mechanisms that enforce security. Thus, for example, since files and processes are the objects managed by most operating systems, these were the objects protected by the security policy embodied in the operating system. In support of Bell-LaPadula, data sensitivity labels are associated with files, and authorizations for data access are associated with processes operating on behalf of users. The operating system enforces the security policy by controlling access to data based on file labels and process (user) authorizations. This type of security policy implementation is the hallmark of high-assurance systems as defined by the Orange Book. Concerning integrity in the Orange Book, note that if an integrity policy (like Clark-Wilson) and an integrity mechanism (like type enforce-

OCR for page 246
Computers at Risk: Safe Computing in the Information Age ment or rings) are then differentiated, an invariant property of mechanisms is that they enforce a "protected subsystem" kind of property. That is, they undertake to ensure that certain data is touchable only by certain code irrespective of the privileges that code inherits because of the person on whose behalf it is executing. Thus a proper integrity mechanism would ensure that one's personal privilege to update a payroll file could not be used to manipulate payroll data with a text editor, but rather that the privilege could be used only to access payroll data through the payroll subsystem, which presumably performs application-dependent consistency checks on what one does. While the Orange Book does not explicitly call out a set of integrity-based access rules, it does require that B2-level1 systems and those above execute out of a protected domain, that is, that the trusted computing base (TCB) itself be a protected subsystem. The mechanism used to do this (e.g., rings) is usually, but not always, exported to applications. Thus an integrity mechanism is generally available as a byproduct of a system operating at the B2 level. The Orange Book does not mandate mechanisms to support data integrity, but it easily could do so at the B2 level and above, because it mandates that such a mechanism exist to protect the TCB. It is now possible to devise mechanisms that protect the TCB but that cannot be made readily available to applications; however, such cases are in the minority and can be considered pathological. HARDWARE ENFORCEMENT OF SECURITY AND INTEGRITY The complexity and difficulty of developing secure applications can be reduced by modifying the hardware on which those applications run. Such modifications may add functionality to the operating system or application software, they may guarantee specific behavior that is not normally provided by conventional hardware, or they may enhance the performance of basic security functions, such as encryption. This section describes two projects that serve as worked examples of what can be accomplished when hardware is designed with security and/or integrity in mind, and what is gained or lost through such an approach. VIPER Microprocessor The VIPER microprocessor was designed specifically for high-integrity control applications at the Royal Signals and Radar Establish-

OCR for page 246
Computers at Risk: Safe Computing in the Information Age ment (RSRE), which is part of the U.K.'s Ministry of Defence (MOD). VIPER attempts to achieve high integrity with a simple architecture and instruction set designed to meet the requirements of formal verification and to provide support for high-integrity software. VIPER 1 was designed as a primitive building block that could be used to construct complete systems capable of running high-integrity applications. Its most important requirement is the ability to stop immediately if any hardware error is detected, including illegal instruction codes and numeric underflow and overflow. By stopping when an error is detected, VIPER assures that no incorrect external actions are taken following a failure. Such ''fail-stop" operation (Schlichting and Schneider, 1983) simplifies the design of higher-level algorithms used to maintain the reliability and integrity of the entire system. VIPER 1 is a memory-based processor that makes use of a uniform instruction set (i.e., all instructions are the same width). The processor has only three programmable 32-bit registers. The instruction set limits the amount of addressable memory to 1 megaword, with all access on word boundaries. There is no support for interrupts, stack processing or micro-pipelining. The VIPER 1 architecture provides only basic program support. In fact, multiplication and division are not supported directly by the hardware. This approach was taken primarily to simplify the design of VIPER, thereby allowing it to be verified. If more programming convenience is desired, it must be handled by a high-level compiler, assuming that the resulting loss in performance is tolerable. The VIPER 1A processor allows two chips to be used in tandem in an active-monitor relationship. That is, one of the chips can be used to monitor the operation of the other. This is achieved by comparing the memory and input/output (I/O) addresses generated by both chips as they are sent off-chip. If either chip detects a difference in this data, then both chips are stopped. In this model, a set of two chips is used to form a single fail-stop processor making use of a single memory module and an I/O line. It is generally accepted that VIPER's performance falls short of conventional processors' performance, and always will. Because it is being developed for high-integrity applications, the VIPER processor must always depend on well-established, mature implementation techniques and technologies. Many of the decisions about VIPER's design were made with static analysis in mind. Consequently, the instruction set was kept simple, without interrupt processing, to allow static analysis to be done effectively.

OCR for page 246
Computers at Risk: Safe Computing in the Information Age LOCK Project The LOgical Coprocessing Kernel (LOCK) Project intends to develop a secure microcomputer prototype by 1990 that provides A1-level security for general-purpose processing. The LOCK design makes use of a hardware-based reference monitor, known as SIDEARM, that can be used to build new, secure variants of existing architectures or can be included in the design of new architectures as an option. The goal is to provide the highest level of security as currently defined by National Computer Security Center (NCSC) standards, while providing 80 percent of the performance achievable by an unmodified, insecure computer. SIDEARM is designed to achieve this goal by controlling the memory references made by applications running on the processor to which it is attached. Assuming that SIDEARM is always working properly and has been integrated into the host system in a manner that guarantees its controls cannot be circumvented, it provides high assurance that applications can access data items only in accordance with a well-understood security policy. The LOCK Project centers on guaranteeing that these assumptions are valid. The SIDEARM module is the basis of the LOCK architecture and is itself an embedded computer system, making use of its own processor, memory, communications, and storage subsystems, including a laser disk for auditing. It is logically placed between the host processor and memory, and integrated into those existing host facilities, such as memory management units, that control access into memory. Since it is a separate hardware component, applications can not modify any of the security information used to control SIDEARM directly. Security policy is enforced by assigning security labels to all subjects (i.e., applications or users) and objects (i.e., data files and programs) and making security policy decisions without relying on the host system. The security policy enforced by SIDEARM includes type-enforcement controls, providing configurable, mandatory integrity. That is, "types" can be assigned to data objects and used to restrict access to subjects that are performing functions appropriate to that type. Thus type-enforcement can be used, for example, to ensure that a payroll data file is accessed only by payroll programs, or that specific transforms, such as labeling or encryption, are performed on data prior to output. Mandatory access control (MAC), discretionary access control (DAC), and type enforcement are "additive" in that a subject must pass all three criteria before being allowed to access an object. The LOCK Project makes use of multiple TEPACHE-based TYPE-I

OCR for page 246
Computers at Risk: Safe Computing in the Information Age encryption devices to safeguard SIDEARM media (security databases and audit) and data stored on host system media, and to close covert channels. As such, LOCK combines aspects of both COMSEC (communications security) and COMPUSEC (computer security) in an interdependent manner. The security provided by both approaches is critical to LOCK's proper operation. The LOCK architecture requires few but complex trusted software components, including a SIDEARM device driver and software that ensures that decisions made by the SIDEARM are enforced by existing host facilities such as a memory management unit. An important class of trusted software comprises "kernel extensions," security-critical software that runs on the host to handle machine-dependent support, such as printer and terminal security labeling, and application-specific security policies, such as that required by a database management system. Kernel extensions are protected and controlled by the reference monitor and provide the flexibility needed to allow the LOCK technology to support a wide range of applications, without becoming too large or becoming architecture-dependent. One of LOCK's advantages is that a major portion of the operating system, outside of the kernel extensions and the reference monitor, can be considered "hostile." That is, even if the operating system is corrupted, LOCK will not allow an unauthorized application to access data objects. However, parts of the operating system must still be modified or removed to make use of the functionality provided by SIDEARM. The LOCK Project intends to support the UNIX System V interface on the LOCK architecture and to attain certification of the entire system at the A1 level. CRYPTOGRAPHY Cryptography is the art of keeping data secret, primarily through the use of mathematical or logical functions that transform intelligible data into seemingly unintelligible data and back again. Cryptography is probably the most important aspect of communications security and is becoming increasingly important as a basic building block for computer security. Fundamental Concepts of Encryption Cryptography and cryptanalysis have existed for at least 2,000 years, perhaps beginning with a substitution algorithm used by Julius Caesar (Tanebaum, 1981). In his method, every letter in the original message, known now as the plaintext, was replaced by the letter that

OCR for page 246
Computers at Risk: Safe Computing in the Information Age occurred three places later in the alphabet. That is, A was replaced by D, B was replaced by E, and so on. For example, the plaintext "VENI VIDI VICI" would yield "YHQL YLGL YLFL." The resulting message, now known as the ciphertext, was then couriered to an awaiting centurion, who decrypted it by replacing each letter with the letter that occurred three places "before" it in the alphabet. The encryption and decryption algorithms were essentially controlled by the number three, which thus was the encryption and decryption key. If Caesar suspected that an unauthorized person had discovered how to decrypt the ciphertext, he could simply change the key value to another number and inform the field generals of that new value by using some other method of communication. Although Caesar's cipher is a relatively simple example of cryptography, it clearly depends on a number of essential components: the encryption and decryption algorithms, a key that is known by all authorized parties, and the ability to change the key. Figure B.1 shows the encryption process and how the various components interact. FIGURE B.1 The encryption process. If any of these components is compromised, the security of the information being protected decreases. If a weak encryption algorithm is chosen, an opponent may be able to guess the plaintext once a copy of the ciphertext is obtained. In many cases, the cryptanalyst need only know the type of encryption algorithm being used in order to break it. For example, knowing that Caesar used only a cyclic substitution of the alphabet, one could simply try every key value from 1 to 25, looking for the value that resulted in a message containing Latin words. Similarly, many encryption algorithms that appear to be very complicated are rendered ineffective by an improper choice of a key value. In a more practical sense, if the receiver forgets the key value or uses the wrong one, then the resulting message will probably be unintelligible, requiring additional effort to retransmit the message and/or the key. Finally, it is possible that the enemy will break the code even if the strongest possible combination of algorithms and key values is used. Therefore, keys and possibly even the algorithms need to be changed over a period of time to limit

OCR for page 246
Computers at Risk: Safe Computing in the Information Age the loss of security when the enemy has broken the current system. The process of changing keys and distributing them to all parties concerned is known as key management and is the most difficult aspect of security management after an encryption method has been chosen.2 In theory, any logical function can be used as an encryption algorithm. The function may act on single bits of information, single letters in some alphabet, or single words in some language or groups of words. The Caesar cipher is an example of an encryption algorithm that operates on single letters within a message. Throughout history a number of "codes" have been used in which a two-column list of words is used to define the encryption and decryption algorithms. In this case, plaintext words are located in one of the columns and replaced by the corresponding word from the other column to yield the ciphertext. The reverse process is performed to regenerate the plaintext from the ciphertext. If more than two columns are distributed, a key can be used to designate both the plaintext and ciphertext columns to be used. For example, given 10 columns, the key [3,7] might designate that the third column represents plaintext words and the seventh column represents ciphertext words. Although code books (e.g., multicolumn word lists) are convenient for manual enciphering and deciphering, their very existence can lead to compromise. That is, once a code book falls into enemy hands, ciphertext is relatively simple to decipher. Furthermore, code books are difficult to produce and to distribute, requiring accurate accounts of who has which books and which parties can communicate using those books. Consequently, mechanical and electronic devices have been developed to automate the encryption and decryption process, using primarily mathematical functions on single bits of information or single letters in a given alphabet. Private vs. Public Crypto-Systems The security of a given crypto-system depends on the amount of information known by the cryptanalyst about the algorithms and keys in use. In theory, if the encryption algorithm and keys are independent of the decryption algorithm and keys, then full knowledge of the encryption algorithm and key will not help the cryptanalyst break the code. However, in many practical crypto-systems, the same algorithm and key are used for both encryption and decryption. The security of these symmetric cipher systems depends on keeping at least the key secret from others, making such systems private-key crypto-systems. An example of a symmetric, private-key crypto-system is the Data Encryption Standard (DES) (see below, "Data Encryption Standard").

OCR for page 246
Computers at Risk: Safe Computing in the Information Age In this case, the encryption and decryption algorithm is widely known and has been widely studied; the privacy of the encryption and decryption key is relied on to ensure security. Other private-key systems have been implemented and deployed by the National Security Agency (NSA) for the protection of classified government information. In contrast to the DES, the encryption and decryption algorithms within those crypto-systems have been kept classified, to the extent that the computer chips on which they are implemented are coated in such a way as to prevent them from being examined. Users are often intolerant of private encryption and decryption algorithms because they do not know how the algorithms work or if a "trapdoor" exists that would allow the algorithm designer to read the user's secret information. In an attempt to eliminate this lack of trust, a number of crypto-systems have been developed around encryption and decryption algorithms based on fundamentally difficult problems, or one-way functions, that have been studied extensively by the research community. Another approach used in public-key systems, such as that taken by the RSA (see the section below headed "RSA"), is to show that the most obvious way to break the system involves solving a hard problem (although this means that such systems may be broken simpler means). For practical reasons, it is desirable to use different encryption and decryption keys in a crypto-system. Such asymmetric systems allow the encryption key to be made available to anyone, while preserving confidence that only people who hold the decryption key can decipher the information. These systems, which depend solely on the privacy of the decryption key, are known as public-key crypto-systems. An example of an asymmetric, public-key cipher is the patented RSA system. Digital Signatures Society accepts handwritten signatures as legal proof that a person has agreed to the terms of a contract as stated on a sheet of paper, or that a person has authorized a transfer of funds as indicated on a check. But the use of written signatures involves the physical transmission of a paper document; this is not practical if electronic communication is to become more widely used in business. Rather, a digital signature is needed to allow the recipient of a message or document to irrefutably verify the originator of that message or document. A written signature can be produced by one person (although forgeries certainly occur), but it can be recognized by many people as belong-

OCR for page 246
Computers at Risk: Safe Computing in the Information Age ing uniquely to its author. To be accepted as a replacement for a written signature, a digital signature, then, would have to be easily authenticated by anyone, but be producible only by its author. A digital signature system consists of three elements, each carrying out a procedure: The generator, which produces two numbers called the mark (which should be unforgeable) and the secret; The signer, which accepts a secret and an arbitrary sequence of bytes called the input, and produces a number called the signature; and The checker, which accepts a mark, an input, and a signature and says whether or not the signature matches the input for that mark. The procedures have the following properties: If the generator produces a mark and a secret, and the signer produces a signature when given the secret and an input, then the checker will say that the signature matches the input for that mark. If one has a mark produced by the generator but does not have the secret, then even with a large number of inputs and matching signatures for that mark, one still cannot produce an additional input and matching signature for that mark. In particular, even if the signature matches one of the inputs, one cannot produce another input that it matches. A digital signature system is useful because if one has a mark produced by the generator, as well as an input and matching signature, then one can be sure that the signature was computed by a system that knew the corresponding secret, because a system that did not know the secret could not have computed the signature. For instance, one can trust a mark to certify an uninfected program if one believes that it came from the generator, and one also believes that any system that knows the corresponding secret is one that can be trusted not to sign a program image if it is corrupted. Known methods for digital signatures are often based on computing a secure checksum (see below) of the input to be signed and then encrypting the checksum with the secret. If the encryption uses public-key encryption, the mark is the public key that matches the secret, and the checker simply decrypts the signature. For more details, see Chapter 9 in Davies and Price (1984).

OCR for page 246
Computers at Risk: Safe Computing in the Information Age passwords. However, if the random password generator is not good, breaking one may be equivalent to breaking all. At one installation, a person reconstructed the entire master list of passwords by guessing the mapping from random numbers to alphabetic passwords and inferring the random number generator (McIlroy, 1989). For that reason, the random generator must base its seed on a varying source, such as the system clock. Often the user will not find a randomly selected password acceptable because it is too difficult to memorize. This can significantly decrease the advantage of random passwords, because the user may write the password down somewhere in an effort to remember it. This may cause infinite exposure of the password, thus thwarting all attempts to maintain security. For this reason it can be helpful to give a user the option to accept or reject a password, or choose one from a list. This may increase the probability that the user will find an acceptable password. User-defined passwords can be a positive method for assigning passwords if the users are aware of the classic weaknesses. If the password is too short, say, four digits, a potential intruder can exhaust all possible password combinations and gain access quickly. That is why every system must limit the number of tries any user can make toward entering his password successfully. If the user picks very simple passwords, potential intruders can break the system by using a list of common names or a dictionary. A dictionary of 100,000 words has been shown to raise the intruder's chance of success by 50 percent (McIlroy, 1989). Specific guidelines on how to pick passwords are important if users are allowed to pick their own passwords. Voluntary password systems should guide users to never reveal their password to other users and to change their password on a regular basis, a practice that can be enforced by the system. (The NCSC's Password Management Guideline (U.S. DOD, 1985a) represents such a guideline.) Some form of access control must be provided to prevent unauthorized persons from gaining access to a password list and reading or modifying the list. One way to protect passwords in internal storage is by a one-way hash. The passwords of each user are stored as ciphertext. If the passwords were encrypted, per se, the key would be present and an attacker who gained access to the password file could decrypt them. When a user signs on and enters his password, the password is processed by the algorithm to produce the corresponding ciphertext. The plaintext password is immediately deleted, and the ciphertext version of the password is compared with the one stored in memory. The advantage of this technique is that passwords cannot be stolen from the computer (absent a lucky guess). However, a person obtaining unauthorized access could delete or change the ciphertext

OCR for page 246
Computers at Risk: Safe Computing in the Information Age passwords and effectively deny service. The file of encrypted passwords should be protected against unauthorized reading, to further foil attempts to guess passwords. The longer a password is used, the more opportunities exist for exposing it. The probability of compromise of a password increases during its lifetime. This probability is considered acceptably low for an initial time period; after a longer time period it becomes unacceptably high. There should be a maximum lifetime for all passwords. It is recommended that the maximum lifetime of a password be no greater than one year (U.S. DOD, 1985a). NETWORKS AND DISTRIBUTED SYSTEMS Security Perimeters Security is only as strong as its weakest link. The methods described above can in principle provide a very high level of security even in a very large system that is accessible to many malicious principals. But implementing these methods throughout the system is sure to be difficult and time consuming. Ensuring that they are used correctly is likely to be even more difficult. The principle of "divide and conquer" suggests that it may be wiser to divide a large system into smaller parts and to restrict severely the ways in which these parts can interact with each other. The idea is to establish a security perimeter around part of a system and to disallow fully general communication across the perimeter. Instead, there are gates in the perimeter that are carefully managed and audited and that allow only certain limited kinds of traffic (e.g., electronic mail, but not file transfers or general network "datagrams"). A gate may also restrict the pairs of source and destination systems that can communicate through it. It is important to understand that a security perimeter is not foolproof. If it passes electronic mail, then users can encode arbitrary programs or data in the mail and get them across the perimeter. But this is less likely to happen by mistake, and it is more difficult to do things inside the perimeter using only electronic mail than to do things using terminal connections or arbitrary network datagrams. Furthermore, if, for example, a mail-only perimeter is an important part of system security, users and managers will come to understand that it is dangerous and harmful to implement automated services that accept electronic mail requests. As with any security measure, a price is paid in convenience and flexibility for a security perimeter: it is harder to do things across the

OCR for page 246
Computers at Risk: Safe Computing in the Information Age perimeter. Users and managers must decide on the proper balance between security and convenience. Viruses A computer virus is a program that is hidden in another program (called its host) so that it runs whenever the host program runs, and can make a copy of itself. When a virus runs, it can do a great deal of damage. In fact, it can do anything that its host can do: delete files, corrupt data, send a message with a user's secrets to another machine, disrupt the operation of a host, waste machine resources, and so on. There are many places to hide a virus: the operating system, an executable program, a shell command file, or a macro in a spreadsheet or word processing program are only a few of the possibilities. In this respect a virus is just like a Trojan horse. And like a Trojan horse, a virus can attack any kind of computer system, from a personal computer to a mainframe. (Many of the problems and solutions discussed in this section apply equally well in a discussion of Trojan horses.) A virus can also make a copy of itself, into another program or even another machine that can be reached from the current host over a network, or by the transfer of a floppy disk or other removable medium. Like a living creature, a virus can spread quickly. If it copies itself just once a day, then after a week there will be more than 50 copies (because each copy copies itself), and after a month about a billion. If it reproduces once a minute (still slow for a computer), it takes only half an hour to make a billion copies. Their ability to spread quickly makes viruses especially dangerous. There are only two reliable methods for keeping a virus from doing harm: Make sure that every program is uninfected before it runs. Prevent an infected program from doing damage. Keeping a Virus Out Since a virus can potentially infect any program, the only sure way to keep it from running on a system is to ensure that every program run comes from a reliable source. In principle this can be done by administrative and physical means, ensuring that every program arrives on a disk in an unbroken wrapper from a trusted supplier. In

OCR for page 246
Computers at Risk: Safe Computing in the Information Age practice it is very difficult to enforce such procedures, because they rule out any kind of informal copying of software, including shareware, public domain programs, and spreadsheets written by a colleague. Moreover, there have been numerous instances of virus-infected software arriving on a disk freshly shrink-wrapped from a vendor. For this reason, vendors and at least one trade association (ADAPSO) are exploring ways to prevent contamination at the source. A more practical method uses digital signatures. Informally, a digital signature system is a procedure that one can run on a computer and that should be believed when it says, "This input data came from this source" (a more precise definition is given below). With a trusted source that is believed when it says that a program image is uninfected, one can make sure that every program is uninfected before it runs by refusing to run it unless a certificate says, "The following program is uninfected," followed by the text of the program, and the digital signature system says that the certificate came from the trusted source. Each place where this protection is applied adds to security. To make the protection complete, it should be applied by any agent that can run a program. The program image loader is not the only such agent; others include the shell, a spreadsheet program loading a spreadsheet with macros, or a word processing program loading a macro, since shell scripts, macros, and so on are all programs that can host viruses. Even the program that boots the machine should apply this protection when it loads the operating system. An important issue is distribution of the public key for verifying signatures (see "Digital Signatures," above). Preventing Damage Because there are so many kinds of programs, it may be hard to live with the restriction that every program must be certified as uninfected. This means, for example, that a spreadsheet cannot be freely copied into a system if it contains macros. Because it might be infected, an uncertified program that is run must be prevented from doing damage— leaking secrets, changing data, or consuming excessive resources. Access control can do this if the usual mechanisms are extended to specify programs, or a set of programs, as well as users. For example, the form of an access control rule could be "user A running program B can read" or "set of users C running set of programs D can read and write." Then a set of uninfected programs can be defined, namely

OCR for page 246
Computers at Risk: Safe Computing in the Information Age the ones that are certified as uninfected, and the default access control rule can be "user running uninfected" instead of "user running anything." This ensures that by default an uncertified program will not be able to read or write anything. A user can then relax this protection selectively if necessary, to allow the program access to certain files or directories. Note that strong protection on current personal computers is ultimately impossible, since they lack memory protection and hence cannot ultimately enforce access control. Yet most of the damage from viruses has involved personal computers, and protection has frequently been sought from so-called vaccine programs. Providing and Using Vaccines It is well understood how to implement the complete protection against viruses just described, but it requires changes in many places: operating systems, command shells, spreadsheet programs, programmable editors, and any other kinds of programs, as well as procedures for distributing software. These changes ought to be implemented. In the meantime, however, various stopgap measures can help somewhat. Generally known as vaccines, they are widely available for personal computers. The idea behind a vaccine is to look for traces of viruses in programs, usually by searching the program images for recognizable strings. The strings may be either parts of known viruses that have infected other systems, or sequences of instructions or operating system calls that are considered suspicious. This idea is easy to implement, and it works well against known threats (e.g., specific virus programs), but an attacker can circumvent it with only a little effort. For example, many viruses now produce pseudo-random instances of themselves using encryption. Vaccines can help, but they do not provide any security that can be relied on. They are ultimately out of date as soon as a new virus or a strain of a virus emerges. Application Gateways What a Gateway Is The term "gateway" has been used to describe a wide range of devices in the computer communication environment. Most devices described as gateways can be categorized as one of two major types, although some devices are difficult to characterize in this fashion.

OCR for page 246
Computers at Risk: Safe Computing in the Information Age The term "application gateway" usually refers to devices that convert between different protocol suites, often including application functionality, for example, conversion between DECNET and SNA protocols for file transfer or virtual terminal applications. The term "router" is usually applied to devices that relay and route packets between networks, typically operating at layer 2 (LAN bridges) or layer 3 (internetwork gateways). These devices do not convert between protocols at higher layers (e.g, layer 4 and above). Mail gateways, devices that route and relay electronic mail (a layer-7 application) may fall into either category. If the device converts between two different mail protocols, for example, X.400 and SMTP, then it is an application gateway as described above. In many circumstances an X.400 message transfer agent (MTA) will act strictly as a router, but it may also convert X.400 electronic mail to facsimile and thus operate as an application gateway. The multifaceted nature of some devices illustrates the difficulty of characterizing gateways in simple terms. Gateways as Access Control Devices Gateways are often employed to connect a network under the control of one organization (an internal network) to a network controlled by another organization (an external network such as a public network). Thus gateways are natural points at which to enforce access control policies; that is, the gateways provide an obvious security perimeter. The access control policy enforced by a gateway can be used in two basic ways: Traffic from external networks can be controlled to prevent unauthorized access to internal networks or the computer systems attached to them. This means of controlling access by outside users to internal resources can help protect weak internal systems from attack. Traffic from computers on the internal networks can be controlled to prevent unauthorized access to external networks or computer systems. This access control facility can help mitigate Trojan horse concerns by constraining the telecommunication paths by which data can be transmitted outside an organization, as well as supporting concepts such as release authority, that is, a designated individual authorized to communicate on behalf of an organization in an official capacity. Both application gateways and routers can be used to enforce access control policies at network boundaries, but each has its own advantages and disadvantages, as described below.

OCR for page 246
Computers at Risk: Safe Computing in the Information Age Application Gateways as PAC Devices Because an application gateway performs protocol translation at layer 7, it does not pass through packets at lower protocol layers. Thus, in normal operation, such a device provides a natural barrier to traffic transiting it; that is, the gateway must engage in significant explicit processing in order to convert from one protocol suite to another in the course of data transiting the device. Different applications require different protocol-conversion processing. Hence a gateway of this type can easily permit traffic for some applications to transit the gateway while preventing the transit of other traffic, simply by not providing the software necessary to perform the conversion. Thus, at the coarse granularity of different applications, such gateways can provide protection of the sort described above. For example, an organization could elect to permit electronic mail (e-mail) to pass bidirectionally by putting in place a mail gateway while preventing interactive log-in sessions and file transfers (by not passing any traffic other than e-mail). This access control policy could be refined also to permit restricted interactive log-in, for example, that initiated by an internal user to access a remote computer system, by installing software to support the translation of the virtual terminal protocol in only one direction (outbound). An application gateway often provides a natural point at which to require individual user identification and authentication information for finer-granularity access control. This is because many such gateways require human intervention to select services in translating from one protocol suite to another, or because the application being supported intrinsically involves human intervention, for example, virtual terminal or interactive database query. In such circumstances it is straightforward for the gateway to enforce access control on an individual user basis as a byproduct of establishing a "session" between the two protocol suites. Not all applications lend themselves to such authorization checks, however. For example, a file transfer application may be invoked automatically by a process during off hours, and thus no human user may be present to participate in an authentication exchange. Batch database queries or updates are similarly noninteractive and might be performed when no "users" are present. In such circumstances there is a temptation to employ passwords for user identification and authentication, as though a human being were present during the activity, and the result is that these passwords are stored in files at the initiating computer system, making them vulnerable to disclosure (see "Authentication" in Chapter 3). Thus there are limitations on the use of application gateways for individual access control.

OCR for page 246
Computers at Risk: Safe Computing in the Information Age As noted elsewhere in this report, the use of cryptography to protect user data from source to destination (end-to-end encryption) is a powerful tool for providing network security. This form of encryption is typically applied at the top of the network layer (layer 3) or the bottom of the transport layer (layer 4). End-to-end encryption cannot be employed (to maximum effectiveness) if application gateways are used along the path between communicating entities. The reason is that these gateways must, by definition, be able to access protocols at the application layer, above the layer at which the encryption is employed. Hence the user data must be decrypted for processing at the application gateway and then re-encrypted for transmission to the destination (or to another application gateway). In such an event the encryption being performed is not really end-to-end. If an application-layer gateway is part of the path for (end-to-end) encrypted user traffic, then one will, at a minimum, want the gateway to be trusted (since it will have access to the user data in clear text form). Note, however, that use of a trusted computing base (TCB) for a gateway does not necessarily result in as much security as if (uninterrupted) encryption were in force from source to destination. The physical, procedural, and emanations security of the gateway must also be taken into account as breaches of any of these security facets could subject a user's data to unauthorized disclosure or modification. Thus it may be especially difficult, if not impossible, to achieve as high a level of security for a user's data if an application gateway is traversed as the level obtainable using end-to-end encryption in the absence of such gateways. In the context of electronic mail the conflict between end-to-end encryption and application gateways is a bit more complex. The secure massaging facilities defined in X.400 (CCITT, 1989a) allow for encrypted e-mail to transit MTAs without decryption, but only when the MTAs are operating as routers rather than as application gateways, for example, when they are not performing "content conversion" or similar invasive services. The privacy-enhanced mail facilities developed for the TCP/IP Internet (Linn, 1989) incorporate encryption facilities that can transcend e-mail protocols, but only if the recipients are prepared to process the decrypted mail in a fashion that suggests protocol-layering violation. Thus, in the context of e-mail, only those devices that are more akin to routers than to application gateways can be used without degrading the security offered by true end-to-end encryption. Routers as PAC Devices Since routers can provide higher performance and greater robustness and are less intrusive than application gateways, access control

OCR for page 246
Computers at Risk: Safe Computing in the Information Age facilities that can be provided by routers are especially attractive in many circumstances. Also, user data protected by end-to-end encryption technology can pass through routers without having to be decrypted, thus preserving the security imparted by the encryption. Hence there is substantial incentive to explore access-control facilities that can be provided by routers. One way a router at layer 3 (and to a lesser extent at layer 2) can effect access control is through the use of "packet filtering" mechanisms. A router performs packet filtering by examining protocol control information (PCI) in specified fields in packets at layer 3 (and perhaps at layer 4). The router accepts or rejects (discards) a packet based on the values in the fields as compared to a profile maintained in an access-control database. For example, source and destination computer system addresses are contained in layer-3 PCI, and thus an administrator could authorize or deny the flow of data between a pair of computer systems based on examination of these address fields. If one "peeks" into layer-4 PCI, an eminently feasible violation of protocol layering for many layer-3 routers, one can effect somewhat finer-grained access control in some protocol suites. For example, in the TCP/IP suite one can distinguish among electronic mail, virtual terminal, and several other types of common applications through examination of certain fields in the TCP header. However, one cannot ascertain which specific application is being accessed via a virtual terminal connection, and so the granularity of such access control may be more limited than in the context of application gateways. Several vendors of layer-3 routers already provide facilities of this sort for the TCP/IP community, so that this is largely an existing access-control technology. As noted above, there are limitations to the granularity of access control achievable with packet filtering. There is also a concern as to the assurance provided by this mechanism. Packet filtering relies on the accuracy of certain protocol control information in packets. The underlying assumption is that if this header information is incorrect, then packets will probably not be correctly routed or processed, but this assumption may not be valid in all cases. For example, consider an access-control policy that authorizes specified computers on an internal network to communicate with specified computers on an external network. If one computer system on the internal network can masquerade as another authorized internal system (by constructing layer-3 PCI with incorrect network addresses), then this access-control policy could be subverted. Alternatively, if a computer system on an external network generates packets with false addresses, it too can subvert the policy. Other schemes have been developed to provide more sophisticated

OCR for page 246
Computers at Risk: Safe Computing in the Information Age access-control facilities with higher assurance, while still retaining most of the advantages of router-enforced access control. For example, the VISA system (Estrin and Tsudik, 1987) requires a computer system to interact with a router as part of an explicit authorization process for sessions across organizational boundaries. This scheme also employs a cryptographic checksum applied to each packet (at layer 3) to enable the router to validate that the packet is authorized to transit the router. Because of performance concerns, it has been suggested that this checksum be computed only over the layer-3 PCI, instead of the whole packet. This would allow information surreptitiously tacked onto an authorized packet PCI to transit the router. Thus even this more sophisticated approach to packet filtering at routers has security shortcomings. Conclusions About Gateways Both application gateways and routers can be used to enforce access control at the interfaces between networks administered by different organizations. Application gateways, by their nature, tend to exhibit reduced performance and robustness, and are less transparent than routers, but they are essential in the heterogeneous protocol environments in which much of the world operates today. As national and international protocol standards become more widespread, there will be less need for such gateways. Thus, in the long term, it would be disadvantageous to adopt security architectures that require that interorganizational access control (across network boundaries) be enforced through the use of such gateways. The incompatibility between true end-to-end encryption and application gateways further argues against such access-control mechanisms for the long term. However, in the short term, especially in circumstances where application gateways are required due to the use of incompatible protocols, it is appropriate to exploit the opportunity to implement perimeter access controls in such gateways. Over the long term, more widespread use of trusted computer systems is anticipated, and thus the need for gateway-enforced perimeter access control to protect these computer systems from unauthorized external access will diminish. It is also anticipated that increased use of end-to-end encryption mechanisms and associated access control facilities will provide security for end-user data traffic. Nonetheless, centrally managed access control for interorganizational traffic is a facility that may best be accomplished through the use of gateway-based access control. If further research can provide higher-assurance packet-filtering facilities in routers, the resulting system, in combination with trusted computing systems for

OCR for page 246
Computers at Risk: Safe Computing in the Information Age end users and end-to-end encryption, would yield significantly improved security capabilities in the long term. NOTES 1.   See TCSEC Section 3.2.3.1.1 (U.S. DOD, 1985d). 2.   To appreciate cryptography, note that we do not always understand what ''information" is. Information, in the sense of semantic content, is always in the mind of the beholder and is a combination of ordinary symbols (e.g., "East Wind, Rain") or extraordinary ones (e.g., Wehrmacht beer orders) and some richer context. To differentiate, "data" is an encoding, and "information" is the (always to some degree unknowable) meaning that the encoding may or may not convey to a human observer. With regard to automata, "information" refers to data that alters the behavior of the robots. For example, the string RDAQN QRHIH FECCA DRSWV KIKSS HSPAX CUBS conveys 34 characters of data to everyone who has "read" access to this transaction but conveys a significant amount of information only to those who know the richer context of cryptosystem and key. Readers are invited to determine the key from the substantial hint that the plaintext is THERE ARE MORE THINGS IN HEAVEN AND EARTH; solutions may be verified by transforming RCVQD ALCFV CLLLL DLSCK KRVKT BRVAO AVUA from data to information. 3.   The security of RSA is not known to be provably equivalent to the problem of factoring the modulus, although that seems to be the best way to attack it.