-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parsing Keys from EventData #110
Comments
Thanks for the report. I understand the issue, as well as #95.
We would need the #95 feature for this, but it would not be possible now, as I commented on #95 (comment).
It would not be enough for this issue, but if you need this feature, we should improve this plugin. |
Thanks for the response, @daipom! I'm also not sure how to use the API to take the Currently I have very little Ruby and general API experience, but in the future if I have the time to look further into this then I'll give it a try. |
Is there a way to parse EventData with the fields included rather than parsing the Description with the description fields?
I'd like to use the field names from EventData because NXlog is supported by my event collector and this is what NXlog does. For example, in the Security log 4624, is the EventData fields "TargetLogonId", "TargetUserName", and "TargetUserSid". While, parsed from the Description these fields are "new_logon_logon_id", "new_logon_account_name", and "new_logon_security_id". I was able to get the keys to be in Camel case without underscores by editing the to_key function:
and by removing the period on line 392 to be:
k = "#{parent_key}#{to_key(key)}"
After these changes, the fields are "NewLogonLogonId", "NewLogonAccountName", and "TargetSubjectSecurityID" which still is not the desired field names. I've realized that what I want is probably only achievable from the XML Key values in the Windows events by default.
Is there a configuration setting that achieves this? Or should I attempt my own implementation of it?
I would also be ok with solution described in issue #95, if that goes anywhere.
The text was updated successfully, but these errors were encountered: