What we mean by Trust

This paper was written as part of a site-wide security audit, and later revised slightly for publication in ;login (October 95, pg 29).

When discussing systems, or network layouts, or security concerns, we often use the word "trust". Unfortunately, this has led to some confusion, as in this context, we are not using the word "trust" in the conventional sense.

Trusting People

When I say that I trust Dave, it means that not only do I trust him in the conventional sense of trust, but that when the userid daveh signs on to a machine, I have a VERY HIGH expectation that it is in fact Dave at the keyboard. This means that not only that he has not given his password to someone else, but that his office door is locked when he is not there, that no one has ever sniffed his password from the net, that his X sessions have not been tapped via the Xkeys program, his workstation has not been hacked and a trojan horse installed, and a whole range of other exposures that might enable someone else to pretend that they are Dave and use his RCS userid.

Many of these weakness may be outside of Dave's control. There may be hacked machines on his ethernet that have watched him sign on and grabbed his password. He may have been traveling and signed on via some service provider who has been hacked (This is a serious problem). He may have signed on at a public X station and had his keystrokes picked off by the student next to him, or simply had someone shoulder surf his password as he typed it in.

In determining the level of trust, we are not looking at the particular person, but rather we are looking at all the different ways that someone could obtain credentials to impersonate the first person.

Trusting Hosts

How do you trust a machine? When we say we trust a host, that is a measure of our confidance that we still control that machine, and no cracker has taken control of it, installed back doors, sniffers, trojan horses, etc.

While some attacks come via the network, many of the attacks require that the cracker first be signed on the machine as a conventional user. From here, they find holes in the system that let them obtain additional access, and eventually partial control of the machine. From here, they can then use this machine to launch attacks on other machines.

While there are things we can do to close these holes, and we must do what we can, this will be an ongoing task, as every OS upgrade, vendor change, etc, may introduce a new hole. In addition, operational requirements may force us to tolerate holes in vendor software that we do not have the ability to close ourselves. In these cases, we need to isolate these systems behind suitable firewalls to protect the rest of the systems and limit damage.

Given that a cracker only has to be able to break in once, the security of a machine is in part determined by the least trusted user on the machine, and by trust, we are referring to the previous section.

Trusted Networks

We also need to be able to trust a network. As with hosts, this is a measure of our confidance that no one is sniffing packets, or spoofing IP addresses. Although we can reduce sniffing attacks via correctly configured smart hubs, and reduce spoofing attacks via filters at the gateways, if a cracker can break a machine on a particular subnet, they may still be able to launch some attacks despite the safeguards.

Although many things go into determining the level of trust for a given subnet, we again are faced with the least trusted factor setting the level for the network, and includes all of the machines on that network.

Transitive Trust

Building trust models is a tricky business. For example, in order to protect the file servers, we need to trust the network they are on so the root password is not monitored. This means we have to trust all the machines on that network. Which means we have to trust all the users on machines on that network. This turns into geometric growth very quickly. In addition, we have to trust the gateways on the network, and the machines that control the gateways.

The process isn't easy, but it is important. If you can start with a trusted core, you can then build out from there. We will never be able to trust the entire RPI network, but we can take steps to protect important parts of it (and the associated machines, data and people), and to maintain firebreaks to limit damage, and to establish fire towers in cyberspace to detect and track problems in order to correct them.

Crackers

Who are we defending against? Disgruntled students, disgruntled employees, assorted outside cyperpunks with time on their hands, current students with perhaps too much spare time on their hands. We are not trying to keep out the NSA; if they want in, they will get in. We really are not going to stop KGB spys; they will simply bribe the appropriate person if they want it bad enough.... My bet is that neither the NSA, nor the KGB are going to bother.

The people we are trying to stop are generally not geniuses (they usually have better things to do). Instead, we have vandals in cyberspace who found a set of cracking tools on an anonymous FTP site. They may not understand what they are using, but some of these tools are quite good and finding holes. These people are often very good liars (this is known as social engineering) Ask Gail or Barry or Sharon about some of the second offenders they have dealt with.

These people do often have a lot of time to spend looking for holes. Often there are programs that can help automate or exploit the holes when they find them. If we leave a hole, and someone is willing to invest the time to find it, they will. We must be sure to make that investment too high for anyone who is likely to try, to succeed.


finkej@rpi.edu