Host Intrusion Prevention Software

We focused only on server protection in this review; however, Platform Logic, Cisco and CA also sell HIP products for the desktop, and Sana says it is evaluating desktop support.

All the products we tested work similarly. Agent software installed on each server communicates with a central management site, sending log files and status reports and retrieving policy files. Agent software comprises two components, one in user space and a kernel piece. The user-space piece handles the GUI, logging violations and communicating with the management station. The kernel module or device driver captures system calls, which are then evaluated against the policy file. If approved, the call is passed to the kernel's API and does its thing. If denied, an error is returned to the calling procedure. The returned value is a standard kernel-error code, not a proprietary one. It's then up to the application to take action, send an inquiry to the user or exit. Applications do not need to be modified to handle HIP denials.

In Cisco's and Platform Logic's apps, we created a set of rules, and agents enforced them. These rules could include denying read access to certain files, denying registry write access or controlling what executables can do. Sana's Primary Response differs in that it detects and blocks unexpected behaviors. Instead of creating rules, we let the product's agent profile our machines for the amount of time it took to perform all normal functions. This adaptation process does not take into account time of day. Primary Response then determined a standard behavior model that knows what processes normally access which directories and the order of system calls--Primary Response is unique in being able to detect the normal order in which system calls are made. Our attempts to inject breakout code, for example, were thwarted. One advantage here is that we could just plop the agent on the server and it figured out the rest.

Computer Associates' eTrust Access Control differs from mainstream HIP software in that it has more of an access-control focus, which means the system is based on user-access capabilities instead of processes. This by itself is not inherently better or worse than process-based products, just different. One area that's a good fit with CA's approach is in situations where multiple users need to log into a server, and the operating system's access controls aren't granular enough.In the reader poll for our recent patch-management review "Save Your Ship", more than half of respondents said having the time and staff to test and deploy patches was a big problem. HIP can help here--all products tested protected our unpatched IIS servers from Blaster, Code Red and all other attacks we threw at them. Of course, the next worm might target a hole not covered in our HIP policies, but we're confident that these products will buy us some breathing room.

In addition, during our tests, we were able to install patches surprisingly well. We took our Windows 2000 SP2 IIS Web server and upgraded it to SP4. Cisco's product, with its included Win2K and IIS policies, even let us upgrade without having to disable the agent, though we did have to click an "allow this action to happen" button. If you use a more locked-down policy with administrator restrictions, you may need to turn off the agent. Platform Logic's default Windows policies, for example, didn't let us upgrade unless we disabled the agent or turned off protection, and Sana required us to turn off the agent and then let it re-adapt. CA's product doesn't have canned policies, so your settings determine whether you can install patches or modify policies.If you're a member of the "better safe than sorry" camp, you'll probably want to disable the agent and network connection, install the patch or software, and then re-enable the agent. Note that though our upgrade didn't require modifying the policies for IIS to continue working (except for Sana, which required a re-adaptation), it is possible for a patch to require modifying the policy. If a patch changes the naming convention of log files, for example, your policies may need tweaking.

What We Still Want

As we said in "Last Line of Defense," implementing HIP is a pain in the rear. That's largely intentional--enacting fine control over your system, down to which registry keys and directories a process can read or write, rightfully requires hands-on attention. The software from Platform Logic and Cisco both include profiling capabilities that let us specify a process or processes to watch on a server, generating a profile of the application. These profiles included accessed directories, file access, registry entries and other access-control options. We then could edit the profile manually and import it into our rule set.

Sana's product automatically profiled our servers to determine their normal behavior, but we couldn't easily modify or even see the profile. CA doesn't offer an application profiler; rather, it simply plopped us in front of a blank screen to have fun for a few hours.

