The regulations of the GDPR in many cases require that some user data is not always present, and / and or that they are anonymized. So I would like to show you now how NetEye 4 responds to this new requirement.
NetEye 4 is composed of various modules. In the NetEye 4 Log Manager, we have Elastic Stack 6.5 with Search Guard.
Search Guard is an Open Source security plugin for Elasticsearch and the entire Elastic Stack. Search Guard offers encryption, authentication, authorization, audit logging, multitenancy along with compliance features for regulations like GDPR, HIPAA, PCI DSS and SOX.
In NetEye 4, we have the best solution that Search Guard offers: the Compliance Edition. At the link here you can see the feature comparison between the various versions:https://search-guard.com/product/
I decided to try the feature fields anonymized, role, role mapping, and index security.
In order to get an example of an anonymized field in NetEye 4, I stored one simple log that I downloaded from the Elastic Stack samples, and loaded it into the Elastic Stack using Logstash. It’s also possible to define a new server in Icinga Director with one of the Safed profiles as shown in the following screenshot:
Then in the Log Manager section you can configure the server you just created in order to permit it to send via rsyslog the log stored locally on NetEye, sign it, and send it to Elasticsearch using Logstash. For this it’s necessary to click on Deploy Server Configuration as shown in the following screenshot:We now have data in Elasticsearch which I can find with the Kibana module by clicking on the Log Analytics menu entry. I found this situation after loading the data:
Now it’s time to anonymize for example one field for a group of users. I selected the IP information and created a new role in Search Guard. I selected a Search Guard session and created sg_index_logstashin order to see just the Logstash index with an anonymized IP field as shown here:
Next I created a background role called read_logstashand then created a new role in Icinga 2 called rolebwith a corresponding unique member called userb.
So I ran a test. I selected a Logstash index as the root user and saw the IP field:
Instead, userbcould only see the anonymized version of the IP address.
Finally, to test that userbcould not open the other index, I tried to open yet another index and correctly saw this error message: