[Fleet] Lack of Fleet Policy Change Audit Logs

[christophercutajar]

Describe the feature:

Currently, fleet logs audit logs when a fleet policy is updated and when that policy is deployed to an agent. However, the logs lack in highlighting what the user has changed if any changes were done and who was the user.

Describe a specific use case for the feature:

My use-case is a security use-case whereby a malicious user has managed to gain fleet access and the user disables agent tamper protection

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[kpollich]

The Fleet audit logging implementation is aligned with Kibana's core audit logging implementation. Fleet doesn't include granular change sets for change operations because no other Kibana audit logs do so. We could implement this for Fleet, but it'd be better to consult @elastic/kibana-security here, I think.

I know Elasticsearch audit logs allow for a change property that contains information about the specific change set for a given request. Perhaps we could consider supporting the same field for Kibana audit logs. Doing this for just Fleet though would introduce inconsistency, so we'd probably want to take on the large effort of updating all of Kibana's audit logging to include granular change sets if this is something we want to pursue. This would have substantial ramification on log file size, as well.

[user-987654321]

This feature is sooo badly needed - its impossible to track who updated a Policy. If a team of Fleet admins is looking after the environment no auditing is captured for the admin who created, updated a policy etc

[jeramysoucy]

"However, the logs lack in highlighting what the user has changed if any changes were done and who was the user."

Fleet doesn't include granular change sets for change operations because no other Kibana audit logs do so

@kpollich @christophercutajar As far as I know this is correct. Kibana audit logs do not include a change set, however do include the session ID for the user that executed the change. I can bring this issue up with the team during our sync to see what the general feedback is.

[jeramysoucy]

@kpollich @christophercutajar I discussed this with the team. Being able to log a change set would add overhead to each CRUD operation - we'd need to retrieve the previous version of an object and perform a diff with the updated version. In addition, if concurrent writes are being executed on the same object we cannot be sure that the previous version retrieved is accurate (see optimistic concurrency). Pushing audit logging down to Elasticsearch might alleviate these issues, but Elasticsearch has zero context from which to create meaningful Kibana audit events.

We think a reasonable compromise could be to include the latest version, or subset thereof, of an object when an operation is audited. By tracing the audit logs, one would be able to generate the change set for each operation if needed. Due to the potentially large size of some saved objects, we thought of 3 ways to preventing runaway log file entry sizes:

• A per-object size cap: SO's that exceed this limit would be truncated. This would be a global setting in the audit logging system.
• SO type opt-in: the audit logger would only record the value of SO types that opt in. This would be settable during SO type registration.
• SO type field opt-in: the audit logger would only record a subset of SO fields for a type. This would be settable during SO type registration.

I have opened an issue for our team to draft an RFC for this concept: #181946