HIDS Comments, Suggestions & Questions

[Andy Torres]

I'm evaluating HIDS for the first time on our systems. We'd only need to implement it on two servers, both rp4440's with 4 CPU and 4GB RAM. We will be connecting an XP10000 over SAN soon as well. These systems are running Eloquence database instances. IPv6, Trusted, SSH, the works - very secure systems. We feel HIDS will help complete the security we feel we need.

From reading through the Sizing/Tuning Primer and the HIDS Admin Guide, my concerns are:
- Will I have enough CPU as the event load is increased?
- What size logs can I expect?
- Will I be able to configure this thing effectively without the GUI (we don't have workstations or own X-emulation software)?
- I am considering asking for a management server for SIM 5 soon. What are the pros/cons of running the HIDS admin system from the possible SIM server and treating the other two servers as agent systems?

I'd also like to hear implementation discoveries and gotchas to watch out for, and general opinions of the product from other SysAdmins. Any info will be rewarded. I value the community's insight.

I may not answer this thread until Monday, so be patient with point awards, okay?

Thanks very much for taking the time.

[Steven E. Protter]

Log size depends on how many features you select and what detail you decide on.

No.

The pro's of running HIDS from a management system is only the agents run on the production boxes but you still get full data.

That machine if reporting detail is high will be heavily loaded.

Other advice. Too much logging on the HIDS server means nothing much else will be able to run on the box.

SEP

[Pierre Pasturel · Accepted solution]

I am also very interested in getting sys admins' feedback concerning HIDS v3.1, as we do take customer's feedback into account when planning future releases. Versions of HIDS before v3.0 had known performance issues, and we have received positive feedback so far on the performance improvements with v3.x. The next future release, V4.0, will contain improvements mainly in alert reduction.

Now, to address your questions:

Q: Will I have enough CPU as the event load is increased?
This depends on the rate of and type of systems calls invoked by your applications, which detection templates you are running, and how they are configured. If your applications are file I/O intensive, there will be minimum HIDS impact. We only monitor certain systems calls (e.g., open(2) but not read(2) or write(2)). You can determine the rate of the systems calls produced by your applications and monitored by HIDS by acquiring a special version of the /opt/ids/lbin/idscor that calculates that rate for you. Please go through your normal support channel to obtain a special version of idscor for V3.1. Starting with V4.0 (tentatively available sometime in beginning of 2006), idscor has an option (-t) to calculate that rate for you. You can then refer to the graphs in the sizing/tuning paper to determine approximately the CPU and memory impact.

Q: What size logs can I expect?
By logs, I assume you are referring to the number of logged alerts. This again depends on how you configure your detection templates and which templates you activate as part of your schedule. You will probably need to fine tune your templates to filter alerts that you deem can be safely ignored. You can also fine tune your filtering using the response program facility, although this type of filtering is not applied to alerts sent to the GUI. Starting with V4.0, we will introduce alert aggregation to reduce the number of alerts for certain situations. For example, if you are monitoring the /opt directory for modification and you run swinstall to install a product in /opt, HIDS v3.1 can generate 100's of alerts, one for each file created under /opt. With alert aggregation, you will only receive one aggregated alert to notify you of the swinstall.

Q: Will I be able to configure this thing effectively without the GUI (we don't have workstations or own X-emulation software)?
The agents can be configured remotely using the non-graphical tool /opt/ids/bin/idsadmin. You can write scripts to automate the pushing of schedules. We have customers who also rely on idsadmin instead of the GUI for configuration. For monitoring w/o the GUI, you can use the response script mechanism to filter and forward alerts (e.g., via email, a socket connection, etc...). Regardless of the GUI, alerts are always logged locally on the agent host.

Q: What are the pros/cons of running the HIDS admin system from the possible SIM server and treating the other two servers as agent systems?
In short, you can more easily configure multiple schedules and manage multiple agents from the GUI. A con can be the CPU utilization of the GUI because it is a Java application.

Pierre