Yeah I dont see a problem with sharing it. Nate actually did most of it, and we are still tweaking it a little but give me a week or so to get the bugs out and I dont mind sharing.
Zate On Wed, May 23, 2012 at 9:23 AM, sklaumin...@gmail.com < sklaumin...@gmail.com> wrote: > 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? >> > >
