CS-MARS default rules

randytoni · ‎06-21-2006

hi - Mars 4.1.5 just installed. I notice it's logging an incident based on activity on a domain controller (where it's pulling event logs).

As I understand it, a change to a computer account happens on the domain controller. That event (windows security event win-sec-646) gets logged in the DC event log. MARS pulls the logs, then matches that event to the MARS-defined event/signature "Windows 2000 Computer Account Changed". This MARS event belongs to the event group "Persist/Modify Host/User Groups". This event group in turn causes the rule "System Rule:Modify Host: User Group" to fire.

OK - so that seems to be the thread. But the question is - what does the windows event "computer account changed" have to do with a MARS rule that's supposed to be triggered by group modifications on the monitored system. In other words, does the MARS-defined event/signature "Windows 2000 Computer Account Changed" even belong in the event group "Persist/Modify Host/User Groups"? It seems very misleading that a rule which appears to be designed to detect changes to user group attributes is firing on an event that actually indicated computer account change.

Hope I'm making sense.

thanks

-randy

mhellman · ‎06-22-2006

Events are often mapped into multiple eventtype groups. That particular event is mapped to:

Persist/All,

Persist/ModifyHost/All,

Persist/ModifyHost/UserGroup

I can't explain why Cisco chose to map them this way, but I don't think the Persist/ModifyHost/UserGroup mapping is used by default in any rule anyway. The other two eventtype groups can be found in multiple rules.

randytoni · ‎06-22-2006

thanks for the reply - also don't know why these things are mapped out like they are.

Double checked on the MARS box here - the default rule "System Rule: Modify Host: User Group" does use the event group "Persist/ModifyHost/UserGroup, along with 2 other event groups:

Persist/ModifyHost/UserGroup,

Persist/ModifyHost/DB/UserGroup/Success,

Persist/ModifyHost/DB/UserGroup/Failure,

This is the rule that's firing when a windows event 646 (computer account changed) is captured by MARS. That's what's got me scratching my head - this 646 event has nothing (apparently) to do with a user group change on the source server, so why would Cisco map this event to the "Persist/ModifyHost/UserGroup" event group, which triggers a rule (apparently) intended / designed to detect group changes in general? Actually I think there may also be a couple of other similar events in this group that don't really make sense, at least to me, a MARS newbie - have not had time to really dig.

Can someone from Cisco please explain the rationale here? If MARS default rules are firing on events that don't jive with the intent / nature of the rule, doesn't that put a big dent in the trustworthiness of what MARS is actually reporting?

maybe I'm missing something simple - but when demo'ing this to a windows admin here and chasing down apparent user group changes, only to find out that they're atually macning account changes, it did not make a great impression. If I'm out to lunch here, I need to know. If the MARS mapping is not 100% it needs to be fixed. Just need to know for sure.

thanks again for the reply...

-randy

mhellman · ‎06-22-2006

ah yes, I apologize. I was only looking at active rules;-) That rule was disabled long ago for obvious reasons. Wouldn't it be nice if you could modify the mappings? Maybe while Cisco is explaining the mapping they can also explain what purpose using the SAME and $EVENT_TYPE01 and $TARGET01 variables has in a rule with two offsets combined with an OR...both of which trigger on a single event? I thought I understand how the variables work, but I really don't get that.

randytoni · ‎06-23-2006

no need to apologize - appreciate the replies and all sanity checks.

I agree - the ability to re-map / fine tune would be nice. But since that's not the case, I think that particular rule will also get disabled here. I'm slowly figuring this thing out. Wish I could offer some useful feedback on your point about the variables, but I still need to get my head around all that variable stuff.

thanks again

-randy