ECS Audit logging lack of identifiable description on saved object

[Leaf-Lin]

Describe the feature: As of writing, when ECS audit logging is enabled, we can see the saved object is getting accessed, found or deleted via its ID. Sample ECS audit log message looks like [1]:

User is creating search [id=xxx]
User has accessed search [id=xxx]
User is requesting [/api/saved_objects/search/xxx] endpoint
User is deleting search [id=xxx]

But there's no clear indication what saved object is associated with ID xxx. If the saved object has not been deleted, one could do GET .kibana/_search?q=xxx to identify the object.

Once it was deleted, is there a way to identify from kibana audit logs?

Describe a specific use case for the feature: Having the ability to identify deleted saved object from ECS audit logs.

---

[1] Saved object here could be search/index-pattern/map/visualization/graph-workspace etc.

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[jportner]

For this to be useful, we would probably have to add the object title/name to all audit records. Otherwise an attacker could confuse the audit trail by renaming the object before deleting it. That said, I think a human-readable description of the object (if it exists) would probably be a great addition to the audit records.

For delete, update, bulkUpdate: The SavedObjectsClient (SOC) wrapper an operation for a given type/id and writes it to the audit log, it doesn't have any more information about the saved object itself. We could potentially add a preflight check to fetch the object first. The repository itself also conducts its own preflight checks as part of the space context.

We worked around this problem with the new updateObjectsSpaces API by allowing the SOC wrapper to add a preflight check for data and pass it down to the base client method, so the SavedObjectsRepository (SOR) doesn't need to do another preflight check. We could potentially change delete, update, and bulkUpdate to behave the same way.

---

Another thing to note: there is no "root-level" field to describe saved objects. Each saved object type may define its own "type-level" field (such as attributes.title or attributes.name), but our SavedObjectsClient wrapper does not understand what field it is. Plugin authors define a function that returns the object's human-readable title, but this assumes the entire object is available, so it means we can't just fetch a subset of the object's attributes for the purposes of the preflight check. That means that, over time, a lot more data will go across the wire from ES to Kibana. I think it would be worthwhile to consider adding a root-level human-readable field for all saved objects. I've been planning to open an RFC for that for a while now but it's gotten away from me, I guess this is a good excuse to do so 😄

[ppf2]

Linking to meta issue: https://github.com/elastic/kibana/issues/52125

[mbudge]

We need this too.

We want to generate reports for IT controls, but the reports using the save object ID aren't user friendly.

We need the saved object name/description in the audit log, so we can report on what dashboards/visuals the user is accessing.

[Danouchka]

My customers needs to have kibana usage stats (how many times a dashboard was accessed for instance) Therefore after we enable kibana audit logs in the production cluster, we can go and fetch information from elastic cloud logs (elastic-cloud-logs-8 datastream) in the dedicated monitoring cluster filtering on (service.type:"kibana" and event.action:"saved_object_resolve" ). But there we have the kibana.saved_object.id but never its title. For now, I am fetching the information remotely from all .kibana indices in the production cluster and enabling an enrichment policy on the elastic-cloud-logs-8 template. Which is heavy Would be possible to send those audit logs with the (human readable) saved object title as well ?