March 2002

Test Center

Hewlett-Packard IDS/9000

The Doors' song, "Break on Through (to the Other Side)," might make a good hacker theme song. Because organizations tend to structure security by placing defenses mostly on the perimeter, hackers know that once they punch through the firewall, the rest of the network is relatively undefended. Security only at the perimeter creates a Maginot line effect, fortifying a defensive line while leaving what's behind it vulnerable to attack.

Hewlett-Packard's free host-based security application, IDS/9000, aims to prevent HP-UX systems from being hijacked, regardless of where the intruder is coming from. Even if the hacker is a company insider, IDS/9000 provides several methods to protect the host.

Host-based security is used to protect the systems that run the organization's bread 'n butter systems--Web, transaction, database and application servers. Designed specifically for the HP-UX platform, IDS/9000 is capable of putting the kibosh on unauthorized access, root exploits, privilege violations and even buffer-overflow attacks.

What It Does

IDS/9000 looks for fundamental behaviors that may provide someone with an unauthorized escalation of privileges. HP has written some of the functionality required to make this happen in the HP-UX 11.x kernel, allowing it to spot low-level calls that may be indicative of malicious behavior. IDS/9000 also has the ability to take action based on events. For instance, if the password file is modified, IDS/9000 can kick off a process that replaces the modified version with a known good copy. This feature could also be useful for immediately detecting and replacing defaced Web sites.

The IDS/9000 software uses kernel calls and system log files to gather event data. Using a correlation engine, it compares the events occurring on the host system against templates that contain user-defined behaviors. For instance, a template may instruct IDS/9000 to monitor a particular set of subdirectories for changes. Or, IDS/9000 may check a template for applications that switch context, suddenly obtaining super-user privileges.

Color-coded alert screens provide a quick check of alert severities.

How It Works

HP relies on templates, which are very different from the signatures used by most commercial IDSes. Most scanners look for a specific string within packet traffic. The string operates like a fingerprint: If an event matches the signature, an alert is generated. If an event occurs, and it doesn't match the signature string, the person managing the IDS must modify the signature or create a new signature for the new situation. The signature-based approach is inherently inefficient, because it's reactionary. Hackers can change their fingerprints (such as in the world of viruses), forcing admins to constantly update their signature-based IDS.

The approach that HP takes with IDS/9000 is to examine the underlying structure of a hack and stop it at the OS level. HP's idea is to strip away the variations of many hacks and see what it is the hacker is really attempting to do. Essentially, when a hacker cracks the password file, runs a buffer overflow or installs a backdoor, he's really trying to take advantage of some underlying OS vulnerability. Often, the goal of a hack boils down to gaining unauthorized privileges.

Using templates, IDS/9000 looks for patterns of suspicious behavior that may indicate a hack attempt. Templates provide guidelines for IDS/9000--what to look for, such as monitoring what happens when someone attempts to log into the machine, create or modify a file, or change file permissions. Each of these individual actions may not be a problem. But if someone repeatedly attempts to log in or change permissions on a file used by the OS, this may indicate hacker behavior in progress. When the IDS/9000 spots what may be hacker behavior, it sends an alert or kicks off a response script.

To determine if user activity is benign or malicious, IDS/9000 must examine events in the context of other events. Some products collect system events via event logs, which provide some of this functionality, usually by looking at log files for expressions. However, log files often lack sufficient detail and can be altered or removed. Moreover, because of the processing required, log files are often batch-processed offline during an audit-long after the events have occurred. IDS/9000 processes the kernel calls as they occur, using node point and process IDs and even showing the absolute path of the process. This is no small feat, considering how Unix often employs symbolic and relative paths.

As noted above, IDS/9000 can also react to intrusion activity. It can fire off a message, log to a file, kick off a script to replace a file or take any other action that can be scripted. The HP product manager called the system "self-healing." While this may be a bit of hyperbole, IDS/9000 can retrieve a clean copy of the hacked file from a read-only CD-ROM, copy the file and reimage the system or otherwise return it to a trusted state. My only gripe with this feature is that IDS/9000 lacks a back channel for reporting to IDS/9000 on the success or failure of a script. But since it's an HP product, shops that use OpenView can process the return codes from a script action.

