Enable breadcrumbs token at /includes/pageheader.html.twig

Prototype Code Connects Multitude of Security Devices

Researchers are developing a programming language that enables different computer intrusion detection and response applications to communicate with each other, offering users a more complete defense against cyberattacks. The goal of the common intrusion detection framework is to allow interoperability among the variety of security components that reside on a single network.

New language aids network intrusion detection and response applications.

Researchers are developing a programming language that enables different computer intrusion detection and response applications to communicate with each other, offering users a more complete defense against cyberattacks. The goal of the common intrusion detection framework is to allow interoperability among the variety of security components that reside on a single network.

An open working group, composed of universities, industry and the Defense Advanced Research Projects Agency, focused on defining an application-layer language for describing data that is important to intrusion detection components and a protocol for encoding that data so it can be shared between applications.

As attacks on computer networks become more sophisticated and increase in both frequency and scale, it is becoming more difficult for stand-alone proprietary intrusion detection systems to provide adequate defense (SIGNAL, August 1999, page 33). Under these circumstances, it is important for security systems and their components to share information about attacks and probes. Such communication allows applications to identify and locate assaults more accurately while enabling administrators to deploy advanced response and data recovery procedures.

According to Brian Tung, security researcher and project leader at the University of Southern California’s (USC’s) Information Sciences Institute, the main product of this work has been the common intrusion specification language (CISL), which allows information about events and attacks to be expressed in a platform-independent manner. The language is not really meant for human consumption; it is primarily designed to allow tools and applications to communicate with each other, he notes.

For example, a system manager installs intrusion detection tools on a network. The administrator wants to place more than one security item on the system, but a problem exists because each product has different and proprietary forms of communication. The ideal way to handle this would be for all the tools to communicate with an automated system coordinator, which would then generate a composite analysis for the administrator’s use, Tung says.

To fit into the common intrusion detection framework (CIDF) model, the language has to be extremely flexible because of the interrelationship of intrusion detection devices on a network, where the output of one component might become another component’s input. Tung indicates that the nature of these inputs and outputs can be quite different at various places and locations in a system. Components that are close to data sources are more likely to produce raw event descriptions, while components further downstream may consume these descriptions and generate analysis of them. Other applications may take in these analyses and produce recommendations for responses as well, he says.

Though the nature of the information being exchanged is highly variable, it is beneficial to find a common means of communication because the components are connected and related in purpose and function. This would also allow other devices, which conduct activities such as state monitoring, to participate. An extensive feedback loop within the intrusion detection system at large could also be created with responses ranging from additional reconnaissance to specialized event data gathering, he explains.

Despite these commonalities, the nature of the messages these devices produce is different in important ways. For example, event records simply represent observations made by a component on a system; many involve ordinary computation or routine maintenance. The resulting records are often produced in high volume with relatively low security requirements. In contrast, analysis results and countermeasure recommendations are almost always related to suspected attacks and are therefore relatively rare. Security requirements will be higher for these messages because they can affect an intrusion detection system’s reasoning about how to react to an incident. The differences in the nature of these messages affect the transport mechanisms used to move the data. Information generated in high volume will most likely be sent in forms optimized for performance. Likewise, less frequent communications will use methods that provide reliability and security, Tung says.

To meet these goals, CISL needed several important qualities. It had to be expressive enough to allow components to describe a wide range of intrusion detection and misuse-related phenomena and solutions. The language needed to be unique in expression, so a given statement could only be described in a limited number of ways. Layering was important because it allowed different applications with varying requirements to understand as much as they needed from a message. CISL also had to be efficient so it would not consume too many system resources, extensible enough for users to modify without losing compatibility, and portable enough to operate on a variety of platforms.

Early in development, the team decided to use s-expressions, a format in which lists are grouped within parentheses. Information within the parentheses is headed by semantic identifiers (SIDs) that indicate the semantics for the grouped list. This choice was motivated by the issue of grids messages, which are a sequence of data in pairs that note grid position; however, using only grid messages would have led to a rapid multiplication of SIDs to try to combine two orthogonal attributes, Tung says.

The team created two different messages: the data and a vessel to contain that information. Later it became necessary to know not only the role, but also the activity associated with a specific statement because a role can be interpreted differently depending on a given activity, he explains. This led to the creation of verb SIDs that represent “sentences” of events. When the entire statement, or sentence is encapsulated, it forms generalized intrusion detection objects. What was initially a very flat language structure grew into a hierarchical one, and doing so was a practical matter because the language needed a hierarchy to be feasible at all, Tung observes.

In June, USC’s Information Sciences Institute ran a demonstration of CISL and the CIDF framework. This event was not considered an experiment because the participants knew the sequence and number of activities taking place on a network featuring a number of intrusion detectors and correlators. Multiple attacks were then attempted on the system with all participants being aware of the source of the intrusions. The exercise demonstrated that a syntactical understanding existed between the various components on the network, which validated the core goal of CISL. Tung cautions that while the demonstration proves that the language can function in a controlled environment, it does not reveal whether it will work under real-world conditions.

This fall, another demonstration is planned that will involve generalized intrusion detection objects being sent between different intrusion detection tools to determine the semantic interoperability of CISL. Of key importance is whether data has been clearly and unambiguously conveyed from one tool to another tool that does not know how the data will be phrased. This will determine if the vocabulary is clear enough to convey information without prior agreement on the exact context of the message. Tung adds that the purpose of the approach is not to mandate a specific possibility. CISL does not place many constraints on how statements are put together, but only dictates how information components are shared once two intrusion detection devices decide to communicate with each other.

Properly structuring the language was the first difficulty the team encountered, Tung says. Once this problem was addressed, the next step was to determine how to understand what someone was going to say in the language because, for example, there are many ways to convey the statement “someone had deleted this file,” he notes.

Placement of information was another issue. Initially, CISL had almost no rules governing the order in which SIDs were sequenced. Development of a concordance to determine how things would be laid out in the language was a primary problem.

Proprietary systems were another hurdle the software designers faced when developing CISL, and Tung concedes he encountered resistance from vendors on this issue. However, manufacturers of intrusion detection products have shown greater interest in the area of intersystem cooperation. If proprietary programs all share the same network provider, they can be vulnerable to attack. The idea is to generate reports from other applications’ intrusion detection reports and react to them, he says.

Cross platform language encoding was never significant, Tung observes. CISL is much simpler now because it was trimmed to avoid ambiguity. Network byte order specified these usages, and the utilities for manipulating the language were written in Perl and ANSI C++.

The code is very portable with few components being dependent on a particular operating system, and other cross-platform concerns were minor. However, a larger issue is determining the available tools for use with CISL. Tung admits the language currently has a UNIX bias and would benefit from additional input from Windows NT programmers because NT-specific intrusion detection is not well covered.

The framework is still very much a work in progress, Tung cautions. Additional tests will lead to improvements in the vocabulary and to open language specifications. The development process has improved as well. At this stage in the language’s development, suggestions have a much greater impact than before, and once a proposal is accepted, the improvements are usually implemented within 10 days.

In the long run, Tung is not interested in turning CISL into a product—he considers it an infrastructure. However, he hopes that the language becomes so well known that designers have no real choice but to incorporate it into their products. The winners would be the users who would benefit from the added network security provided by interdevice communication, he says.