Add tamper resistance or tamper evidence to security audit logs

[jburr9]

Submitting on behalf of my group of five University of Nebraska - Omaha Cybersecurity Masters students for our Software Assurance class project:

We reviewed Elasticsearch as part of our class project with a hypothetical "bank portal" scenario. One key feature of our scenario required was the ability to trace user activity via security audit logs. We identified that an Audit Log feature already exists in Elasticsearch. However, the log data is stored in a JSON file on each node. If an attacker or insider were able to gain access to that file either through a weakness in Elasticsearch or by another means, he/she would be able to easily alter or remove audit events (See CAPEC-81 Web Logs Tampering).

Therefore, we would like to offer the idea for a "tamper-resistant" or "tamper-evident" audit logging capability. The general idea would be to prevent changes to audit log entries made outside of Elasticsearch. If it doesn't too negatively impact performance, perhaps the audit logs file could be encrypted (to provide confidentiality) and a Message Authentication Code could be calculated on it after each change (to provide integrity). The MAC's secret key could be stored securely by the application in a manner that makes it difficult for an outsider to locate but easy for Elasticsearch to use.

If this sort of "tamper-resistance" is not feasible, Elasticsearch could provide the ability to show evidence of tampered logs. To accomplish this, a Message Authentication Code could be calculated on each log message and stored with the message (again, requiring the secret key to remain in a secure location away from the log file). Then, Elasticsearch could provide a mechanism to validate logs by re-calculating the MAC on the log contents. If an attacker made changes, the old MAC and new MAC would not match and Elasticsearch could report that log as "tampered with". A few commercial products document a similar feature (GoAnywhere, Ipswitch).

[elasticmachine]

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

[bytebilly]

Thanks @jburr9 for the proposal.
I like the overall idea of having anti-tampering features for audit logs, but this is not something trivial and at the moment it is not on our roadmap.

One of the obstacles to this implementation is that the audit trail write is a blocking operation. If it cannot be written correctly, the operation doesn't happen. It means that we should be very careful in introducing "slow" operations in the process, as they may reflect to the entire system.

The node machine where the file is located should probably be a trusted environment anyway, since it has access to cluster data. This may relax the assumption that anti-tampering should happen before the entry is written to the file, since an attacker with access to the node probably has access to all the information needed to alter the trust chain.

We normally expect audit files to be ingested to another cluster, for example via filebeat. This could be a good place to add some integrity checks.