Profiling applications was a bit tricky. We did a profile of Notepad, a simple application by any standard, to illustrate this point. There were several dozen registry reads and file read requests. We created a text file and saved it to the desktop. The Cisco, Sana and Platform Logic profilers interpreted this action as, "Give Notepad.exe read and write access to any .txt file on the desktop," and nowhere else. These three products all attempt some wildcarding in their profilers. In the Notepad example, Cisco's CSA gave access to any text file on the desktop for any user. Sana's product could interpret if a program should have write access to a directory and allow it.Remember, too, that log files must be rotated occasionally. If your policy is too restrictive, or the profiler doesn't detect log rotation, you may find that logfile.txt is permitted but logfile2.txt is denied. We easily created a policy in Cisco and Platform Logic that allowed write access to logfile.txt only. When IIS tried to cycle the log, it got a violation and couldn't cycle. The solution was to allow read/write to logfile*.txt. Cisco's profiler was relatively easy to modify, thanks to its extensive use of macros and file sets. Platform Logic's AppFire profiler wasn't as clear-cut because it generated a ton of rules.

We'd like to see finer control of role-based administration across a group of machines. For example, we wanted to create a group of servers and assign an administrator to modify only that group. CA's product allowed this, as did Sana's, but Cisco's CSA and Platform Logic's AppFire didn't offer that much granularity.

We also wanted better reporting capabilities. Sana offered the most useful reporting information, but no vendors made it crystal clear what went wrong or which rule was violated. Platform Logic's product was especially poor in this regard, displaying only a long list of violations.

In the final analysis, though the products from Cisco and Platform Logic are nearly identical in features and operation, Cisco won our Editor's Choice award, because CSA had some of the best canned policies, centralized management features and reporting of the group.

