[Fleet] Lack of Fleet Policy Change Audit Logs

christophercutajar commented 4 months ago

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 commented 4 months ago

Pinging @elastic/fleet (Team:Fleet)

kpollich commented 4 months ago

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 commented 2 months ago

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 commented 2 months ago

"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 commented 2 months ago

@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: https://github.com/elastic/kibana/issues/181946

nimarezainia commented 2 weeks ago

@kpollich I think we are blocked here until the RFC is complete.

@jeramysoucy I was wondering if there are any updates on the RFC you created?

jeramysoucy commented 1 week ago

I was wondering if there are any updates on the RFC you created?

@nimarezainia This task is in our backlog, but we have not scheduled it yet. Could you give us a sense of the level of urgency of your issue? Is this directly impacting customers?

nimarezainia commented 1 week ago

I was wondering if there are any updates on the RFC you created?

@nimarezainia This task is in our backlog, but we have not scheduled it yet. Could you give us a sense of the level of urgency of your issue? Is this directly impacting customers?

Please see the comments above, it's a sub-optimal UX as it makes sense for users wanting to know what changed at a granular level.

jeramysoucy commented 1 week ago

Is this issue essentially describing the same request? https://github.com/elastic/kibana/issues/152711

kpollich commented 1 week ago

Is this issue essentially describing the same request? https://github.com/elastic/kibana/issues/152711

Yes I would say that is accurate

jeramysoucy commented 1 week ago

@kpollich Can we close that one as a duplicate of this one?

nicpenning commented 1 week ago

👀

elastic / kibana

[Fleet] Lack of Fleet Policy Change Audit Logs #177972