How Immutable Indices help you to stay GDPR compliant

How Immutable Indices help you to stay GDPR compliant
By Jochen Kressin
Search Guard is more than capable of monitoring and recording security and compliance related events. You can, for example, track the complete lifecycle of a document, including creation, changes, and deletion. Search Guard can ship these compliance events to multiple endpoints, like SIEM systems, Kafka, Cassandra and, of course, Elasticsearch. To ensure the integrity of this compliance audit trail, Search Guard provides you with the new Immutable Indices feature: Once data is written to an immutable index, any changes to it is automatically prevented. This makes sure that no one tampers with the event data once recorded. Stay calm on your next compliance audit!
Both the Audit Logging module and the new Read- and Write History can produce a lot of valuable security and compliance relevant events. By using both, you are on a good way to meet most compliance regulations, like GDPR, PCI, SOX or ISO.

Using a dedicated Elasticsearch logging cluster

Generating an audit trail is fine, but the logical next question is where to store these events. It's good practice to store them in an external system, like SIEMonster, Kafka, Cassandra or the like. But why introduce another system when you already have the perfect solution in place - Elasticsearch. In fact, many users set up a dedicated Elasticsearch logging cluster which stores all security and compliance events.
elasticsearch logging cluster
The generated events are very valuable, especially in case of a data breach, a compliance audit or whenever a customer exercises his or her information rights under GDPR. So you have to make sure no one can change the events after they have been recorded.
quotes icon
How do you allow a user to write data, but prevent any changes once the data has been written?
What options do you have? Of course, you can protect the event index with Search Guard's powerful role-based access control features, and maybe supplement that with Document- and Field-Level security: Set up one or more roles, and grant only read access to the event index. But you will run into a chicken-and-egg problem: In order to write audit events to Elasticsearch, you need at least one user/role with write access to the index. But this account can potentially also be used to change any existing data in that index. So how do you allow a user to write data, but prohibit any changes once the data has been written?

Introducing Immutable Indices

The Search Guard Immutable Indices feature comes to the rescue. Immutable indices, sometimes also called write-once indices allow the creation of new documents, but once created, they cannot be changed anymore. It's like burning a non-rewritable CD or DVD back in the days: You can burn them once and read them as many times you want. But once the data is recorded, changes are not possible.
quotes icon
Immutable Indices allow the creation of new documents, but once created, prevent any changes to them.
Making an index immutable is very simple. You only need to list all indices you would like to mark immutable in elasticsearch.yml and you are done:
copy
searchguard.compliance.immutable_indices: - auditlog
Don't forget to restart the node(s) for the changes to take effect!
We can now create a Search Guard role that has CRUD access to this index in sg_roles.yml, and map a user auditlog to the role in sgrolesmapping.yml:
copy
sg_roles.yml sg_auditlog: indices: 'auditlog': '*': - CRUD
sgrolesmapping.yml sg_auditlog: users: - auditlog
Now we create a new document in the immutable auditlog index:
copy
curl -u auditlog:password \ -H 'Content-Type: application/json' \ -XPUT "https://example.com:9200/auditlog/_doc/1" \ -d '{"field1": "value1", "field2":"value2"}'
As expected, the call succeeds and the document is created. Let's now try to change it:
copy
curl -u auditlog:password \ -H 'Content-Type: application/json' \ -XPOST "https://example.com:9200/auditlog/_doc/1/_update?pretty" \ -d '{"doc":{"field1": "newvalue1", "field2":"newvalue2"}}'
As per role definition you would expect that this call also succeeds. We have write permissions, right? This is where the immutable index protection kicks in an prevents the changes from being executed:
copy
{ "error": { "root_cause": [{ "type": "security_exception", "reason": "Index is immutable" }], "type": "security_exception", "reason": "Index is immutable" }, "status": 403 }
And we get the same result if we try to delete the document:
copy
curl -u auditlog:password \ -XDELETE "https://example.com:9200/auditlog/_doc/1"
This of course applies to any Elasticsearch action that would change data, including bulk requests or delete by query for example.
By making the index immutable we are now protected from any changes to the data in it. Not quite. There are other things an attacker or an inattentive employee can do:
    Deleting the index
    Restoring the index from a snapshot
    Creating an index alias and trying to change data via the alias name
    Closing and opening the index
    Reindexing
Search Guard has your back also covered in these situations. Once an index is marked immutable, none of the actions mentioned above are possible anymore. Any attempt will result in a security exception.

What about maintenance?

Merely forbidding any changes to an immutable index is not practical. Your index would grow forever, without any chance for you to do anything about it. How can you maintain the index then?
quotes icon
Index maintenance for immutable indices is only possible with an admin TLS certificate
Search Guard never had any default users or passwords, and that means there is no default root or admin user. Instead, we rely on the industry standard TLS to give a user elevated privileges to the cluster: To perform any sensitive operation, like changing roles and permissions, you need to provide an admin TLS certificate to Search Guard. Maintaining immutable indices are no exception to this rule: Search Guard protects immutable indices against changes performed by any regular role, but will allow index maintenance if you provide an admin TLS certificate.

Summary

Immutable Indices, introduced with the Compliance Edition of Search Guard, solve the chicken and egg problem when storing audit and compliance events in Elasticsearch. Once data has been written to an immutable index, it cannot be changed anymore, even if a Search Guard role has write access for this index. This ensures integrity of your data and makes sure that audit and compliance events are unchangeable once written. In addition, your index is protected from any operation that changes or copies it, like deletion, reindex or restore. Immutable indices are a perfect feature to meet compliance regulations like GDPR, SOX, PCI or ISO.

Where to next

Image: shutterstock / gotphotos
Published: 2018-04-16
share
linkedIn icon
Reddit icon
Questions? Drop us a line!
your message
newsletter
This form collects your name and email. Please take a look in our privacy policy for a better understanding on how we protect and manage your submitted data.

Other posts you may like

follow us
twitter iconfacebook iconlinkedIn iconyoutube icon
Search Guard Newsletter
For the latest product developments, new versions and cybersecurity news, sign up to our newsletter.