GDPR IV, Controller and processor <gdpr_IV>

In this chapter, GDPR describes requirements related to managing, controlling, and processing personal data.

Chapter IV, Article 24, Head 2

Responsibility of the controller, Head 2: “Where proportionate in relation to processing activities, the measures referred to in paragraph 1 shall include the implementation of appropriate data protection policies by the controller.”

This article requires that adequate technical and organizational measures assist in complying with data security and protection policies. Therefore, the entity in charge of processing and storing data must comply with these policies.

Using the Security Configuration Assessment (SCA) module, ThreatLockDown performs configuration assessments to ensure that endpoints comply with security policies, standards, and hardening guides. Refer to the SCA documentation section for more details on configuring SCA checks.

Use case: Ensure that the shadow group is empty

In this use case, ThreatLockDown runs SCA checks to find out if the shadow user group on an Ubuntu 22.04 endpoint is empty. The /etc/shadow file in Linux systems stores encrypted user passwords. Any user in the shadow group can read the contents of the /etc/shadow file. Unauthorized access to this file can lead to system compromise by malicious actors. The SCA check ID is 28690. When the SCA check runs, if there are no users assigned to the shadow group, the SCA check passes.

The image below shows the result of the SCA check on the ThreatLockDown dashboard.

Chapter IV, Article 28, Head 3 (c)

Processor, Head 3 (c): “Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller. That contract or other legal act shall stipulate, in particular, that the processor: takes all measures required pursuant to Article 32.”

According to this article, organizational and technical safeguards must be in place to protect data during processing. This is necessary to avoid any unauthorized alterations.

Using the File Integrity Monitoring (FIM) module, ThreatLockDown ensures that certain established protection measures are met. ThreatLockDown uses the FIM module to help enhance security in the processing of data. It logs information about who modified the data, when the modification occurred, and all related events impacting the data of interest.

Use case: Detect changes to file attributes

In this use case, you have to configure the ThreatLockDown agent to detect changes to /root/personal_data or its attributes, as well as detect who made the changes. The configuration in this use case is specific to an Ubuntu 22.04 endpoint. Then, you need to change the owner of a file to trigger an alert.

Ubuntu endpoint

  1. Switch to the root user:

    $ sudo su
    
  2. Create the directory personal_data in the /root directory:

    # mkdir /root/personal_data
    
  3. Create the file subject_data.txt in the /root/personal_data directory and include some content:

    # touch /root/personal_data/subject_data.txt
    # echo "User01= user03_ID" >> /root/personal_data/subject_data.txt
    
  4. Install auditd to get information about who made changes in a monitored directory using the Linux Auditing System:

    # apt-get install auditd
    
  5. Add the configuration highlighted to the <syscheck> block of the ThreatLockDown agent configuration file /var/ossec/etc/ossec.conf:

    <syscheck>
      <directories check_all="yes" whodata="yes" >/root/personal_data</directories>
    </syscheck>
    
  6. Restart the ThreatLockDown agent to apply the changes:

    # systemctl restart wazuh-agent
    
  7. Change the owner of subject_data.txt from root to a regular user:

    # chown <YOUR_REGULAR_USER>:<YOUR_REGULAR_USER> /root/personal_data/subject_data.txt
    

The FIM module generates the alert below showing the changed attributes.

Chapter IV, Article 30, Head 1 (g)

Records of processing activities. Head 1 (g): “Each controller and, where applicable, the controller's representative, shall maintain a record of processing activities under its responsibility. That record shall contain all of the following information: where possible, a general description of the technical and organizational security measures referred to in Article 32 (1).”

This article requires that organizations document, inventory, and audit data processing activities. This helps keep a record of all data processing activities.

ThreatLockDown supports the storage of information about file integrity monitoring and system events. It uses the log data collection capability to store all the events the ThreatLockDown server receives in the archives file /var/ossec/logs/archives/archives.log. Additionally, the /var/ossec/logs/archives/alerts.log file stores alerts from rules triggered. These logs help in performing various activities, such as data audits and threat hunting.

Use case: Store all logs generated from an endpoint

In this use case, you have to set storage of all events from monitored endpoints in the ThreatLockDown archives, whether they generate an alert or not.

