Hey Johnny5:
Yes, it does seem overwhelming, with over 10,000 messages, and each of them seeming critical. The important thing to note is that not all of these 10,000 messages are equally critical for your environment. So how do you start identifying what's critical to your environment?
Here's what I suggest you do.
Use the risk-based profile of the assets that you are monitoring with the IDS solution and map the requirements out of the risk profile to the enVision Event Categories provided within the RealSecureIDS parser for each event. This will allow you to prioritize the categories for each asset - or network the asset(s) are located in, and then you can create correlation rules for each of the general areas that are identified from the mapping.
For example, if you are using the IDS to protect perimeter devices (Firewall - in front and behind of -, web servers, etc.) These assets represent "The Perimeter." Based upon your risk-profile, you might already identified event types such as Denial of Service, Brute Force Attacks, Injection Attempts, Recon sweeps that may result in the highest risk to your perimeter.
You can then create customized rules for each Event Category to include the necessary events (all if necessary for each event category.) One example could be a rule called "Denial of Service attempts" in which events that relate to the event category "Denial of Service" are included, with possible customized IP addresses that pertain to your Perimeter.
These "Perimeter Rules" can then be enclosed within a Overall View called the "IDS Monitored - Perimeter" - in which now you will put the correlation rules themselves, instead of the thousands of events. These rules will be your starting point to understand what's happening in your environment, how to tune, and develop more advanced rules going forward.
One note about Recon Sweeps - these usually introduce many false positives, as it equates to someone knocking on the front door without actually getting in. Perhaps you can create a rule with a high threshold from the baseline (say 50%) to help reduce the amount of alerts and identify exceptions. hat covers Perimeter Devices.
Rinse and repeat for different subnets or device groupings. For an internal subnet, a few suggestions for correlation rules would be more access-control oriented rules, virus/worm/trojan activities, and injection attempts, and create the Views as necessary.
You are going to have to do your research to understand what many of these messages could mean potentially to your environment, but at least now you don't have to learn 10,000 events!
Does this help?
Regards;
Mark Nadir.
