Sure thing. Take "Windows DC Logon Failure"
it has a bunch of ID's associated, one of them is 4769 that id is "A kerberos ticket was requested", but has a bunch of result codes, most of which we dont care about. http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4769 So the rule is classsifying anything that is 4769 as Windows DC logon Failure. Even that is too generic. Was is bad password? Bad username? something else? Ideally I'd like to lump all the bad password codes/sub codes together. what we are having problems with right now is writing a sub decode that pulls the Result Code from the 4769 event so we can have a rule that say generates an event of "Password has expired" for 0x17 instead of just lumping everything into the one area. ID 675 ( http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=675) is the same, shows up as "windows DC logon failure" but gives no indication of what the failure code is. Again, we'd like to put in a sub decoder to pull failure code so we could use it in rules to more accurately label the type of failure. so ideally we would go and pickout error codes that should go together, that generally mean the same things (bad password, bad username, etc etc) and put them all together in a rule. Report them as the same kind of alert. It's al ittle frustrating to be trying to rewrite some of this stuff as not all of it is documented. For example. the sub decoders, very little is written on how it all actually works and we are unsure if we can add a new field? such as error_code or if we have to use extra_data? or something else? How do we add these sub decoders and still have the main decoder process things? Am I missing something? this is how I am understanding it looking at what I have in front of me. Zate On Wed, May 16, 2012 at 8:59 PM, Michael Starks < ossec-l...@michaelstarks.com> wrote: > On 05/14/2012 11:26 AM, Zate wrote: > >> How did you deal with the windows event ID issue in the rules? Some of >> the ways the events are grouped do not make sense. It's not using the >> sub event ID as far as I can tell so it is lumping alerts of differing >> kinds together. This was something we found when putting the alerts >> into splunk, things like wrong password were spread >> across multiple different event ID's and handled differently by >> different rules. made it hard to get like events all grouped together. >> > > I'm not sure I entirely understand your issue, but I would like to. What > do you mean about "sub event ID?" As to the lumping alerts together, that > is by design unless you change the option to not group alerts. >