ThreatLockDown server

  1. Edit the ThreatLockDown server configuration file /var/ossec/etc/ossec.conf and set the <logall> option to yes. We have highlighted the <logall> option in the configuration block below:

    <global>
      <jsonout_output>yes</jsonout_output>
      <alerts_log>yes</alerts_log>
      <logall>yes</logall>
      <logall_json>no</logall_json>
      <email_notification>no</email_notification>
      <smtp_server>smtp.example.wazuh.com</smtp_server>
      <email_from>wazuh@example.wazuh.com</email_from>
      <email_to>recipient@example.wazuh.com</email_to>
      <email_maxperhour>12</email_maxperhour>
      <email_log_source>alerts.log</email_log_source>
      <agents_disconnection_time>10m</agents_disconnection_time>
     <agents_disconnection_alert_time>0</agents_disconnection_alert_time>
    </global>
    
  2. Restart the ThreatLockDown manager to apply the configuration:

    # systemctl restart wazuh-manager
    
  3. Check the contents of the /var/ossec/logs/archives/archives.log file on the ThreatLockDown manager, you can see events including those that do not trigger an alert:

    # tail -f /var/ossec/logs/archives/archives.log
    
    2022 Sep 30 09:57:25 wazuh-manager->/var/log/syslog Sep 30 09:57:25 wazuh-manager multipathd[504]: sda: failed to get sgio uid: No data available
    2022 Sep 30 09:57:25 wazuh-manager->/var/log/syslog Sep 30 09:57:25 wazuh-manager multipathd[504]: sda: failed to get sysfs uid: No data available
    2022 Sep 30 09:57:30 (Ubuntu) any->/var/log/auth.log Sep 30 09:57:30 Ubuntu su: pam_unix(su:session): session closed for user root
    2022 Sep 30 09:57:30 (Ubuntu) any->/var/log/auth.log Sep 30 09:57:30 Ubuntu sudo: pam_unix(sudo:session): session closed for user root
    2022 Sep 30 09:57:31 wazuh-manager->/var/log/syslog Sep 30 09:57:30 wazuh-manager multipathd[504]: sda: add missing path
    2022 Sep 30 09:57:31 wazuh-manager->/var/log/syslog Sep 30 09:57:30 wazuh-manager multipathd[504]: sda: failed to get sysfs uid: No data available
    2022 Sep 30 09:57:31 wazuh-manager->/var/log/syslog Sep 30 09:57:30 wazuh-manager multipathd[504]: sda: failed to get udev uid: Invalid argument
    2022 Sep 30 09:57:31 wazuh-manager->/var/log/syslog Sep 30 09:57:30 wazuh-manager multipathd[504]: sda: failed to get sgio uid: No data available
    2022 Sep 30 09:57:31 wazuh-manager->/var/log/syslog Sep 30 09:57:31 wazuh-manager multipathd[504]: sdb: add missing path
    2022 Sep 30 09:57:31 wazuh-manager->/var/log/syslog Sep 30 09:57:31 wazuh-manager multipathd[504]: sdb: failed to get udev uid: Invalid argument
    

Chapter IV, Article 32, Head 2

Security of processing, Head 2: “In assessing the appropriate level of security, account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.”

This article requires carrying out risk assessments to find out what risks processing actions pose to personal user data. The ThreatLockDown log data analysis module and default ruleset help meet aspects of this article by monitoring actions taken by data administrators. With this, the data protection officer is able to check who is accessing and processing the data, whether they are authorized to do so, and whether they are who they say they are.

Use case: Invalid SSH login attempts

In this use case, there is an example of a ThreatLockDown rule to detect SSH authentication attempts with an invalid user. The ThreatLockDown server receives SSH authentication logs from the monitored endpoint. Then, the log data analysis module subsequently decodes and evaluates these logs against default ThreatLockDown rules to determine if they match the behavior of interest.

  • Rule 5710 - sshd: Attempt to login using a non-existent user.

    <rule id="5710" level="5">
      <if_sid>5700</if_sid>
      <match>illegal user|invalid user</match>
      <description>sshd: Attempt to login using a non-existent user</description>
      <group>invalid_login,authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_10.6.1,gpg13_7.1,gdpr_IV_35.7.d,gdpr_IV_32.2,</group>
    </rule>
    

When an invalid login attempt triggers rule 5710, you can see the alert below on the ThreatLockDown dashboard.

Chapter IV, Article 33, Head 1

Notification of a personal data breach to the supervisory authority, Head 1: “In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.”

