Document all possible event_data.* fields?

[rivaanbechan]

Hi,

Is there any list out there with all the current fields that is possible to receive within "event_data".

I would like to further filter the subfields. Although I need the list to get a baseline.

Please assist me.

Thank you,
Rivaan

[andrewkroh]

It's not feasible to compile a list of all possible fields for all events since it's up to the applications that log the events to name their fields.

You could build up a list of field names for different applications. The field names are specific to an event ID. So the meaning of a given field's data could vary between events with different IDs.

Could you whitelist fields that you do want to allow? This would require you to know only the fields that you want to keep vs. knowing all fields you want to drop.

[rivaanbechan]

Hi Andrew,

Thank you! I didn't realize that this is up to the application that logs the event. I assumed that winlogbeats did renaming and extractions on the "message" field.

Yes, the plan is to whitelist, although just wanted a broad scope to understand the dataset and what provides enough value to keep.

So the way forward for me would be?

My assumption is, index a large volume of event logs, identify valuable fields within event_data and then do the whitelisting?

Thank you,
Rivaan

[andrewkroh]

@rivaanbechan

My assumption is, index a large volume of event logs, identify valuable fields within event_data and then do the whitelisting?

That sounds like a sane approach. You'll probably also want to blacklist some events that add no value to your use case (by using source_name + event_id to uniquely identify the event).