From Physical Reality to Cyberspace

CS 513 -- System Security -- January 28, 1999 -- Lecture 2
Lecturer: Professor Fred B. Schneider

Lecture notes by Lynette I. Millett
Revised by Borislav Deianov

In the last lecture we discussed economics, politics, reality, and reasons for the prevalence and untrustworthiness of network information systems. Today, we begin a more specific discussion of security. What properties are we interested in and what are good strategies in implementing security?

General Security Issues

We first consider what we can learn from "real world" security. In the real world, security decisions are based on three things: We try to buy good enough locks so that the "bad guys" can't break in too often. The terms "good enough," "break in" and "too often" are key. We also assume that the police and courts work, so "bad guys" are caught and punished. "Police" in this context is a generic term for any agency that might pursue offenders; it includes the corporate hierarchy or the legal system. Similarly, the "bad guys" could be anyone, anywhere, including system operators for the system being secured. By "often enough" we don't mean always but enough so that crime doesn't pay. In other words, the expected gain from committing a crime must be negative. Value is an important aspect of this characterization, because generally we do not protect things of little value.

A constraint we place on any security mechanism is that it add a minimum amount of interference to daily life. For example, locks must not be difficult or annoying to use. If they are, it's likely that people will find ways to circumvent the annoyance and thus nullify the security protect0ions the locks offer. It should also be noted that with rare exceptions is a security breach of some sort the end of the world. Risk management allows recovery from a security problem and decreases the need for complex and annoying locks. For example, rather than installing a complicated locking system for automobiles we buy auto insurance to help deal with costs that arise in the event of damage or theft.

Externalities also have a role to play. Briefly, an externality occurs when somebody or some agency does something in which the cost implications for the doer are not the same as (usually significantly less than) the cost implications for society. For example, think of companies that pollute the environment. The cost of cleaning pollution is usually great, and until recently there was no corporate penalty for not fixing a pollution problem. In short, an externality exists when it is cheaper to do the wrong thing. This has obvious large implications for security--an insecure subsystem may enable a system wide attack of great consequence.

There are number of things to observe. First, note that all locks are not the same. They typically have different keys as well as different strengths. The strength of the lock tends to be chosen according to the value of what is being protected. The environment also influences the type and strength of the locks being used as well. For example, apartments in Ithaca likely have fewer and weaker locks than apartments in Manhattan. Second, people pay for security they believe they need. Security is not monolithic and there is not one mechanism for everyone. Security is scaled with respect to both the value of the thing being secured and the threat against it. People's security "needs" are usually based on the perception of what's going on around them. If your neighbors are being broken into, then it's likely that you'll buy more security equipment than if not. Third, the police are central to the picture. The system still works even if locks are completely removed. Locks are only a deterrent; however, it is essential that there be enforcement and punishment strategies in place. There will undoubtedly be some security breaches no matter how good the locks are. Thus, it is critical that bad guys be found. Locks reduce temptation as well as reducing the police workload. Finally, security, as we have portrayed it, is holistic. It is only as good as its weakest link. Attackers will look for the weakest link, and thus it is generally best to expend effort in determining where the weaknesses are and shoring them up. Given limited resources, the best approach is to make all elements equally strong, thus eliminating weakest links.

Applications to Computer Security

We now move from an abstract discussion of security in our day-to-day lives to the world of computer security. How can the above discussion be applied in this new context? With regard to computer security, the story is told in terms of three terms:

Bugs in a software system are vulnerabilities. Since we are not really good at building large systems, it seems clear that any large software system will have many vulnerabilities. While a first strategy for addressing a security problem might be to find and fix each vulnerability, in fact, this is likely to be too costly to be practical. Rather, it is better to first identify threats, and then work on eliminating only those vulnerabilities that those threats would exploit.

As an example, consider the problem of intercepting cellular phone transmissions. This possibility is clearly a result of a design vulnerability--a consequence of the way cellular phone signals are encoded and transmitted. A threat that exploits this vulnerability would be the small number of people who want to do this and have the knowledge and equipment to intercept transmissions. When cell phones were first introduced, the equipment was hard to come by and few people had the knowledge to mount an attack. Thus, the threat was small. Currently, just about anyone can buy the equipment; the threat is huge. The vulnerability has remained the same, but the nature of the threat has changed. Currently, there is a large amount of cellular-phone fraud.

Range of Threats

What are the range of threats that network information systems face? The Defense Science Board has issued a report that includes their view of current threats to the national infrastructures. Their list, in order of increasing severity, is as follows:

Note that as we go down the list, more and more resources are presumed available for attacks. It seems, then, that the severity of a threat is related to the resources available. On the other hand, available resources will also include knowledge. Cash can buy knowledge, of course, but these days attacks can be packaged and broadly distributed so that considerably less knowledge is needed to launch an attack. For example, SATAN is a package used to identify breaches of security in UNIX systems and break into them. Ostensibly this package is for UNIX system administrator's to use to aid in securing their own systems. However, its wide availability on the Internet means that anyone can use it. Note also that the existence of such packaged software means there is a discontinuity between the technical expertise of a particular threat (such as the blunderers) and the severity of the problem they can cause with access to methods produced by those at the higher end of the scale. This is troubling.

Attributes of Computer Security

How do locks, value, and police make sense in connection with computer security? Locks can be thought of as authorization or access control mechanisms. A "key" or authentication is generally required to open a lock. This "key" can be something the user knows, has, or is. For example, the user may know a password or possess an ID card. Retinal scans and fingerprint verification would take advantage of something that the user is. The police for computer security are the same as the "real world" police. The difference is that in the realm of computers, attacks can be launched remotely, and thus the equivalent of video cameras (to help the police and courts convict the offender) will be necessary. We call this equivalent an audit facility. Noting the chemical symbol, Au, for gold, Butler Lampson has proposed the "Gold Standard of Security" consisting of

Any system purporting to be secure will contain these elements. Note that, as before, locks are only the first line of defense. Security cannot work if locks are the only protection, however. It is easy to forge keys, and locks are typically complicated, so they may have design and implementation vulnerabilities. This suggests two general principles: Secure systems should have multiple, independent lines of defense with a diversity of mechanisms. And that gives rise to another useful, general principle: It is,still necessary to have audit and police procedures in place. The latter, of course, are not a mechanical means of solving the problem; they move the problem back into society, rather than keeping it in the realm of technology.

There are several possible strategies for implementing a security system:

  1. Keep everyone out. If there is no sharing, then there is no need to worry about attacks. This technique is used for single-user machines. The problem is that sharing is a good way to communicate and get things done.
  2. Keep the bad guys out. There are technologies that facilitate this. Firewalls can be used to act as a gateway and filter information going in and out of a subnetwork. Similarly, code signing is used by web browsers to allow restrictions on what code can be run. The problem here is that if a firewall is penetrated or a code signature is stolen, security is compromised.
  3. Let the bad guys in, but prevent them from doing damage. There are various techniques for this. Most internal system security mechanisms we discuss do exactly this. Think of standard operating systems, which place restrictions on which processes have which privileges.
  4. Let the bad guys do anything, keep track of what happens, catch the bad guys and then prosecute them. This is facilitated through the use of good audit facilities.
Approach (3) ("Let the bad guys in but ... ") is an instance of a another general principle for computer security: Notice that the latter three strategies of the four possible strategies (1)-(4) require being able to distinguish the bad guys from the good guys, and that means some sort of authentication process. Keeping the bad guys out requires having a list of the good guys. Letting the bad guys in but preventing them from doing harm requires not only a list of the good guys, but an authorization mechanism as well. This authorization can be done at many levels of the system. For example, read/write/execute privileges in a UNIX system are done at the file level. Authorization could also be done at the level of fields in data records. The closer to the application level, the greater the possibility of authorizing precisely what is required. However, if done at a higher level, it is possible for the success of the mechanism to become application dependent. At a lower level, authorization is likely to be simpler. The less complex such facilities are, the fewer bugs there will be. Thus lower level authorizations can provide higher assurance. This is a classic trade-off: functionality vs. assurance. The fourth option above depends heavily on audit facilities that cannot be subverted by the bad guys. Thus, audit requires authorization.

Assurance

The issue of assurance brings up a whole family of issues. It is not enough that a system be secure or trustworthy. It must be demonstrably so. Before a system can be trusted, it is necessary to convince people that it satisfies the security requirements. The question becomes: What do you know and how do you know it? There are several ways to answer this question. One weak answer is to claim that the system has been debugged thoroughly. Another is to note that the system has been deployed and tested extensively. Yet a third may be to point to an agency, like NSA, that has approved it. (The latter may not provide as much of a security guarantee as one would hope.)

In general, the two strongest methods used to increase assurance are extensive testing by outside groups and mathematical proof. Mathematical proofs can be very long and involved even for small programs, and thus are not likely to be feasible for large, complicated systems.

The question of assurance is also related to an engineering question. If a system is designed to have the fewest number of critical components, then testing those components thoroughly can be a lower-cost way to increase assurance than by testing an entire system.