[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

[nimarezainia]

@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]

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]

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]

Is this issue essentially describing the same request? #152711

[kpollich]

Is this issue essentially describing the same request? #152711

Yes I would say that is accurate

[jeramysoucy]

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

[nicpenning]

👀

[nicpenning]

Just checking in on the status of this. Is there any audit logs happening today per user?

These are some of the questions we want to answer:

Who upgraded what agents (and when)?
Who upgraded integrations (and when)?
Who modified and integration and what was changed in the integration (and when)?
Who moved an agent to what policy (and when)?

[jeramysoucy]

@nicpenning

Just checking in on the status of this. Is there any audit logs happening today per user?

If audit logs are enabled, they will contain logs for any actions requested for saved objects and will include the user ID that issued the action.

These are some of the questions we want to answer:
Who upgraded what agents (and when)?
Who upgraded integrations (and when)?

You should be able to determine this now with existing audit logs, given that there is a specific action and specific saved object that correlates to an agent or integration upgrade. The logs are timestamped and include the action, ID of the saved object, and ID of the user.

Who modified and integration and what was changed in the integration (and when)?
Who moved an agent to what policy (and when)?

Audit logs do not include the specific granular changes made to saved object attributes. The audit logger provides a security function in Kibana - its purpose is to log access/actions to objects/data to provide authorization traceability.

A change log feature has been in discussion for some time (with the @elastic/appex-sharedux team and now also in AppEx Platform Security), and would server higher-level purposes compared to the audit logger. It requires additional context and encompasses a much broader scope. We had been looking what changes to the audit logger might make a subset of these capabilities possible, but determined that it may not be the right tool for the job. @bitzandeb has been compiling the needs for change logging, and how/where it would be utilized so that we can determine an appropriate solution. Let's make sure Fleet is involved in this discussion.

cc @legrego to keep me honest here

[nicpenning]

Okay, great to hear some of this has been implemented! Could you point me in the direction of the docs to.setup audit logging? I am unsure if this is Elasticsearch, Kibana or other parts of the stack auditing.

[kpollich]

@nicpenning - https://www.elastic.co/guide/en/kibana/current/security-settings-kb.html#audit-logging-settings + https://www.elastic.co/guide/en/kibana/current/xpack-security-audit-logging.html should cover setting up audit logging, and detail the available fields that are logged.