I would agree with this, get all clients installed and reporting at the beginning otherwise you are tailoring rules to a 'half system'.
If you are concerned about the job of identifying which alerts need tuning I would recommend using AnaLogi (shameless plug), it's graphical and based on graphs, with it you can instantly see which alerts/logs/hosts are the loudest and need tuning first. When you get all the rules in place and things quieten down, you can always just wipe the logs/database and consider that a baseline/test period. Andy On Friday, September 28, 2012 3:43:01 PM UTC+1, ash kumar wrote: > > It is almost always better to collect everything and start eliminating > events that are not interesting or noisy rather than the other way around. > It does not take as long as you think it would and helps you learn to > navigate OSSEC and understand your traffic patterns better. > > Just looking at successful / unsuccessful logons is rather droll and > voluminous in reasonably busy network. You are creating a lot of alert data > and missing out on potentially more interesting activity. In my opinion > logons should be reported on daily for trending statistics or correlated > with other events to be meaningful. > > The File Integrity information is limited as it cannot return a lot of > useful information such what the change was or who changed the file and at > what time. > > In a nutshell, these goals for the POC virtually ensure disappointment. > > Ash > > On Monday, September 24, 2012 9:43:33 AM UTC-4, dan (ddpbsd) wrote: > >> On Mon, Sep 24, 2012 at 9:40 AM, Michiel van Es <[email protected]> >> wrote: >> > >> > >> > 2012/9/24 dan (ddp) <[email protected]> >> >> >> >> On Mon, Sep 24, 2012 at 9:27 AM, Michiel van Es <[email protected]> >> >> wrote: >> >> > >> >> > >> >> > 2012/9/24 dan (ddp) <[email protected]> >> >> >> >> >> >> On Mon, Sep 24, 2012 at 9:21 AM, Michiel van Es >> >> >> <[email protected]> >> >> >> wrote: >> >> >> > >> >> >> > >> >> >> > 2012/9/24 dan (ddp) <[email protected]> >> >> >> > >> >> >> >> On Mon, Sep 24, 2012 at 2:41 AM, Michiel van Es >> >> >> >> <[email protected]> >> >> >> >> wrote: >> >> >> >> > Hello, >> >> >> >> > >> >> >> >> > We are using OSSEC for a PoC and we want to show only some >> alerts >> >> >> >> > initially >> >> >> >> > and expand the alert list. >> >> >> >> > We are using OSSEC 2.6 mixed Windows and Linux agents. >> >> >> >> > 1 Manager and several agents and Splunk on the manager server >> to >> >> >> >> > show >> >> >> >> > the >> >> >> >> > alerts. >> >> >> >> > >> >> >> >> > For now we want to achieve to show only failed and successful >> >> >> >> > logins >> >> >> >> > and >> >> >> >> > file integrity alerts. >> >> >> >> > How can we achieve this? => manually going through all >> rules/xml >> >> >> >> > files >> >> >> >> > and >> >> >> >> > set accordingly all xml entries to 0 or anything else? (0 >> meaning >> >> >> >> > disabled >> >> >> >> > and dont show) or is there an easier way of achieving this? >> >> >> >> > >> >> >> >> > Kind regards, >> >> >> >> > >> >> >> >> > Michiel >> >> >> >> >> >> >> >> >>You can remove entire rules files if you don't want to use >> them. >> >> >> >> >> Just >> >> >> >> >>test your changes (/var/ossec/bin/ossec-logtest -t) after you >> do >> >> >> >> >> this >> >> >> >> >>to make sure you didn't get rid of something necessary. >> >> >> > >> >> >> > >> >> >> > Would you suggest creating specific rules in xml files with the >> >> >> > correct >> >> >> > alerts and move/disable all others and start from there? >> >> >> >> >> >> >>You should do it however you think is best. I don't like this >> >> >> >> approach >> >> >> >>and don't have an opinion on it. >> >> >> >> >> > What would you suggest? >> >> > >> >> >> >> >>I think you should do what works for you. If starting small and >> adding >> >> >>more later is better for your organization, do it. If I was going to >> >> >>do it that way I'd probably remove the entries for the rule files in >> >> >>/var/ossec/etc/ossec.conf. >> > >> > >> > Clear. >> > Thx will work something out! >> > >> > Michiel >> >> Good luck. Hopefully someone who has done something along the lines of >> what you're trying to do can post some tips & tricks. >> >
