-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[SECURITY] Endpoint only use host.hostname
#70201
Comments
@nnamdifrankie @ferullo @jonathan-buttner FYI on the above. We may want to populate both fields. The Endpoint would need to write both fields ( Let me know your thoughts or if you see any complications. The fields can just be copies of each other. |
This comment in the ECS repo gives an explanation of how we expect As we can see in the linked ticket, the naming and/or descriptions are not very clear since other ECS implementors have hit the same confusion. So we should probably discuss how to improve it in ECS, but until then, I suggest filling both |
@kevinlog on the kibana/registry side it touches all the events we send. Am sure it is the same thing on Endpoint side too. I thought that name was more arbitrary than hostname. But it will be a wide change. |
@ferullo based on the issue here: https://github.com/elastic/endpoint-dev/issues/6637 I think the endpoint is populating those fields for all messages already. I haven't checked the latest endpoint though to verify though. We will need to update the package for |
@XavierM @stephmilovic adding the changes for the data to master. |
I agree, please fill both. If the endpoint offers the option to customize machine names, this customization should affect Populating |
Pinging @elastic/siem (Team:SIEM) |
In the SIEM app, we are using
host.name
vs usinghost.hostname
. At the beginning of the project we were using onlyhost.hostname
but we switch to only usehost.name
because this field can be edited via the config file in beat.We think that the endpoint should fill
host.hostname
andhost.name
at the same time, so we do not need to have a workaround in every query and the user won't be surprised that it is different trough our security app.The text was updated successfully, but these errors were encountered: