I am in the process of implementing a mars right now with about three sites and 30 pieces of network equipment.
Is it better to configure and load all the devices at once or load one at a time to watch and learn each devices characteristics? And to complicate things more, when planning to do an advanced setup, do you start with the base level configuration and grow to advanced or go right to advanced. I ask this because I am finding that one could get overwhelmed with excessive information. Should you just add choke points or every device you can?
Ben the amount of events generated by one ASA/FWSM alone is so over-whelming that you need to phase things very gradually to make the deployment successful (If the devices are already sending events to MARS). Otherwise you can add all of them together in MARS (using a seed file etc.) but gradually open the water tap on each device as you may say (by enabling syslogs etc. towards the MARS box). However there is no one rule for this. For example, If your IPS sensor's are already tuned then adding them in MARS will cause no problems at all. But if they are not, it would be better to do some 'device specific' tuning before adding them into the MARS box. Try to focus on the Firewalls/IPS in the first phase.
The above is the Cisco start point, but it seems to be silent on this topic.
I am thinking I could add all the devices but only have select devices reporting events so I will have a full topology graph. Won't I get "Inactive CS-MARS reporting device" for those devices I have not configured to report information yet?
Right now I have five devices loaded in mars, mars reports that four of them are inactive but i am pretty sure I am recieving events and netflow from them becuase i have alot of activity on the summary page. What causes mars to think that a device is in active?
If the devices are sending events and MARS is still showing them as Inactive, most probably the devices are using another source IP to send the updates than the one you configured when adding the device.
Goto Query >> Raw Events (or something)
Select Real-time events. And look at the source IPs of the reporting devices.
This can also done by viewing the raw messages in on the 'Administration |Tab'
Yes if they don't report, then they will show as inactive, but that is not really a major issue. That is sent just once at the start of every hour.
"Won't I get "Inactive CS-MARS reporting device" for those devices I have not configured..."
Yes, you will.
"What causes mars to think that a device is in active?"
If MARS receives even a single event in a given hour from a device, it won't generate the "Inactive CS-MARS reporting device" event for that device. Run a query for that specific device and that specific time to determine whether you have any events.
All responses are greatly appreciated. I will dig into this and try to find out more about it. Is recieving netflow considered and event?
Netflow is not counted towards this AFAIK. Because we have one router (even tough it is a backup interner router) sending netflow events to our MARS but it still shows in the Unactive device report.
Good to know. So, you'll want to tweak the "inactive reporting device" rule so that it only includes devices that consistently generate non-netflow events every hour.
Personal preference. I would recommend enabling all the logging you intend to have as a first step, and once you've verified that all the reporting devices are working correctly, start tuning. You will likely find that the same few rules are filling the incident queue. Use the "matched rule ranking" to find the heavy hitters and drill-down and tune from there.
So when I am "tuning", where should I be doing this. Should I be modifying system rules to ignore certian perameters or create custom drop rules? Should I make the rules very specific at first, then add to them as needed?
I think that boils down to personal preference again. Some inspection rules just have silly "count" values. You probably don't want incidents whenever there are 3 failed logins, for example. In this case, you will copy the system rule and then inactive it. Next, you edit the copied rule count values. With the exception of modifying the count value, I would try to utilize drop rules whenever possible. Sometimes a drop rule, because they lack keyword functionality, isn't appropriate because it is too broad. You may be forced to modify a system inspection rule.
Ben, the best place to tune the event is to tune it at the reporting device. However this is not always possible. For example the ACL logging on a firewall, you can't really filter it out at the firewall in a meaningful way. But for example, IPS signature alerts, almost all of them can be restricted based on Source/Dest IP/Port at the IPS only using Event Action Filters. This reduces valuable resources on the MARS box (processing, EPS, hard drive etc.)
If device-specific tuning is not possible, I try to use drop rules to filter the noise. I try my best not to modify the system defined rules, as this creates issues when the current guy leaves the job and things are not well documented. Or for example the new 6.0 release will require re-imaging of GEN1 appliances, then things get confusing.