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: #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 ?

[lukeelmers]

My customers needs to have kibana usage stats (how many times a dashboard was accessed for instance)

@Danouchka Just a heads up that basic dashboard usage stats will be shipping in 8.16, which depending on your use case might help you to avoid using audit logs for this: #187993

[Danouchka]

Hi @lukeelmers , we will have dashboard usage stats but will we able to broke them by user/authentified account ?
We have those stats at dashboard level but we will have a general dashboard showing the most used dashboards or the most used by user ?

Many thanks for your answers, Dan

[Danouchka]

@lukeelmers just a gentle reminder about my questions above. Than you very much

[lukeelmers]

Hi @Danouchka - no, this particular feature will not correlate dashboard views with a particular user. For that, you'd still need an audit log-based solution as described in this issue. I only mentioned the new usage stats feature in case there are folks who only need anonymized stats.

There are not currently plans to have a global dashboard for freeform analysis of usage data. However, I believe we do intend to have the ability to sort a list of dashboards by view count, which could help answer the question of most-viewed dashboards.

[Danouchka]

I have 2 customers that would like to have the following details actually in a single dashboard

• Global and per Space and/or Dashboard Monthly (Daily...etc) active user traffic (Cumulative numbers) [Dashboards]
• Global and per Space and/or Dashboard Monthly (Daily...etc) unique users (How many unique users used the platform) [Dashboards]
• Top used and not used dashboards [Dashboards]

[teresaalvarezsoler]

More user requests for this https://github.com/elastic/kibana-team/issues/869

[Danouchka]

Hi no one answered yet if it would be possible to send kibana audit logs with the (human readable) saved object title as well in addition to the saved object id ?