Elasticsearch Audit Logs are Incomplete and lacks important information

Hello,

We recently configured the Audit logs on our on-prem cluster and configured an Elastic Agent to collect it, the goal is to build some custom dashboards and maybe some security rules on this data.

While doing some tests we noticed that some audit events are pretty basic and lacks important information.

For example, the events change_enable_user , change_disable_user and delete_user from the security_config_change audit layer have the information about the user that received the action, but no information about the user who performed the action.

Also, the integration wrongfully populates the event.outcome field with failure which can be misleading.

A delete_user event audit log looks something like this:

{
  "type": "audit",
  "timestamp": "2024-12-19T01:16:38,497+0000",
  "cluster.uuid": "redacted-uuid",
  "node.id": "redacted-uuid",
  "event.type": "security_config_change",
  "event.action": "delete_user",
  "request.id": "5o8XcGSYToe0MgcyzPmP3Q",
  "delete": {
    "user": {
      "name": "testUsername"
    }
  }
}

I have only information about the user that was deleted, not who deleted it or if it was successfully or not, so it lacks information about who performed the action and what was the outcome.

Since Elasticsearch is a security tool and is used as a SIEM, not having this kind of information in the logs can lead to some issues in the case of external audits for compliance reasons.

These are just some examples, probably there are other similar issues with other logs.

Am I missing anything on this?

Well, it seems that I was missing something.

To know which user performed which actions you may need to have the access_granted audit events enabled.

I've disabled it because it generates an insane amount of logs, after temporarily enabling it I was able to match a delete user request with the user that made the request by filtering on the request id.

But I still think that the log is still incomplete, it should just be one single event with all the information.

I also could not find any documentation about this, or any documentation on which actions would log this, the solution was to let the audit logs for access_granted populate some events to know better what to filter.