OpenView is by no means a requirement for using IDS/9000, but it does help with centralized management. IDS/9000's GUI is sufficient for managing multiple IDS/9000s. Using OpenView enhances some IDS/9000 functions, such as being able to coordinate otherwise innocuous intrusion patterns that may occur across the enterprise, formulating them into a cogent picture of a cross-enterprise hack attempt. OpenView users should implement the OpenView Operations Advanced Security to create a secure channel between IDS/9000 and OpenView.

GUI Upgrades

Since this is version 2.0 of the IDS product, HP has made some improvements to the interface as well. Using an X-windows type GUI, color-coded alert screens provide a quick check of alert severities, with full alert details provided in a window at the bottom of the screen. The Template Configuration Manager screens use language that easily depicts what kinds of behaviors will be monitored, providing assurance that intended actions are the only ones that will be performed. And the Schedule Manager makes it simple to enforce various rules. A scheduling function might be used to do something like enforce a stricter rule set during the evenings--such as lowering the threshold for failed login attempts--or turning off a template that checks for file changes in a given directory during known backup windows.

IDS/9000 employs encrypted channels when communication occurs between the IDS/9000 GUI and its agents. Those communications are encrypted using SSL3 with a 1,024-bit key for setup and 56-bit DES during the session. SSL is provided via the RSA BSAFE toolkit. Eventually, encryption will be configurable, adding higher strengths, but this won't be implemented until the next major release, at least a year from now.

Communication across a firewall requires two ports to be opened, but these ports can be secured by only accepting connections from known hosts. For those IDS/9000 agents that must traverse the wilds outside the LAN, HP made them smart enough to discard any connections that don't legitimately come from the GUI, minimizing the possibility that agent communication can be blocked by a denial-of-service attack.

With kernel calls providing real-time information on what the kernel itself and various processes are doing, a certain level of performance load must be expected. The extra load will vary depending on the number and the types of system calls that are being monitored. The greater the number of relevant security calls being monitored, the greater the potential for performance degradation. Thus, the performance hit is to some degree in the control of the admin, who decides which events to monitor and how often various templates are invoked.

According to HP, the TPC-C performance degradation is 1 percent on average. However, there are two templates in particular that can cause a greater load on the server: buffer-overflow checking and race-condition templates, which require more computational power. HP notes that in tests using a 32-way processor reference system running a full data warehouse application suite, with all the templates turned on, the average additional load would amount to a 6 percent performance hit. However, according to HP, some systems could experience extra loads of as much as 20 percent due to the checking performed by the IDS. With minimal effort, users can toggle the settings for performance or security. Since it's Unix, no rebooting is required, but IDS/9000 will restart the IDS process. HP recommends that users start with minimal features turned on and slowly turn on more templates as time progresses.

The Timetable tab in the Schedule Manager is used when an admin decides to activate the detection templates.

With such a useful tool, it must be noted that the kinds of checking that IDS/9000 does couldn't be accomplished without specific tie-ins to the HP kernel. HP, being the owner of both the HP-UX operating system and the hardware, has engineered the kernel to work in tandem with the IDS/9000. For the IDS/9000 to work on non-HP-UX systems would require HP to not only port the software, but force vendors to modify the kernel of their OSes. Doing this would then defeat the purpose of HP's goals to sell more HP hardware. So while IDS/9000 is free, don't expect to see it running on Sun or Intel platforms any time soon.

HP has designed IDS/9000 to run on anything from a single-processor machine up to a 64-way Superdome. Anyone who's interested can go to the HP Web site and download the software, including GUIs and any number of agents. Considering what you get, how easy it is to use and that it's free, its only fault might be that HP didn't design it to run on non-HP platforms.

Technical editor SCOTT SIDEL (ssidel@infosecuritymag.com ) is a senior security engineer with Computer Sciences Corp.

March 2002 Table of Contents

Copyright 2002 TechTarget