Concepts of Information Security
This chapter discusses security policies in the context of requirements for information security and the circumstances in which those requirements must be met, examines common principles of management control, and reviews typical system vulnerabilities, in order to motivate consideration of the specific sorts of security mechanisms that can be built into computer systems—to complement nontechnical management controls and thus implement policy—and to stress the significance of establishing GSSP. Additional information on privacy issues and detailing the results of an informal survey of commercial security officers is provided in the two chapter appendixes.
Organizations and people that use computers can describe their needs for information security and trust in systems in terms of three major requirements:
Confidentiality: controlling who gets to read information;
Integrity: assuring that information and programs are changed only in a specified and authorized manner; and
Availability: assuring that authorized users have continued access to information and resources.
These three requirements may be emphasized differently in various applications. For a national defense system, the chief concern may be ensuring the confidentiality of classified information, whereas a funds transfer system may require strong integrity controls. The requirements for applications that are connected to external systems will differ from those for applications without such interconnection. Thus the specific requirements and controls for information security can vary.
The framework within which an organization strives to meet its needs for information security is codified as security policy. A security policy is a concise statement, by those responsible for a system (e.g., senior management), of information values, protection responsibilities, and organizational commitment. One can implement that policy by taking specific actions guided by management control principles and utilizing specific security standards, procedures, and mechanisms. Conversely, the selection of standards, procedures, and mechanisms should be guided by policy to be most effective.
To be useful, a security policy must not only state the security need (e.g., for confidentiality—that data shall be disclosed only to authorized individuals), but also address the range of circumstances under which that need must be met and the associated operating standards. Without this second part, a security policy is so general as to be useless (although the second part may be realized through procedures and standards set to implement the policy). In any particular circumstance, some threats are more probable than others, and a prudent policy setter must assess the threats, assign a level of concern to each, and state a policy in terms of which threats are to be resisted. For example, until recently most policies for security did not require that security needs be met in the face of a virus attack, because that form of attack was uncommon and not widely understood. As viruses have escalated from a hypothetical to a commonplace threat, it has become necessary to rethink such policies in regard to methods of distribution and acquisition of software. Implicit in this process is management's choice of a level of residual risk that it will live with, a level that varies among organizations.
Management controls are the mechanisms and techniques—administrative, procedural, and technical—that are instituted to implement a security policy. Some management controls are explicitly concerned with protecting information and information systems, but the concept of management controls includes much more than a computer's specific role in enforcing security. Note that management controls not only are used by managers, but also may be exercised by users. An effective program of management controls is needed to cover all aspects of information security, including physical security, classification of information, the means of recovering from breaches of security, and above all training to instill awareness and acceptance by people. There are trade-offs among controls. For example, if technical controls are not available, then procedural controls might be used until a technical solution is found.
Technical measures alone cannot prevent violations of the trust people place in individuals, violations that have been the source of
much of the computer security problem in industry to date (see Chapter 6). Technical measures may prevent people from doing unauthorized things but cannot prevent them from doing things that their job functions entitle them to do. Thus, to prevent violations of trust rather than just repair the damage that results, one must depend primarily on human awareness of what other human beings in an organization are doing. But even a technically sound system with informed and watchful management and users cannot be free of all possible vulnerabilities. The residual risk must be managed by auditing, backup, and recovery procedures supported by general alertness and creative responses. Moreover, an organization must have administrative procedures in place to bring peculiar actions to the attention of someone who can legitimately inquire into the appropriateness of such actions, and that person must actually make the inquiry. In many organizations, these administrative provisions are far less satisfactory than are the technical provisions for security.
A major conclusion of this report is that the lack of a clear articulation of security policy for general computing is a major impediment to improved security in computer systems. Although the Department of Defense (DOD) has articulated its requirements for controls to ensure confidentiality, there is no articulation for systems based on other requirements and management controls (discussed below)—individual accountability, separation of duty, auditability, and recovery. This committee's goal of developing a set of Generally Accepted System Security Principles, GSSP, is intended to address this deficiency and is a central recommendation of this report.
In computing there is no generally accepted body of prudent practice analogous to the Generally Accepted Accounting Principles promulgated by the Financial Auditing Standards Board (see Appendix D). Managers who have never seen adequate controls for computer systems may not appreciate the capabilities currently available to them, or the risks they are taking by operating without these controls. Faced with demands for more output, they have had no incentive to spend money on controls. Reasoning like the following is common: "Can't do it and still stay competitive"; "We've never had any trouble, so why worry"; "The vendor didn't put it in the product; there's nothing we can do."
On the basis of reported losses, such attitudes are not unjustified (Neumann, 1989). However, computers are active entities, and programs can be changed in a twinkling, so that past happiness is no predictor of future bliss. There has to be only one Internet worm incident to signal a larger problem. Experience since the Internet worm involving copy-cat and derivative attacks shows how a possibility once demonstrated can become an actuality frequently used.1
Some consensus does exist on fundamental or minimum-required security mechanisms. A recent informal survey conducted on behalf of the committee shows a widespread desire among corporate system managers and security officers for the ability to identify users and limit times and places of access, particularly over networks, and to watch for intrusion by recording attempts at invalid actions (see Chapter Appendix 2.2). Ad hoc virus checkers, well known in the personal computer market, are also in demand. However, there is little demand for system managers to be able to obtain positive confirmation that the software running on their systems today is the same as what was running yesterday. Such a simple analog of hardware diagnostics should be a fundamental requirement; it may not be seen as such because vendors do not offer it or because users have difficulty expressing their needs.
Although threats and policies for addressing them are different for different applications, they nevertheless have much in common, and the general systems on which applications are built are often the same. Furthermore, basic security services can work against many threats and support many policies. Thus there is a large core of policies and services on which most of the users of computers should be able to agree. On this basis the committee proposes the effort to define and articulate GSSP.
SECURITY POLICIES-RESPONDING TO REQUIREMENTS FOR CONFIDENTIALITY, INTEGRITY, AND AVAILABILITY
The weight given to each of the three major requirements describing needs for information security—confidentiality, integrity, and availability—depends strongly on circumstances. For example, the adverse effects of a system not being available must be related in part to requirements for recovery time. A system that must be restored within an hour after disruption represents, and requires, a more demanding set of policies and controls than does a similar system that need not be restored for two to three days. Likewise, the risk of loss of confidentiality with respect to a major product announcement will change with time. Early disclosure may jeopardize competitive advantage, but disclosure just before the intended announcement may be insignificant. In this case the information remains the same, while the timing of its release significantly affects the risk of loss.
Confidentiality is a requirement whose purpose is to keep sensitive information from being disclosed to unauthorized recipients. The
secrets might be important for reasons of national security (nuclear weapons data), law enforcement (the identities of undercover drug agents), competitive advantage (manufacturing costs or bidding plans), or personal privacy (credit histories) (see Chapter Appendix 2.1).
The most fully developed policies for confidentiality reflect the concerns of the U.S. national security community, because this community has been willing to pay to get policies defined and implemented (and because the value of the information it seeks to protect is deemed very high). Since the scope of threat is very broad in this context, the policy requires systems to be robust in the face of a wide variety of attacks. The specific DOD policies for ensuring confidentiality do not explicitly itemize the range of expected threats for which a policy must hold. Instead, they reflect an operational approach, expressing the policy by stating the particular management controls that must be used to achieve the requirement for confidentiality. Thus they avoid listing threats, which would represent a severe risk in itself, and avoid the risk of poor security design implicit in taking a fresh approach to each new problem.
The operational controls that the military has developed in support of this requirement involve automated mechanisms for handling information that is critical to national security. Such mechanisms call for information to be classified at different levels of sensitivity and in isolated compartments, to be labeled with this classification, and to be handled by people cleared for access to particular levels and/or compartments. Within each level and compartment, a person with an appropriate clearance must also have a "need to know" in order to gain access. These procedures are mandatory: elaborate procedures must also be followed to declassify information.2
Classification policies exist in other settings, reflecting a general recognition that to protect assets it is helpful to identify and categorize them. Some commercial firms, for instance, classify information as restricted, company confidential, and unclassified (Schmitt, 1990). Even if an organization has no secrets of its own, it may be obliged by law or common courtesy to preserve the privacy of information about individuals. Medical records, for example, may require more careful protection than does most proprietary information. A hospital must thus select a suitable confidentiality policy to uphold its fiduciary responsibility with respect to patient records.
In the commercial world confidentiality is customarily guarded by security mechanisms that are less stringent than those of the national security community. For example, information is assigned to an "owner" (or guardian), who controls access to it.3 Such security mechanisms are capable of dealing with many situations but are not as resistant to certain attacks as are mechanisms based on classification and manda-
tory labeling, in part because there is no way to tell where copies of information may flow. With Trojan horse attacks, for example, even legitimate and honest users of an owner mechanism can be tricked into disclosing secret data. The commercial world has borne these vulnerabilities in exchange for the greater operational flexibility and system performance currently associated with relatively weak security.
Integrity is a requirement meant to ensure that information and programs are changed only in a specified and authorized manner. It may be important to keep data consistent (as in double-entry bookkeeping) or to allow data to be changed only in an approved manner (as in withdrawals from a bank account). It may also be necessary to specify the degree of the accuracy of data.
Some policies for ensuring integrity reflect a concern for preventing fraud and are stated in terms of management controls. For example, any task involving the potential for fraud must be divided into parts that are performed by separate people, an approach called separation of duty. A classic example is a purchasing system, which has three parts: ordering, receiving, and payment. Someone must sign off on each step, the same person cannot sign off on two steps, and the records can be changed only by fixed procedures—for example, an account is debited and a check written only for the amount of an approved and received order. In this case, although the policy is stated operationally—that is, in terms of specific management controls—the threat model is explicitly disclosed as well.
Other integrity policies reflect concerns for preventing errors and omissions, and controlling the effects of program change. Integrity policies have not been studied as carefully as confidentiality policies. Computer measures that have been installed to guard integrity tend to be ad hoc and do not flow from the integrity models that have been proposed (see Chapter 3).
Availability is a requirement intended to ensure that systems work promptly and service is not denied to authorized users. From an operational standpoint, this requirement refers to adequate response time and/or guaranteed bandwidth. From a security standpoint, it represents the ability to protect against and recover from a damaging event. The availability of properly functioning computer systems (e.g., for routing long-distance calls or handling airline reservations) is essential to the operation of many large enterprises and sometimes
for preserving lives (e.g., air traffic control or automated medical systems). Contingency planning is concerned with assessing risks and developing plans for averting or recovering from adverse events that might render a system unavailable.
Traditional contingency planning to ensure availability usually includes responses only to acts of God (e.g., earthquakes) or accidental anthropogenic events (e.g., a toxic gas leak preventing entry to a facility). However, contingency planning must also involve providing for responses to malicious acts, not simply acts of God or accidents, and as such must include an explicit assessment of threat based on a model of a real adversary, not on a probabilistic model of nature.
For example, a simple availability policy is usually stated like this: "On the average, a terminal shall be down for less than 10 minutes per month." A particular terminal (e.g., an automatic teller machine or a reservation agent's keyboard and screen) is up if it responds correctly within one second to a standard request for service; otherwise it is down. This policy means that the up time at each terminal, averaged over all the terminals, must be at least 99.98 percent.
A security policy to ensure availability usually takes a different form, as in the following example: "No inputs to the system by any user who is not an authorized administrator shall cause the system to cease serving some other user." Note that this policy does not say anything about system failures, except to the extent that they can be caused by user actions. Instead, it identifies a particular threat, a malicious or incompetent act by a regular user of the system, and requires the system to survive this act. It says nothing about other ways in which a hostile party could deny service, for example, by cutting a telephone line; a separate assertion is required for each such threat, indicating the extent to which resistance to that threat is deemed important.
Examples of Security Requirements for Different Applications
The exact security needs of systems will vary from application to application even within a single application. As a result, organizations must both understand their applications and think through the relevant choices to achieve the appropriate level of security.
An automated teller system, for example, must keep personal identification numbers (PINs) confidential, both in the host system and during transmission for a transaction. It must protect the integrity of account records and of individual transactions. Protection of privacy is important, but not critically so. Availability of the host system is important to the economic survival of the bank, although not to its fiduciary responsibility. As compared to the availability of
the host system, the availability of individual teller machines is of less concern.
A telephone switching system, on the other hand, does not have high requirements for integrity on individual transactions, as lasting damage will not be incurred by occasionally losing a call or billing record. The integrity of control programs and configuration records, however, is critical. Without these, the switching function would be defeated and the most important attribute of all—availability—would be compromised. A telephone switching system must also preserve the confidentiality of individual calls, preventing one caller from overhearing another.
Security needs are determined more by what a system is used for than by what it is. A typesetting system, for example, will have to assure confidentiality if it is being used to publish corporate proprietary material, integrity if it is being used to publish laws, and availability if it is being used to publish a daily paper. A general-purpose time-sharing system might be expected to provide confidentiality if it serves diverse clientele, integrity if it is used as a development environment for software or engineering designs, and availability to the extent that no one user can monopolize the service and that lost files will be retrievable.
MANAGEMENT CONTROLS-CHOOSING THE MEANS TO SECURE INFORMATION AND OPERATIONS
The setting of security policy is a basic responsibility of management within an organization. Management has a duty to preserve and protect assets and to maintain the quality of service. To this end it must assure that operations are carried out prudently in the face of realistic risks arising from credible threats. This duty may be fulfilled by defining high-level security policies and then translating these policies into specific standards and procedures for selecting and nurturing personnel, for checking and auditing operations, for establishing contingency plans, and so on. Through these actions, management may prevent, detect, and recover from loss. Recovery depends on various forms of insurance: backup records, redundant systems and service sites, self-insurance by cash reserves, and purchased insurance to offset the cost of recovery.
Preventing Breaches of Security—Basic Principles
Management controls are intended to guide operations in proper directions, prevent or detect mischief and harmful mistakes, and give
early warning of vulnerabilities. Organizations in almost every line of endeavor have established controls based on the following key principles:
Separation of duty.
These principles, recognized in some form for centuries, are the basis of precomputer operating procedures that are very well understood.
Individual accountability answers the question: Who is responsible for this statement or action? Its purpose is to keep track of what has happened, of who has had access to information and resources and what actions have been taken. In any real system there are many reasons why actual operation may not always reflect the original intentions of the owners: people make mistakes, the system has errors, the system is vulnerable to certain attacks, the broad policy was not translated correctly into detailed specifications, the owners changed their minds, and so on. When things go wrong, it is necessary to know what has happened, and who is the cause. This information is the basis for assessing damage, recovering lost information, evaluating vulnerabilities, and initiating compensating actions, such as legal prosecution, outside the computer system.
To support the principle of individual accountability, the service called user authentication is required. Without reliable identification, there can be no accountability. Thus authentication is a crucial underpinning of information security. Many systems have been penetrated when weak or poorly administered authentication services have been compromised, for example, by guessing poorly chosen passwords.
The basic service provided by authentication is information that a statement or action was made by a particular user. Sometimes, however, there is a need to ensure that the user will not later be able to claim that a statement attributed to him was forged and that he never made it. In the world of paper documents, this is the purpose of notarizing a signature; the notary provides independent and highly credible evidence, which will be convincing even after many years, that a signature is genuine and not forged. This more stringent form of authentication, called nonrepudiation, is offered by few computer systems today, although a legal need for it can be foreseen as computer-mediated transactions become more common in business.
Auditing services support accountability and therefore are valuable to management and to internal or external auditors. Given the reality that every computer system can be compromised from within,
and that many systems can also be compromised if surreptitious access can be gained, accountability is a vital last resort. Auditing services make and keep the records necessary to support accountability. Usually they are closely tied to authentication and authorization (a service for determining whether a user or system is trusted for a given purpose—see discussion below), so that every authentication is recorded, as is every attempted access, whether authorized or not. Given the critical role of auditing, auditing devices are sometimes the first target of an attacker and should be protected accordingly.
A system's audit records, often called an audit trail, have other potential uses besides establishing accountability. It may be possible, for example, to analyze an audit trail for suspicious patterns of access and so detect improper behavior by both legitimate users and masqueraders. The main drawbacks are processing and interpreting the audit data.
Systems may change constantly as personnel and equipment come and go and applications evolve. From a security standpoint, a changing system is not likely to be an improving system. To take an active stand against gradual erosion of security measures, one may supplement a dynamically collected audit trail (which is useful in ferreting out what has happened) with static audits that check the configuration to see that it is not open for attack. Static audit services may check that software has not changed, that file access controls are properly set, that obsolete user accounts have been turned off, that incoming and outgoing communications lines are correctly enabled, that passwords are hard to guess, and so on. Aside from virus checkers, few static audit tools exist in the market.
The well-established practice of separation of duty specifies that important operations cannot be performed by a single person but instead require the agreement of (at least) two different people. Separation of duty thus strengthens security by preventing any single-handed subversion of the controls. It can also help reduce errors by providing for an independent check of one person's actions by another.
Separation of duty is an example of a broader class of controls that attempt to specify who is trusted for a given purpose. This sort of control is generally known as user authorization. Authorization determines whether a particular user, who has been authenticated as the source of a request to do something, is trusted for that operation. Authorization may also include controls on the time at which something can be done (only during working hours) or the computer terminal from which it can be requested (only the one on the manager's desk).
Just as the goal of individual accountability requires a lower-level mechanism for user authentication, so also do authorization controls such as separation of duty require a lower-level mechanism to ensure
that users have access only to the correct objects. Inside the computer, these enforcement mechanisms are usually called access control mechanisms.
Responding to Breaches of Security
Recovery controls provide the means to respond to, rather than prevent, a security breach. The use of a recovery mechanism does not necessarily indicate a system shortcoming; for some threats, detection and recovery may well be more cost-effective than attempts at total prevention. Recovery from a security breach may involve taking disciplinary or legal action, notifying incidentally compromised parties, or changing policies, for example. From a technical standpoint, a security breach has much in common with a failure that results from faulty equipment, software, or operations. Usually some work will have to be discarded, and some or all of the system will have to be rolled back to a clean state.
Security breaches usually entail more recovery effort than do acts of God. Unlike proverbial lightning, breaches of security can be counted on to strike twice unless the route of compromise has been shut off. Causes must be located. Were passwords compromised? Are backups clean? Did some user activity compromise the system by mistake? And major extra work—changing all passwords, rebuilding the system from original copies, shutting down certain communication links or introducing authentication procedures on them, or undertaking more user education—may have to be done to prevent a recurrence.
DEVELOPING POLICIES AND APPROPRIATE CONTROLS
Ideally a comprehensive spectrum of security measures would ensure that the confidentiality, integrity, and availability of computer-based systems were appropriately maintained. In practice it is not possible to make ironclad guarantees. The only recipe for perfect security is perfect isolation: nothing in, nothing out. This is impractical, and so security policies will always reflect trade-offs between cost and risk. The assets to be protected should be categorized by value, the vulnerabilities by importance, and the risks by severity, and defensive measures should be installed accordingly. Residual vulnerabilities should be recognized.
Planning a security program is somewhat like buying insurance. An organization considers the following:
The value of the assets being protected.
The vulnerabilities of the system: possible types of compro-
mise, of users as well as systems. What damage can the person in front of the automated teller machine do? What about the person behind it?4
Threats: do adversaries exist to exploit these vulnerabilities? Do they have a motive, that is, something to gain? How likely is attack in each case?
Risks: the costs of failures and recovery. What is the worst credible kind of failure? Possibilities are death, injury, compromise to national security, industrial espionage, loss of personal privacy, financial fraud, election fraud.
The organization's degree of risk aversion.
Thence follows a rough idea of expected losses. On the other side of the ledger are these:
Available countermeasures (controls and security services),
Their effectiveness, and
Their direct costs and the opportunity costs of installing them.
The security plans then become a business decision, possibly tempered by legal requirements and consideration of externalities (see ''Risks and Vulnerabilities," below).
Ideally, controls are chosen as the result of careful analysis.5 In practice, the most important consideration is what controls are available. Most purchasers of computer systems cannot afford to have a system designed from scratch to meet their needs, a circumstance that seems particularly true in the case of security needs. The customer is thus reduced to selecting from among the various preexisting solutions, with the hope that one will match the identified needs.
Some organizations formalize the procedure for managing computer-associated risk by using a control matrix that identifies appropriate control measures for given vulnerabilities over a range of risks. Using such a matrix as a guide, administrators may better select appropriate controls for various resources. A rough cut at addressing the problem is often taken: How much business depends on the system? What is the worst credible kind of failure, and how much would it cost to recover? Do available mechanisms address possible causes? Are they cost-effective?
The computer industry can be expected to respond to clearly articulated security needs provided that such needs apply to a broad enough base of customers. This has happened with the Orange Book visà vis the defense community—but slowly, because vendors were not convinced the customer base was large enough to warrant accelerated investments in trust technology.
However, for many of the management controls discussed above,
there is not a clear, widely accepted articulation of how computer systems should be designed to support these controls, what sort of robustness is required in the mechanisms, and so on. As a result, customers for computer security are faced with a "take-it-or-leave-it" marketplace. For instance, customers appear to demand password-based authentication because it is available, not because analysis has shown that this relatively weak mechanism provides enough protection. This effect works in both directions: a service is not demanded if it is not available, but once it becomes available somewhere, it soon becomes wanted everywhere. See Chapter 6 for a discussion of the marketplace.
RISKS AND VULNERABILITIES
Risks arise because an attack could exploit some system vulnerability (see, for example, Boxes 2.1 and 2.2). That is, each vulnerability of a system reflects a potential threat, with corresponding risks. In a sampling of a collection of over 3,000 cases of computer system abuse, drawn from the media and personal reporting, the following types of attack, listed roughly in order of decreasing frequency, predominated (Neumann and Parker, 1989):
Misusing authority, through activities such as improper acquisition of resources (reading of data, theft of programs), surreptitious modification, and denials of service, apparently by authorized users.
Masquerading, as in one user impersonating another.
Bypassing intended controls, by means such as password attacks and exploitation of trapdoors. These attacks typically exploit system flaws or hidden circumventive "features."
Setting up subsequent abuses such as Trojan horses, logic bombs, or viruses.
Carrying out hardware and media abuses, such as physical attacks on equipment and scavenging of information from discarded media. (Electronic interference and eavesdropping also belong in this class but have not been widely detected.)
Using a computer system as an indirect aid in committing a criminal act, as in auto-dialing telephone numbers in search of answering modems, cracking another system's encrypted password files, or running an illicit business. (For example, drug operations are becoming increasingly computerized.)
The cases considered in the sampling cited above often involved multiple classes of abuse. In attacking the National Aeronautics and Space Administration systems, the West German Chaos Computer
BOX 2.1 THE WILY HACKER
In August 1986, Clifford Stoll, an astronomer working at the Lawrence Berkeley Laboratory, detected an intruder, nicknamed him the Wily Hacker, and began to monitor his intrusions. Over a period of 10 months, the Wily Hacker attacked roughly 450 computers operated by the U.S. military and its contractors, successfully gaining access to 30 of them. Prior to detection, he is believed to have mounted attacks for as long as a year.
Although originally thought to be a local prankster, the Wily Hacker turned out to be a competent and persistent computer professional in West Germany, with alleged ties to the Soviet KGB, and possibly with confederates in Germany.* It is assumed that the Wily Hacker was looking for classified or sensitive data on each of the systems he penetrated, although regulations prohibit the storage of classified data on the systems in question.
Looking for technological keywords and for passwords to other systems, the Wily Hacker exhaustively searched the electronic files and messages located on each system. He carefully concealed his presence on the computer systems and networks that he penetrated, using multiple entry points as necessary. He made long-term plans, in one instance establishing a trapdoor that he used almost a year later.
The most significant aspect of the Wily Hacker incident is that the perpetrator was highly skilled and highly motivated. Also notable is the involvement of a U.S. accomplice. Tracking the Wily Hacker required the cooperation of more than 15 organizations, including U.S. authorities, German authorities, and private corporations. The treatment of the Wily Hacker by German authorities left some in the United States unsatisfied, because under German law the absence of damage to German systems and the nature of the evidence available diminished sentencing options.
SOURCES: Stoll (1988); Markoff (1988a).
Club masqueraded, bypassed access controls (partly by exploiting a subtle operating system flaw), and used Trojan horses to capture passwords. The Internet worm of November 1988 exploited weak password mechanisms and design and implementation flaws in mail-handling and information-service programs to propagate itself from machine to machine (Rochlis and Eichin, 1989; Spafford, 1989a,b). Personal computer pest programs typically use Trojan horse attacks, some with virus-like propagation.
The preceding summary of penetrations gives a good view of the
present situation. However, it is unwise to extrapolate from the present to predict the classes of vulnerability that will be significant in the future. As expertise and interconnection increase and as control procedures improve, the risks and likely threats will change.6 For example, given recent events, the frequency of Trojan horse and virus attacks is expected to increase.
Interconnection results in the vulnerability of weak links endangering other parts of an interconnected system. This phenomenon is particularly insidious when different parts of a system fall under different managements with different assessments of risk. For example, suppose computer center A used by students determines that the expected costs of recovery from plausible attacks do not justify the costs of protective measures. The center has data connections to a more sensitive government-sponsored research center B, to which some students have access. By computer eavesdropping at the student-center end, an invisible intruder learns passwords to the research installation. Somewhat paradoxically, the low guard kept at center A forces B to introduce more rigorous and costly measures to protect the supposedly innocuous communications with A than are necessary for genuinely sensitive communications with installations that are as cautious as B.
Such scenarios have been played out many times in real life. In saving money for itself, installation A has shifted costs to B, creating what economists call an externality. At the very least, it seems, installation B should be aware of the security state of A before agreeing to communicate.
System interconnection may even affect applications that do not involve communication at all: the risks of interconnection are borne not only by the applications they benefit, but also by other applications that share the same equipment. In the example given above, some applications at installation B may need to be apprised of the security state of installation A even though they never overtly communicate with A.
In some sectors, the recognition of interdependence has already affected the choice of safeguard. For example, a national funds transfer system may depend on communications lines provided by a common carrier. It is common commercial practice to trust that common carriers transmit faithfully, but for funds transfer such trust is judged to be imprudent, and cryptographic methods are used to ensure that the carrier need not be trusted for the integrity of funds transfer (although it is still trusted to ensure availability). The alternative would have been to include the carriers within the trusted funds transfer system, and work to ensure that they transmit faithfully.
BOX 2.2 THE INTERNET WORM
The Internet, an international network of computer systems that has evolved over the last decade, provides electronic mail, file transfer, and remote log-in capabilities. Currently, the Internet interconnects several thousand individual networks (including government, commercial, and academic networks) that connect some 60,000 computers. The Internet has become the electronic backbone for computer research, development, and user communities.
On November 2, 1988, the Internet was attacked by a self-replicating program called a worm that spread within hours to somewhere between 2,000 and 6,000 computer systems—the precise number remains uncertain. Only systems (VAX and Sun 3) running certain types of Unix (variants of BSD 4) were affected.
The Internet worm was developed and launched by Robert T. Morris, Jr., who at the time was a graduate student at Cornell University. Morris exploited security weaknesses (in the fingerd, rhosts, and sendmail programs) in the affected versions of Unix. The worm program itself did not cause any damage to the systems that it attacked in the sense that it did not steal, corrupt, or destroy data and did not alter the systems themselves; however, its rapid proliferation and the ensuing confusion caused severe degradation in service and shut down some systems and network connections throughout the Internet for two or three days, affecting sites that were not directly attacked. Ironically, electronic mail messages with guidance for containing the worm were themselves delayed because of network congestion caused by the worm's rapid replication.
Although Morris argued that the worm was an experiment unleashed without malice, he was convicted of a felony (the conviction may be appealed) under the Computer Fraud and Abuse Act (CFAA) of 1986, the first such conviction. Reflecting uncertainty about both the applicability of the CFAA and the nature of the incident, federal prosecutors were slow to investigate and bring charges in this case.
The Internet worm has received considerable attention by computing professionals, security experts, and the general public, thanks to the abundant publicity about the incident, the divided opinions within the computer community about the impact of the incident, and a general recognition that the Internet worm incident has illuminated the potential for damage from more dangerous attacks as society becomes more dependent on computer networks. The incident triggered the establishment of numerous computer emergency response teams (CERTs), starting with DARPA's CERT for the Internet; a reevaluation of ethics for computer professionals and users; and, at least temporarily, a general tightening of security in corporate and government networks.
SOURCES: Comer (1988); Spafford (1989a); Rochlis and Eichin (1989); and Neumann (1990).
In other sectors, including the research community, the design and the management of computer-mediated networks generate communication vulnerabilities. In these systems (e.g., Bitnet) messages travel lengthy paths through computers in the control of numerous organizations of which the communicants are largely unaware, and for which message handling is not a central business concern. Responsibility for the privacy and integrity of communications in these networks is so diffuse as to be nonexistent. Unlike common carriers, these networks warrant no degree of trust. This situation is understood by only some of these networks' users, and even they may gamble on the security of their transmissions in the interests of convenience and reduced expenses.
SECURING THE WHOLE SYSTEM
Because security is a weak-link phenomenon, a security program must be multidimensional. Regardless of security policy goals, one cannot completely ignore any of the three major requirements—confidentiality, integrity, and availability—which support one another. For example, confidentiality is needed to protect passwords. Passwords in turn promote system integrity by controlling access and providing a basis for individual accountability. Confidentiality controls themselves must be immune to tampering—an integrity consideration. And in the event that things do go wrong, it must be possible for administrative and maintenance personnel to step in to fix things—an availability concern.
A system is an interdependent collection of components that can be considered as a unified whole. A computer operating system, an application such as a computerized payroll, a local network of engineering workstations, or the nationwide network for electronic funds transfer each can be considered as a system—and any one system may depend on others. All of these involve physical elements and people as well as computers and software. Physical protection includes environmental controls such as guards, locks, doors, and fences as well as protection against and recovery from fire, flood, and other natural hazards.
Although a security program must be designed from a holistic perspective, the program itself need not—indeed should not—be monolithic. It is best to operate on a divide-and-conquer principle, reflecting the classical management control principle of separation of duty. A system made of mutually distrustful parts should be stronger than a simple trusted system. On a large scale, communications links define natural boundaries of distrust. Within a single system extra strength may be gained by isolating authentication functions and auditing
records in physically separate, more rigorously controlled hardware. Such isolation of function is universal in serious cryptography.
Technology alone cannot provide security. In particular, an information security program is of little avail if its users do not buy into it. The program must be realistic and maintain the awareness and commitment of all participants. Further, management actions must signal that security matters. When rewards go only to visible results (e.g., meeting deadlines or saving costs), attention will surely shift away from security—until disaster strikes.
Concern for privacy arises in connection with the security of computer systems in two disparate ways:
the need to protect personal information about people that is kept in computer systems; and
the need to ensure that employees of an organization are complying with the organization's policies and procedures.
The first need supports privacy; the institution of policies and mechanisms for confidentiality should strengthen it. The second, however, is a case in which need is not aligned with privacy; strong auditing or surveillance measures may well infringe on the privacy of those whose actions are observed. It is important to understand both aspects of privacy.
Protection of Information About Individuals
The need to protect personal information is addressed in several laws, notably including the Privacy Act of 1974 (P.L. 93–579), which was enacted during a period of international concern about privacy triggered by advancing computerization of personal data.7 A number of authors who have written on the subject believe that privacy protections are stronger in other countries (Turn, 1990; Flaherty, 1990).
The Privacy Act is based on five major principles that have been generally accepted as basic privacy criteria in the United States and Europe:
There must be no personal data record keeping system whose very existence is secret.
There must be a way for individuals to find out what information about them is on a record and how it is used.
There must be a way for individuals to prevent information
obtained about them for one purpose from being used or made available for other purposes without their consent.
There must be a way for individuals to correct or amend a record of identifiable information about them.
Any organization creating, maintaining, using, or disseminating records of identifiable personal data must assure that data are used as intended and must take precautions to prevent misuse of the data.
Even where most organizations make a reasonable, conscientious effort to protect the privacy of personal information residing in their computing systems, compromisable system and data access controls often allow intruders to violate personal privacy. For example, a survey of 178 federal agencies by the General Accounting Office revealed 34 known breaches in computerized systems containing personal information in fiscal years 1988 and 1989; 30 of those incidents involved unauthorized access to the information by individuals otherwise authorized to use the systems (GAO, 1990e). Frequent reports of "hacker" invasions into credit-reporting databases and patients' medical records provide ample evidence of the general lack of appropriate protection of personal information in computer systems. Also, some applications in and of themselves appear to undermine the Privacy Act's principle that individuals should be able to control information about themselves.8 As noted in a recent newspaper column,
Most of us have no way of knowing all the databases that contain information about us. In short, we are losing control over the information about ourselves. Many people are not confident about existing safeguards, and few are convinced that they should have to pay for the benefits of the computer age with their personal freedoms. (Lewis, 1990)
Employee Privacy in the Workplace
An employer's need to ensure that employees comply with policies and procedures requires some checking by management on employees' activities involving the use of company computing resources; how much and what kind of checking are subject to debate.9 A common management premise is that if a policy or procedure is not enforced, it will eventually not be obeyed, leading to an erosion of respect for and compliance with other policies and procedures. For instance,
consider a policy stating that company computing resources will be used only for proper business purposes. Users certify upon starting their jobs (or upon introduction of the policy) that they understand and will comply with this policy and others. Random spot checks of user files by information security analysts may be conducted to ensure that personal business items, games, and so on, are not put on company computing resources. Disciplinary action may result when violations of policy are discovered.
The above situation does not, in itself, relate to security. However, one method proposed to increase the level of system security involves monitoring workers' actions to detect, for example, patterns of activity that suggest that a worker's password has been stolen. This level of monitoring provides increased opportunity to observe all aspects of worker activity, not just security-related activity, and to significantly reduce a worker's expectation for privacy at work.
Some managers argue that a worker, while performing work-related activity, should expect arbitrary supervisory observation and review and that there is no expectation of privacy in that context. This argument combines consideration of privacy with considerations of management style and philosophy, which are beyond the scope of this report. However, what is relevant to this report is the fact that computer and communications technologies facilitate greater monitoring and surveillance of employees and that needs for computer and communications security motivate monitoring and surveillance, some of which may use computer technology. As the congressional Office of Technology Assessment has noted, the effects of computer-based monitoring depend on the way it is used (OTA, 1987a).
There are complex trade-offs among privacy, management control, and more general security controls. How, for example, can management ensure that its computer facilities are being used only for legitimate business purposes if the computer system contains security features that limit access to the files of individuals? Typically, a system administrator has access to everything on a system. To prevent abuse of this privilege, a secure audit trail may be used. The goal is to prevent the interaction of the needs for control, security, and privacy from inhibiting the adequate achievement of any of the three.
Note that by tracing or monitoring the computer actions of individuals, one can violate the privacy of persons who are not in an employee relationship but are more generally clients of an organization or citizens of a country. For example, the Wall Street Journal reported recently that customer data entered by a travel agency into a major airline reservation system was accessible to and used by other travel service firms without the knowledge of the customer or
the travel agency (Winans, 1990). Computer systems as a mechanism provide no protection for people in these situations; as was observed above, computers, even very secure computers, are only a mechanism, not a policy. Indeed, very secure systems may actually make the problem worse, if the presence of these mechanisms falsely encourages people to entrust critical information to such systems.
INFORMAL SURVEY TO ASSESS SECURITY REQUIREMENTS
In April 1989 informal telephone interviews were conducted by a committee member with the information security officers of 30 private companies in the aerospace, finance, food and beverage, manufacturing, petrochemical, retail, and utilities industries. Within these categories an even distribution of companies was achieved, and interviewees were distributed geographically. Individuals were asked what basic security features should be built into vendor systems (essential features)—what their requirements were and whether those requirements were being met. Their unanimous opinion was that current vendor software does not meet their basic security needs.
The survey addressed two categories of security measures: prevention and detection. Within the prevention category the focus was on three areas: computers, terminals, and telecommunications and networking.
Individuals were asked to consider 40 specific security measures. For each, they were asked whether the measure should be built into vendor systems as a mandatory (essential) item, be built in as an optional item, or not be built in.
All of the interviewees believed that a unique identification (ID) for each user and automatic suspension of an ID for a certain number
of unauthorized access attempts were essential. The capability to prevent the simultaneous use of an ID was considered essential by 90 percent of the individuals interviewed. A comment was that this capability should be controllable based either on the ID or the source of the access.
Eighty-three percent of the interviewees agreed it is essential that the date, time, and place of last use be displayed to the user upon sign-on to the system. A comment was that this feature should also be available at other times. The same number required the capability to assign to the user an expiration date for authorization to access a system. Comments on this item were that the ability to specify a future active date for IDs was needed and that the capability to let the system administrator know when an ID was about to expire was required. Seventy-three percent thought that the capability to limit system access to certain times, days, dates, and/or from certain places was essential.
User Verification or Authentication
All interviewees believed that preventing the reuse of expired passwords, having the system force password changes, having the password always prompted for, and having the ID and password verified at sign-on time were all essential security measures.
Ninety-seven percent judged as essential the capabilities to implement a password of six or more alphanumeric characters and to have passwords stored encrypted on the system. Eighty-seven percent believed that an automatic check to eliminate easy passwords should be an essential feature, although one individual thought that, in this case, it would be difficult to know what to check for.
Sixty percent saw the capability to interface with a dynamic password token as an essential feature. One recommendation was to investigate the use of icons that would be assigned to users as guides to selecting meaningful (easily remembered) passwords. Thirty-three percent considered a random password generator essential; 7 percent did not want one.
File Access Control
All interviewees considered it essential to be able to limit access to files, programs, and databases. Only 60 percent thought that the capability to limit access to a specified time or day should be essential. Although all information security officers of financial organizations
thought such a capability should be essential, at least some representatives from all other categories of businesses preferred that such a feature be optional.
Eighty-three percent agreed that a virus detection and protection capability and the ability to purge a file during deletion were essential features. An added comment was that vendors should be required to certify a product as being free of viruses or trapdoors. Seventy-three percent considered the capability to encrypt sensitive data to be mandatory, but one respondent was opposed to that feature because it could complicate disaster recovery (i.e., one might not be able to access such data in an emergency during processing at an alternate site). Ninety-five percent thought it should be essential to require the execution of production programs from a secure production library and also, if using encryption, to destroy the plaintext during the encryption process.
All interviewees agreed that preventing the display of passwords on screens or reports should be essential. Ninety-five percent favored having an automated log-off/time-out capability as a mandatory feature. A comment was that it should be possible to vary this feature by ID.
Identification of terminals was a capability that 87 percent considered essential, but only two-thirds felt that a terminal lock should be included in the essential category.
An additional comment was that a token port (for dynamic password interface) should be a feature of terminals.
Telecommunications and Networking
More than 95 percent of the interviewees believed that network security monitoring; bridge, router, and gateway filtering; and dial-in user authentication should be essential features. Also, 90 percent wanted a modem-locking device as a mandatory feature. Eighty-three to eighty-seven percent of interviewees wanted security modems (call-back authentication), data encryption, automated encryption and decryption capabilities, and the ability to automatically disconnect an unneeded modem to be regarded as essential.
Additional comments in this area addressed the need for message authentication and nonrepudiation as security features.
All interviewees believed that audit trails identifying invalid access attempts and reporting ID and terminal source identification related to invalid access attempts were essential security measures. Likewise, all agreed that violation reports (including date, time, service, violation type, ID, data sets, and so forth) and the capability to query a system's log to retrieve selected data were essential features.
Eighty-three percent were in favor of network intrusion detection, a relatively new capability, as an essential item. However, everyone also agreed on the need for improved reporting of intrusions.
General Comments and Summary
General suggestions made in the course of the interviews included the following:
Make requirements general rather than specific so that they can apply to all kinds of systems.
Make security transparent to the user.
Make sure that ''mandatory" really means mandatory.
Seek opinions from those who pay for the systems.
In summary, it was clearly the consensus that basic information security features should be required components that vendors build into information systems. Some control of the implementation of features should be available to organizations so that flexibility to accommodate special circumstances is available.
Interviewees indicated that listing essential (must-have and must-use) and optional security features in an accredited standards document would be very useful for vendors and procurement officers in the private sector. Vendors could use the criteria as a measure of how well their products meet requirements for information security and the needs of the users. Procurement officers could use the criteria as benchmarks in evaluating different vendors' equipment during the purchasing cycle. Vendors could also use the criteria as a marketing tool, as they currently use the Orange Book criteria. These comments are supportive of the GSSP concept developed by this committee.
The mechanisms for carrying out such procedures are called mandatory access controls by the DOD.
Such mechanisms are called discretionary access controls by the DOD, and user-directed, identity-based access controls by the International Organization for Standards. Also, the owner-based approach stands in contrast with the more formal, centrally administered clearance or access-authorization process of the national security community.
There are many kinds of vulnerability. Authorized people can misuse their authority. One user can impersonate another. One break-in can set up the conditions for others, for example, by installing a virus. Physical attacks on equipment can compromise it. Discarded media can be scavenged. An intruder can get access from a remote system that is not well secured, as happened with the Internet worm.
Although it might be comforting to commend the use of, or research into, quantitative risk assessment as a planning tool, in many cases little more than a semiquantitative or checklist-type approach seems warranted. Risk assessment is the very basis of the insurance industry, which, it can be noted, has been slow to offer computer security coverage to businesses or individuals (see Chapter 6, Appendix 6.2, "Insurance"). In some cases (e.g., the risk of damage to the records of a single customer's accounts) quantitative assessment makes sense. In general, however, risk assessment is a difficult and complex task, and quantitative assessment of myriad qualitatively different, low-probability, high-impact risks has not been notably successful. The nuclear industry is a case in point.
The extent of interconnection envisioned for the future underscores the importance of planning for interdependencies. For example, William Mitchell has laid out a highly interconnected vision:
Through open systems interconnection (OSI), businesses will rely on computer networks as much as they depend on the global telecom network. Enterprise networks will meet an emerging need: they will allow any single computer in any part of the world to be as accessible to users as any telephone. OSI networking capabilities will give every networked computer a unique and easily accessible address. Individual computer networks will join into a single cohesive system in much the same way as independent telecom networks join to form one global service. (Mitchell, 1990, pp. 69–72)
Other federal privacy laws include the Fair Credit Reporting Act of 1970 (P.L. 91–508), the Family Educational Rights and Privacy Act of 1974 (20 U.S.C. 1232g), the Right of Financial Privacy Act of 1978 (11 U.S.C. 1100 et seq.), the Electronic Funds Transfer Act of 1978 (15 U.S.C. 1693, P.L. 95–200), the Cable Communications Policy Act of 1984 (48 U.S.C. 551), the Electronic Communications Privacy Act of 1986 (18 U.S.C. 2511), and the Computer Matching and Privacy Protection Act of 1988 (5 U.S.C. 552a Note) (Turn, 1990). States have also passed laws to protect privacy.
This point was made by the congressional Office of Technology Assessment in an analysis of federal agency use of electronic record systems for computer matching, verification, and profiling (OTA, 1986b).
Recent cases about management perusing electronic mail messages that senders and receivers had believed were private amplify that debate (Communications Week, 1990a).