Hi there.
I am trying to analyze some Windows security logs (as that is all I was given) from a client, using Elastic Stack and the security features and dashboards it provides.
I have managed to have winlogbeat create dashboards in Kibana and whatever else it does with the winlogbeat setup command, and I have imported all the Windows Security Event Log tagged rules in the Security section, before I start importing the data.
Currently, I send the data to an index that starts with winlogbeat- followed by the project it is related to, and the events are available to the dashboards and I would assume the SIEM rules as well, but it seems like some mappings are not done when I use winlogbeat directly to import. Perhaps the most important ones can actually be remapped in the winlogbeat config, but I’m a little puzzled why the dashboards except different field names than what winlogbeat creates?
For example, the Login dashboard, it expects event.code, but the imported field I get is winlog.event_id
Is something extra done using Elastic Agent that remaps this? As these are not the regular system logs, I can’t really use that in this case.
— UPDATE: I rechecked my yml-file, and it actually drops event.code for some reason. I’ll try to see if it works correctly if it does not drop it.
I expect there is the same mismatch in the SIEM rules. (if it’s only event.code, I guess I have my answer)
I also see a log of errors in the Kibana logs about some of the fields even just after the import before I have even added any data, which may be related.
I am using a specialized winlogbeat.yml file for this, so it’s possible there are some options I have not copied from the 9.2.0 distribution version, but I am using the standard winlogbeat.yml file to import the assets (dashboards, etc.), so I would expect it would create the lastest (as of that version) assets available. There does seem to be a lot of mention of version 7 or 8, so I assume there aren’t really much in the assets that are new to version 9?
I have exported the Kibana log from the container it runs in. It takes up quite some space. Is there anything from it you would like to see to help debug this?
It seems many of the fields I get imported end up with type ‘text’ in stead of ‘keyword’ and thus creates a mismatch, but even before that, the SIEM rules seem to balk at some field names…
I will try another import that does not remove event.code, but I expect there will still be issues with keyword/text and the fields Kibana had trouble with.