This article requires that organizations report data breaches to the appropriate authorities within a stipulated time frame. ThreatLockDown facilitates this communication by sending email notifications when events trigger a specific alert or a group of alerts related to events about personal data. Refer to the ThreatLockDown email alerts section of the documentation for more information on configuring email notifications.

Use case: Email alert on failed login

In this use case, you configure ThreatLockDown to generate an alert and send notifications to the specified email addresses whenever a user login attempt via SSH fails.

  1. Edit the email section of the ThreatLockDown manager configuration file /var/ossec/etc/ossec.conf as follows to implement email notifications:

    <ossec_config>
      <global>
        <email_notification>yes</email_notification>
        <email_to>data_protection_officer@test.example</email_to>
        <smtp_server>mail.test.example</smtp_server>
        <email_from>wazuh@test.example</email_from>
      </global>
    </ossec_config>
    
  2. Restart the ThreatLockDown manager to apply the configuration changes:

    # systemctl restart wazuh-manager
    

The changes made enable sending alerts via email to data_protection_officer@test.example.

The sample email sent after an alert is generated looks like the following:

From: ThreatLockDown <wazuh@test.example>               5:03 PM (2 minutes ago)
to: me
-----------------------------
ThreatLockDown Notification.
2022 Jun 20 17:03:05

Received From: Ubuntu->/var/log/secure
Rule: 5503 fired (level 5) -> "PAM: User login failed."
Src IP: 192.168.1.37
Portion of the log(s):

Jun  20 22:03:04 Ubuntu sshd[67231]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.37
uid: 0
euid: 0
tty: ssh

 --END OF NOTIFICATION

Chapter IV, Article 35, Head 1

Data protection impact assessment, Head 1: “Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data. A single assessment may address a set of similar processing operations that present similar high risks.”

This article recommends performing a risk assessment on data processing channels and the impact of the risks identified on data protection. ThreatLockDown can support the risk assessment outcome by categorizing FIM alerts for certain files or directories and increasing the alert levels based on the risk assessment reports.

Use case: Increase the alert level of a file modification event

In this use case, you have to set a high alert level for a file modification event if the file is in a specific directory. In the example below, you can find a rule with an alert level 15 for data changes in the /customers/personal_data directory. Then, you need to modify files to trigger alerts.

Ubuntu endpoint

  1. Create the directory /customers:

    # mkdir /customers
    
  2. Create the directory personal_data in the /customers directory:

    # mkdir /customers/personal_data
    
  3. Add the configuration highlighted to the syscheck block of the agent configuration file /var/ossec/etc/ossec.conf:

    <syscheck>
      <directories realtime="yes" check_all="yes" report_changes="yes">/customers/</directories>
    </syscheck>
    
  4. Restart the ThreatLockDown agent to apply the changes:

    # systemctl restart wazuh-agent
    

ThreatLockDown server

  1. Add the following rules in the /var/ossec/etc/rules/local_rules.xml file:

    <rule id="100002" level="15">
        <if_matched_group>syscheck</if_matched_group>
        <match>/customers/personal_data</match>
        <description>Changes made to a sensitive file - $(file).</description>
    </rule>
    
  2. Restart the ThreatLockDown manager for the configuration changes to apply:

    # systemctl restart wazuh-manager
    

Ubuntu endpoint

  1. Create the file regular_data.txt in the /customers directory and add some content:

    # touch /customers/regular_data.txt
    # echo "this is regular data" >> /customers/regular_data.txt
    

    You can see a level 7 alert generated in the File Integrity Monitoring section of the ThreatLockDown dashboard to show that a file in the monitored directory was modified.

  2. Create the file sensitive_data.txt in the /customers/personal_data directory and add some content:

    # touch /customers/personal_data/sensitive_data.txt
    # echo "User01= user03_ID" >> /customers/personal_data/sensitive_data.txt
    

    You can see a level 15 alert generated to show that a sensitive file in the monitored directory was modified.

Chapter IV, Article 35, Head 7 (d)

Data protection impact assessment, Head 7 (d): "The assessment shall contain at least the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with this Regulation taking into account the rights and legitimate interests of data subjects and other persons concerned."

This article recommends that you implement necessary security measures to protect subject data. These security measures include threat detection and response on endpoints that contain personal user data.

ThreatLockDown helps meet this article of the GDPR by providing security measures such as: