 |
 |
 |
|
|
|
 |
OSSIM is often misconstrued as a tool that can store alerts in a central location. It is possible to do this, but it is not recommended. OSSIM is, by design, an information management tool, not a storage tool. It is designed and built to manage your CND alerts and infrastructure. There are other, more efficient ways to store alerts centrally and this article shows you how to do it.
The OSSIM Server is a tool that collects, analyzes, and stores some information. The tool keeps CND data in memory for varying lengths of time. Alarms are created based upon matches of that data. The OSSIM Server stores those alarms in a database. Alerts that do not match into an alarm eventually age out of the server. This aging is based on a risk algorithm and constraints defined by alarm rules. This means that the OSSIM Server does not store all data it receives.
Certainly, a generic rule could be created to match all incoming data. This would be a very bad idea. Such a rule would turn the OSSIM Server into a data storage agent. The OSSIM Server should be busy correlating , analyzing, and collecting data. Instead, the rule would force OSSIM Server to spend most of its time churning on database inserts and commits. This would eliminate the whole point of the OSSIM Server.
If you want to store alerts, it is highly recommended that you use the native sensors default storage mechanism. Regarding commercial products:
This is all fine, but what about open source tools like snort and ntop?
Central storage of Snort alerts is best handled using the barnyard program. The best documentation for barnyard is in the Syngress Snort book published through Jay Beale’s Open Source Security Series. Chapter 11 in the 2.1 version of the book covers everything you need to know to setup and run Barnyard. I will not divulge exact details here, because the book is well worth the money. I will say a few things though.
Make certain you run your database on a separate computer and be certain that you run barnyard at a lower process level. You might complain about needing a separate computer, but you need it. You will understand why if you do a performance comparison. Database inserts are expensive. Do not use a database on your sensor. Your sensor will spend more time dropping data packets even with the latest multi-core architectures. Changing the priority of the process varies by OS.
Ntop is an interesting beast – you may not want to consolidate all of its data in one place. Ntop data is very time sensitive data. It is probably best to leave it at each sensor. There is a great tool called Cacti that allows you to work with multiple rrd repositories. I highly recommend that if you need to consolidate ntop data.
If you are interested in OSSIM, you can purchase a distribution from our website. Lomin Security maintains and sells an OSSIM distribution called SIM CD. SIM CD is an installation CD that installs OSSIM and preconfigured tools. The SIM ST Appliance is the same solution, but instead of a CD you receive an appliance. The appliance has a standard installation and support contract. Custom versions of the appliance are available for different applications.
 |
 |
 |
 |
|
 |