Trust Mechanisms for Hummingbird

Introduction

Hummingbird is a general network auditing manager which collects data from multiple audit tools and provides mechanisms for sharing data among hosts, and even other networks. Other tools presently exist that permit administrators to automatically collect data for a network, such as ISS, SATAN, and Hewlett Packard's network monitor. However, most of these require centralized administration, manage only same-vendor audit tools, or are custom made for a particular site. In contrast, Hummingbird's design offers abstraction from platform-specific implementation issues, and it encourages distributed administration.

We believe that intrusion detection and prevention will be greatly improved by providing cooperating networks with information relevant to an intrusion in progress. These cooperating sites may then be able to help by limiting or tracing the intrusion. Cooperation between system administrators has been found to be extremely effective in responding to wide-scale attacks, as with the Internet Worm of 1988. However, presently there is no truly automated mechanism for sharing information between sites. SATAN, ISS, and similar tools permit sites to obtain information about remote networks, but this information is provided from outside and (potentially) without the consent of the remote site's administrator.

Hummingbird's main objective is to gather data about possible security problems and organize it in an easy-to-comprehend format. However, unlike most security tools, Hummingbird can compile data about multiple workstations, even when on different networks by running a local ``hummer'' on each workstation. This enables system administrators to react more quickly to security threats.

Hummingbird is intended to allow a system administrator to monitor security threats on multiple computers from one central location. Hummingbird's real strength is the ability to share data with other sites, even those of questionable character, without compromising security and confidentiality. In this article we will focus on how Hummingbird selectively shares information with other sites and the issues involved.

Architecture

In order to maximize the system's modularity, Hummingbird relies upon individual hummer agents to generate and distribute misuse reports. Hummingbird's core has three parts:

Message Distribution Unit (MDU): Communicates with other hummers.
Data Distribution Unit (DDU): Decides what other hummers should be sent which data
Data Collection Unit (DCU): Uses data collection modules to collect data. Data collection modules can be added without modifying the DCU.

These three components communicate through the ``local hummer network,'' which is an intelligent network presently implemented using sockets. Integrating the components into one multi-threaded process would probably be a more pleasing design, but portability is presently of higher precedence.

Figure 1: Hummingbird's Architecture

The Meaning of Life...

Through this parable we will illustrate the problems Hummingbird addresses, as well as the new problems it creates.

...without Hummingbird

George is a system administrator for one department of a large software corporation which does its development on a UNIX network. Recently George has noticed several attacks on the local file server. The attacks came from somewhere outside George's local group, but could have been from anywhere else in the corporation. George raises his eyebrows and wonders if there were attacks on the other machines he is responsible for. He rolls up his sleeves and manually searches for any traces of attack on each of the 75 machines he supports.

Three days later George has confirmed that of 75 machines, all were attacked and 13 were compromised. It turns out that the attacker exploited a security hole unique to one patch level of the operating system. George steadfastly patches the kernel on the compromised stations, and cleans up the apparent damage done.

Two weeks later George comes to work to find the file server's file systems corrupted beyond repair. It seems the attacker left a back door which George missed. Now George is faced with the monumental task of re-installing the operating system from scratch on 75 workstations! Not only does he have a lot of work to do, but the most recent ``safe'' copy of his group's files are three weeks old.

George is not happy. He laments over his predicament at the cafeteria and Bob, another system administrator overhears him. George and Bob start comparing notes and realize that they were originally attacked within three hours of each other. Bob runs back to his office and disconnects his group from the network. After assessing the damage, Bob realizes that he is no better off than George.

The next day George and Bob spread the news to other system administrators and one sends a copy of a security bulletin which tells of the problem. The bulletin is informational, but definitely too late. Sixty percent of the corporation's departments have been compromised. The company goes off-line for three weeks while repairing the damage, and meanwhile loses a lot of money from lost productivity.

...with Hummingbird

A few weeks later at another large corporation, Scott is sitting at his desk when his terminal beeps madly at him. He takes a look at what is happening and sees that Hummingbird indicates someone has unsuccessfully tried to log into 30 workstations in his group in the last two minutes; all 30 messages are identical. Then another message pops up -- one of Scott's systems has been compromised. Scott immediately fires up a packet snooper and starts a log of all traffic on his subnet. Within another two minutes, two more machines are compromised. Scott has had enough. He shuts down the gateway to his subnet. Scott then goes back through his network traffic log and realizes that his machines were attacked by an automated attack script. He has complete logs of everything that was done to two of the three machines which were compromised. With that information he is able to not only figure out what security hole was exploited, but also is able to completely repair the damage.

After spending a few hours patching the vulnerable systems, Scott sets up Hummingbird to automatically log local network traffic at any sign of another attack.

Scott reconnects his subnet to the outside world and within minutes is flooded with warnings from other hummers in other departments of the company, as well as from off site. He immediately calls Ron, one of the central network administrators and tells him all he has learned about the attack. Ron disconnects the entire company's network from the outside world and calls an emergency meeting. By the end of the next day, all the compromised systems in the company have been restored and Ron puts the company back online. Scott and Ron submit a summary of the attack to some central security agency, describing how to avoid it, and how to repair the damage if already done. Within two weeks, news of the security threat has circulated throughout the world.

