Need Some Advice Regarding Data Ingestion

[tthiry (Tony Thiry)]

Hello,

I am ingesting Windows certificate data via winlogbeat and the "Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational" channel to I can track certificates that are expiring. I am using the "include_xml" switch and the "decode_xml" processor in my winlogbeat configuration. That all seems to be working fine.

The fields that get parsed look like this:
"event.userdata.certnotificationdata.action"
"event.userdata.certnotificationdata.accountname"
"event.userdata.certnotificationdata.certificatedetails.notvalidafter"
"event.userdata.certnotificationdata.certificatedetails.subjectnames.subjectname"

As you can see they are quite long. I'd like to map them to ECS fields but I noticed that there are TLS fields and x.509 fields and I am confused as to which one I should use. Also I want to ensure that the "event.userdata.certnotificationdata.certificatedetails.notvalidafter" is a date or timestamp field so that I can do date math on it to report on expiring certificates.

Does it matter which set of field sets I use?
Can I mix them?
Can/should I add field that don't exist in the ECS? for example If I want to keep a record of the user who deleted a certificate, can I rename "event.userdata.certnotificationdata.accountname" to "tls.client.accountname"?
Or, should I make my own fields e.g. cert.XXXX so that I'm not confusing the fact that the certificate information was not gathered view network traffic ingestion, which seems to be the use case for the TLS and x.509 fields?

Thanks,
Tony

[ebeahan (Eric Beahan)]

Hello, @tthiry!

Does it matter which set of field sets I use?

Are these logs related to Windows certificate services? If these events aren't part of a TLS connection, don't use tls.*. Instead, I'd recommend using the file.x509.* fields.

Can/should I add field that don't exist in the ECS? for example If I want to keep a record of the user who deleted a certificate, can I rename "event.userdata.certnotificationdata.accountname" to "tls.client.accountname"?

Adding custom fields is fine if you follow the best practices. In this case, however, I'd suggest using the top-level user.* fields to capture the record of the user who performed the event. By doing this, you can query across other normalized events using user.* fields.