Correlation Rule Variables Filter / Multi-threading

[RSAAdmin]

Hopefully I can explain this in a way that makes sense.

I am very familiar with creating new reports in envision.  I can put together test reports that will show me where data ends up getting parsed to, and to filter down the columns that actually have the data we are looking for.

Now I am trying to move some reports over to alerts and I see that the variables that you can use for filtering and multi-threading do not match up with fields I see in the report tables.  Is there a way (utility, etc) I can identify what is going into these variables based on test data? 

The rule I want to make deals with windows 2008 user names, but I am not sure if I would use the Event User, Login ID or User Name variable.  For a report I would just run one and show the data for all three and see what is getting populated.  For this I am not sure how I can see which variable is getting the real username from a log message.

I would think there is a somewhat easy way of doing this, since you would often want to know what is in a variable.  Any info someone could provide would be GREATLY appreciated!!

[RSAAdmin]

Yeah, unfortunately the variable names don't map in a particularly friendly way, and it gets even more confusing with Windows since the events usually define several forms of username.

In the case of Windows events, this is how it typically works:

username is the variable associated with the user who initiated the action

event user is the variable associated with the user object being acted upon

(in some cases, these are often the same, although one may also show the domain in addition to the username itself)

Login ID is usually a hex code representation and is no often used, except in some cases where caching it across circuits may be useful.

Here's a good resource for understanding the fields a little better:

http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx

Just pick a message on this site and it shows you how the fields are laid out.

[RSAAdmin]

What you can do is to run a report like you mentioned, looking at logon Id, Event User, Client Username, Username, but also add in the Message ID and the Message itself.  Then you can look through at which events you are going to use in your alert and at the same time you will have the correct variable that you want to filter or multi-thread on.

Paul

[RSAAdmin]

Thanks Matt, you are right they don't correlate very well.  I did find the field I was looking for in that case!  The only thing left now is figuring out what goes into [CONTENT], and I opened another thread about that.  If !payload isnt used (and it almost never is for Windows), then I have no idea what will go into [CONTENT]!

[RSAAdmin]

The !payload marker should be in every HEADER tag for every event source.   It is a requirement - the XMLs would not work otherwise.

[RSAAdmin]

Actually you will find it in the Help file:

The content field is populated based on the payload data of each message. Payload is always defined within the XML that parses the message.

So, the [CONTENT] represents the content portion of the message:

Paul