| Previous | Table of Contents | Next |
As noted in other chapters, many tradeoffs can be made in system monitoring. The two most important variables you can tradeoff are CPU and network performance. If you run Stalker Manager and Agent software on each node, you can analyze the data on the systems where it is created. You will spend CPU cycles on each node performing the analysis, but you will not be sending large audit logs across the network. If you get clever, you can use the Stalker Manager code on the Agent systems to reduce the audit logs before sending them to a central server for storage. Unfortunately, the pricing model of Stalker does not make this configuration too attractive at this time.
On the other hand, if you do not want your agent nodes wasting CPU cycles doing intrusion detection, you can eat up some network bandwidth and send the audit logs to the server using NFS, FTP, or your favorite distributed file system tool. By the way, a Stalker Agent is not necessarily a puny little workstation. Agent is a role that a system plays in the Stalker environment. An agent could be a big megaserver with loads of storage, memory, and plenty of parallel processors. Similarly, the Stalker Manager could be run on the oldest single user UNIX workstation you have at your site, although this would not be a good choice for something that needs to analyze quite a bit of data.
A special version of Stalker is modified to monitor the IBM Firewall. The product includes some custom reports to monitor configuration and executable files that make up the firewall. This feature is complementary to the Tripwire type of file checking that the firewall already does. Stalker will report on who is changing firewall executables or configuration files and describe the audit events that led up to that behavior. Although it would be a useful extension, Stalker does not read or monitor the log files emitted by the firewall. Special attack patterns also have not been developed explicitly for firewalls. Now that Haystack has subsumed into Network Associates who owns the Gauntlet Firewall, a closer fit between IDSs and firewalls is likely.
Stalker V3
A new version of Stalker is planned for 1998. One notable enhancement is real-time processing of MD signatures, so that you can look for attacks as they occur. Information exchanges between Stalker Agents and the Manager will be accomplished in real time using a secure communications protocol.
In Chapter 2, “The Role of Identification and Authentication in Your Environment,” emphasis was placed on the following triad:
Stalker V3 also provides capabilities for different real-time responses when attack patterns are matched. Possibilities include e-mail, paging, custom scripts, killing processes, disabling logins, blocking logins for an interval, and SNMP traps. The design is flexible enough to enable you to respond in unique ways to different intrusions and to vary your responses by time of day.
Before moving to the next section, it is worth mentioning again that Stalker also provides threshold detection for a few events, such as failed logins or failed su events. Thus, Stalker shares characteristics with anomaly detectors such as CMDS. Exceeding a threshold of a specific event is the simplest form of statistical anomaly detection. Conversely, CMDS includes a few pattern matching rules, too. You can even find a few sites that run both CMDS and Stalker.
Like Stalker, CMDS is an audit trail analysis tool. CMDS performs audit reduction from heterogeneous and distributed target nodes. CMDS development at Science Applications International Corporation (SAIC) was led by Paul Proctor (Proctor, 1994). The CMDS server analyzes the data provided to it by monitored targets. Analysis occurs in real time unless CMDS is configured otherwise. Historical audit logs can be saved and interrogated later as in Stalker.
Because the audit logs are the primary source of information for CMDS, accountability can be attributed to users via the AUID or to remote systems by gathering all activities for a particular IP address. Statistical profiles for a given network address can be thus be created and tracked historically.
Often, potential IDS customers ask for “useful management reports” to pass up the chain of command. Summary statistical reporting is another CMDS strength. The original sponsors were looking for a system that could provide good summaries of suspicious activities. This requirement helped drive the development of good reporting in the core CMDS offering.
When a survey of existing IDSs was done as part of the CMDS background research, it was discovered that many existing tools were tailored to the data source and other characteristics of the environment. At that time, Stalker was just beginning to emerge to provide a general-purpose framework adaptable to audit sources from multiple systems. CMDS arose concurrently with the same architecture goals. To prove its easy adaptability, CMDS was modified to support a multilevel secure OS audit trail from B1 DG/UX in a mere two weeks.
CMDS is best known for its statistical anomaly-detection approach, although CMDS also includes an expert system with pattern-matching signatures. Many early IDSs were written using rule-based expert systems, although this programming paradigm is not widely used today.
Analysis Modes
CMDS can analyze target node data in real time, batch, or on-demand modes. Each target runs a daemon that preprocesses the audit data, converts the data into a normal format, encrypts the data, and then sends the data to the CMDS Server. Optionally, the audit logs can be stored on the target and sent to the central server on a scheduled basis.
Most installations run in real time and perform on-demand analysis when an alert is generated to fine tune monitoring activities. When an alert occurs, it is indicated via one of the following responses:
Administrators who do not need real-time analysis can run reports in batch mode, perhaps during off hours so that the analysis will be available to the security officers in the morning.
| Previous | Table of Contents | Next |