Pricing is quite complex, with management stations, a variety of agents, and support and services all thrown into the mix. To get a ballpark estimate of your cost, see "HIP Software Features" for detailed pricing breakdowns and the cost of our scenario. Although these products seem expensive, they all, quite simply, worked. None of the attacks we threw at them caused a breach of information or elevated access rights. Of course, we did not do a full penetration test--such testing requires hundreds of work hours and thousands of dollars per product--so our results are not a 100 percent ironclad guarantee of security. But tossing Code Red at a vulnerable machine and ending up with an "attack failed" message instead of a command shell was quite a feat.The biggest change since Cisco bought Okena is that the company has integrated the HIP product previously known as StormWatch into CiscoWorks. In fact, you must install a copy of CiscoWorks to manage CSA (fortunately, this doesn't add to the price). Aside from a bunch of reboots to install the bloody thing, the bulk of CiscoWorks can be ignored if you don't want to use it.CSA management is performed through a Web interface, and one of its key strengths is its canned policies. We found built-in policies for Microsoft IIS and SQL, standard Windows processes, Apache, DHCP, DNS and many more. Sendmail, iPlanet and Apache policies are available on the Unix side. CSA supports only Sun Solaris and Windows, but the vendor says Linux support is coming this year. For the most part, the management interface kept Unix and Windows policies and settings separate, making it easy to see which policies go to which OS.

Each policy is comprised multiple rules. A rule specifies to allow, deny or query a user for access to a resource. The "query user" command is used chiefly for desktop control. We could set rules for network, file or registry access, as well as for restarting services, limiting connections per minute and specifying which applications a process can run. For example, we denied FTP servers the right to execute command shells by creating a deny rule for application-class "FTP servers" accessing $command shells. An application class is a list of potential processes grouped together logically; we specified all the FTP programs we used here. If we wanted to install a new FTP program, we'd simply modify the FTP applications macro, and that app would be added instantly to all policies that reference it.

We could create macros for file groupings, network addresses, services, registry entries and COM components, and they can be used in multiple levels. It took us less than 10 minutes to understand and appreciate this flexibility. Platform Logic offers a similar feature, but it's not nearly as easy to use.

Next, we set up groups. A group is a collection of machines and associated policies. CSA let us combine multiple policies into one ¼ber security policy. We created a group called "IIS-DHCP" and associated our built-in IIS and DHCP policies. We then created a custom install agent to register the server into this group automatically. We could even download the installer directly from the management station via HTTPS. After we installed the agent, the node downloaded its policies, and we were good to go. Our only nit: We'd have liked a tree view of the groups. As it is, we could look at only one group membership enrollment at a time.

CSA uses Crystal Reports for report generation. These reports are suitable for printing, but we would have liked hyperlinking to various elements. The alerting engine is excellent. We could configure an event to be sent via e-mail, SNMP, pager or piped to an application. Even better, we could easily correlate different types of events to different people, depending on the server group, event type or affected policy.Cisco Security Agent 4.0.1. Cisco Systems, (408) 526-4000, (800) 553-6387. www.cisco.comTake CSA, give it a less intuitive management interface, and you have AppFire Suite. AppFire has two management interfaces. From the Enterprise Manager you assign policies to servers and make canned policy changes. Then you use the Authoring Environment to make more detailed policy-file adjustments.

Canned policies make life easier, and AppFire is the only product we tested to have a canned policy for Exchange servers as well as for SQL and IIS. It was easy to change canned settings, for example, to allow or deny traffic to certain IP addresses; block modification of files by any program; and turn protection on or off for certain services. On the downside, creating policies was quite confusing, and we could look at only one policy at a time. It was difficult to see and understand what the policy was actually doing. Crafting a policy requires some hefty training or manual reading. In contrast, Cisco's product let us create a policy without reading the directions.

Once our nodes were connected to the AppFire management server, we could place them into groups, which also could contain subgroups. We then attached a policy to one of our groups, and every node and subgroup contained therein took on that policy--a fact we could verify by viewing a collapsible tree format. A policy also can be assigned to a single node.

AppFire does not support inherited changes. If a subgroup is assigned its own policy, for example, the parent's policy doesn't affect it. This means you can't create a limited master set of dictated policies that can be modified at any time. None of the products we tested offer inherited policies, but Cisco's CSA came closest by letting us create multiple small policies, which were then merged and sent to the client.

We were disappointed in AppFire's reporting engine. We were presented with a long list of violations, but very little information on what, exactly, had gone wrong. We could e-mail alerts to one or more e-mail addresses per group or node, but there is no support for SNMP.The best thing AppFire has going for it is price. It was the least expensive product, at about a third less than CSA's list price. That almost makes up for the time spent trying to figure out what our policies did.

AppFire Suite 3. Platform Logic, (301) 854-5550. www.platformlogic.com

Primary Response has no rules, no policies and no signatures. Instead, it learns the normal behavior of a system, and thereafter allows only what is deemed normal.

We initially placed the agent software in monitor-only mode. We could set an adoption window from one to 18 hours. Sana recommends using the server normally during this period, and after three similar adoption windows, the machine was profiled, learning system calls, access directories and program behavior. Any events that didn't occur during this adoption period were thrown up as alerts, and we could then specify whether to allow that event to occur. If your backup software runs only once a week, for example, it might not be learned during the adoption period. When it runs, the backup would create an alert, and you could then allow it.

One technique we used after profiling was to leave the machine in monitor-only mode, watch for all permissible but infrequent events and create our exceptions. We then locked the machine down.

Primary Response doesn't let you see the policy file, but that's OK because it can't be modified anyway. We could only create and undo exceptions, which are merely granted permissions outside the norm. We found the hidden profile disturbing. The profiling also assumes that the machine is clean during the adoption period, which is not always the case. If a machine changed radically, or we installed a service pack, we had to readapt. On the other hand, buffer-overflow protection was on during the learning period, and Sana says that having this learning capability makes administering the product easier. We have to agree--protecting our network was hardly any work at all. However, call us paranoid, but we didn't like not being able to look at or modify the policy.Management was relatively simple, and group management was flexible. We could create group administrators who are allowed to modify only the machines assigned to their groups. Primary Response also has excellent reporting capabilities. During our controlled attacks, "alert-in-progress" messages showed up. The product delays full reporting in order to collect forensic information and check for repeated attacks. Information collected included the command line arguments, working directory, everything that netstat can dump and all files being touched. We could even specify a log-file location, and the last few lines will be gathered as well. None of the other products offer this capability.

Primary Response 2.1. Sana Security, (650) 292-7100. www.sanasecurity.comJust because eTrust Access Control finish last-in this review doesn't mean we didn't like it or that it's weak on security. Indeed, we found it quite powerful, though cumbersome to use and very expensive, with a list price at least double that of its rivals. The other vendors charge less than $1,500 per server, while eTrust lists at $3,500. What you gain for your buck is a level of control the other vendors don't offer, namely the ability to restrict users. ETrust also can act as a central repository for creating and modifying user profiles. We easily added new users to a server's local user store, be it Windows or Unix. Speaking of Unix, in typical CA fashion, eTrust also covers the widest breadth of operating systems. If you support many operating systems, this product is for you.

However, eTrust AC lacks canned policies and a profiler, though the company says canned policies are slated for the next release. This means you're going to spend a lot of time figuring out how to do simple tasks, such as locking down IIS. We had the on-site tech working on blocking CodeRed for a few hours, and we succeeded only after getting a 39-line script from CA.

Nothing came easy with eTrust. For example, we created a policy model, which is basically a group policy. Machines that subscribe to a policy model will inherit it and any changes made. Unfortunately, we had to subscribe machines manually--no auto add or ability to scan network options here. Processes are treated as virtual users. One thing to note: eTrust can create internal users in addition to Windows or domain users. For example, we could create an IIS user that was associated with the IIS process. Then we could create access rules for that IIS user, such as read only to the Web directory and write to log file directories. We couldn't create rules for a process directly, though, because eTrust AC is user, not process, centric. On the plus side, this setup afforded us fine-tunable control over user access to server resources. An unprivileged user could be allowed to log in locally and write only to the Web directory, for example, while another could be given access only to the log file directory. This is similar to sudo for Unix.

We were also pleased to see time-control capabilities. None of the other vendors let us restrict access or program execution based on time of day or week.ETrust AC integrates with some other CA products and supports Unicenter calendars (CA says the product will be the security center for Unicenter eventually). Alerts could be sent only with the eTrust Audit component, which we did not test.

Bottom line, despite eTrust AC's unique features, it's just too difficult to create and maintain policies with it. And, though we're aware that the prices we receive don't always reflect street pricing, we still think this product costs an awful lot of money. Maybe when the next version comes out with canned policies, our tune will change.

eTrust Access Control 5.2 (for Windows), eTrust Access Control 5.1 SP2 (for Unix). Computer Associates International, (800) 225-5224 , (631) 342-6000. www.ca.com

MICHAEL J. DEMARIA is an associate technology editor based at NETWORK COMPUTING's Syracuse University's Real-World Labs. Write to him at mdemaria@ nwc.com.

Our testbed consisted of one dedicated management server, three protected servers and an attack machine. All were dual 600-MHz Pentium III machines with 512 MB of RAM, except for the attacker, which was a single 600-MHz Pentium III. We ran Windows 2000 SP4 on the management station, but each protected server had only SP2; no other patches were installed. We then ran a variety of attacks, such as Blaster, Code Red, Jill and IIS decode.

R E V I E WHIP Software

Sorry,
your browser
is not Java
enabled

Welcome to

NETWORK COMPUTING's Interactive Report Card, v2. To launch it, click on the Interactive Report Card ® icon

above. The program components take a few moments to load.

Once launched, enter your own product feature weights and click the Recalc button. The Interactive Report Card ® will re-sort (and re-grade!) the products based on the new category weights you entered.

Click here for more information about our Interactive Report Card ®.