Zate, I would love to see the ruleset you've come up with for Windows. I've been trying to out the time towards this, but have not been able to yet.
Would you be willing to share what you've come up with? Scott Klauminzer Director of Information Technology & Security Sent from my iPad On May 22, 2012, at 8:04 PM, Zate <zat...@gmail.com> wrote: > We actually got it working well with Option #1. We were able to regroup the > alerts into groups that made more sense. "Windows DC Logon Failure" just > wasnt granular enough for us, there were thousands of events, some of which > we didnt care about and some of which were different typeof events, depending > on the subcode. > > so we went through and grouped all the event ID's and sub event codes into > new groups (such as locked account, bad password, bad username etc etc) and > then wrong some child rules to match on the event ID via <if_sid>. > > It's working reasonably well now, and now I am changing some parts of the > splunk app to make it work a little better, fixing how it matches on > user/account name/user name etc. It often only matches on the first > occurance when we really need the 2nd. > > All in all the dashboard is useful now, I can instantly see a spike in > events. > > after I get the matching fixed, going to work on grouping events into > transactions as we will get 6-8 events for every one "real" event, like > changing a security group. I can match them to a transaction vis the SID > used, should make it so I can get a true incident count. > > Zate > > > On Tue, May 22, 2012 at 9:40 PM, Michael Starks > <ossec-l...@michaelstarks.com> wrote: > On 05/18/2012 11:20 AM, Sanders, Nate wrote: > Help me wrap my brain around the actual design for this. It seems much more > complicated than it sounds. > > If I am understanding this correctly, this is how I would do it. Let's take > this one by one (see below): > > > - alert for specific Event ID's that contain specific sub codes > > You can do one of two things here: > > 1. Write a subordinate rule using <if_sid>. When you do this, you "take over" > the original rule, so as long as it matches, the original rule is no longer > in play. So if you don't want to be alerted on or log event ID 4769, you > would do something like this: > > <rule id="100000" level="0"> > <id>4769</id> > <description>These do not matter</description> > </rule> > > 2. Use the overwrite option to simple rewrite the original. To do this, copy > the original rule to local_rules.xml and add overwrite="yes". > > > - don't alert on the parent ID unless you've verify the sub code matches > > This is the same thing really. > > > - regroup Event ID's into better groups (Bad Password, Invalid Username, etc) > > Your rules can contain arbitrary groups to your liking. For example, you > could just add <group>mycompany_failed_logins</group> > > > Problems: > - Original rule groupings contain multiple Event ID's per group > > I think what you mean here is the composite alerts contain the possibility of > multiple different events. This is by design, but can be changed by adding > <do_not_group /> to ossec.conf. Why is it designed this way? Well, imagine > someone trying one failed logon to each service running on a box to one > account. OSSEC would see this as multiple failed logons if there were a > composite rule using <if_group>. Make sense? >