Analysis of this parable

The above story captures the basic spirit of what Hummingbird attempts to accomplish. In this case, Hummingbird excelled mainly because it allowed Scott to realize he was under large-scale attack before the attack was complete. However, Hummingbird has a broader purpose. It allows multiple sites to share information with each other.

Of course, this is a rather rosy picture of what we would like to see Hummingbird do. Unfortunately, making Hummingbird behave as outlined is not trivial. In Scott's case above, he was the first to be attacked of everyone in his hummer network. Before disconnecting from the network, over 50 of Scott's workstations sent messages out to the rest of the hummer network.

What did all these other hummers do with the information Scott's hummers sent? Ideally, all the other computers within the corporation would take the warnings from Scott's computers as gospel truth, while the workstations not associated with Scott's corporation would be more critical of the information. Likewise, the corporation may feel that sending out information about failed attacks is acceptable, but sending messages about successful attacks is a security risk. Deciding who can hear what, and how much to believe from whom is a difficult problem.

Hummingbird's Trust System

Hummingbird's trust system boils down to a fancy bitmap. In order to meet our needs we create bitmaps of attributes. One one-bit column exists for each attribute, and one host's attributes are stored in each row. A value of one in an attribute column indicates that the host possesses that particular attribute. Hummingbird uses two bitmaps, one for incoming messages and another for outgoing messages.

Attribute names can be associated with individual columns of the bitmap. In addition, logical attribute names can be associated with logical expressions made up of attribute names and/or absolute column numbers. This offers complete flexibility.

This representation takes more space than some other possible implementations, but offers several advantages. Perhaps most important is that no hierarchical structure is built into this scheme. For example, assume we have multiple levels of clearance: top secret, secret, and classified. We may, or may not, wish for hosts with top secret clearance to have access to secret and classified data. Hummingbird's trust system allows any combination of both hierarchical and non-hierarchical security labels.

The bitmap format of Hummingbird's trust system is useful when sending a message out to other hosts. Each message to be sent out on the hummer network is associated with one or more security classifications. We can determine which hosts should be sent a message by applying one or more bit masks. We look for hosts with sufficient clearance and encrypt the message for each host before sending the messages.

When receiving messages from other hummers we can look to our bitmap to decide how much faith to put into what we have been told. By creating logical attributes, we can set up levels of trust for various types of data. As mentioned above, this generally uses more space than alternative implementations, but offers full configurability.

Figure 2: Sharing Hummer Data

Sharing Data

There are many ways to configure communication between neighborhoods of networks. One method is to designate one of the LAN Audit Managers in Figure 2 to act as the Neighborhood Audit Manager. This host is then responsible for sharing information about the local neighborhood with its siblings. For example, once the local system administrator has determined that there was in fact an attacker, this information can be passed on to sibling neighborhoods. Initially, it might be best to simply indicate that the local neighborhood was under attack. This way neighborhood siblings can reassess the reliability rating attached to any other information received from this neighborhood, look for similar attacks locally, or limit communication with the besieged neighborhood. If the attack's source can be determined, still more can be done. If the attack arose from outside the neighborhood set, all cooperating neighborhoods might choose to scrutinize or block communication with the source. If the attack arose from inside the neighborhood set, then the neighboring network's system administrator can assist in locating and/or observing the attack. Just as certain types of attacks--for example, doorknob rattling--are most easily detected and traced when data is shared within a LAN, we expect that attackers who probe multiple hosts within sharing neighborhoods will be more easily detected and traced.

Figure 3: Centralized Data Collection

Ongoing Work

The original Hummer prototype used plain text messages and assumed that messages originated with the host whose identity was associated with the packet. This prototype is vulnerable both to message sniffing and identity spoofing. Within a controlled LAN, this may not be a problem; however, both of these attacks are a concern when communicating with neighboring Hummers. We have therefore developed a version of Hummingbird that uses public key encryption (PKE) for authentication and privacy of the messages. We have chosen PGP as the encryption engine. Adding PKE to Hummingbird required adding protocols to the MDU and development of support routines, but the DDU and DCU modules were not changed.

Early versions of the Hummingbird prototype have been tested within a single network that was treated as a set of four virtual networks. These networks were configured to share data as shown in Figure 3. Hummer rings of four to six members have performed correctly for several weeks, and have restarted successfully after system crashes and reboots. The participating hosts were mainly Hewlett-Packard workstations, but an SGI and a DEC workstation were also used.

Our current research is directed towards adding tools to assist in generating data collection programs. Besides providing access to security-relevant data, we have found Hummingbird to be a useful tool in other system administrative tasks, such as tracking host and disk usage.

Deborah Frincke (frincke@cs.uidaho.edu) is an Assistant Professor in the University of Idaho Computer Science Department.

Want more Crossroads articles about Security? Go to the index or the next one or the previous one.

Last Modified:
Location: www.acm.org/crossroads/xrds2-4/humming.html