GDPR IV, Controller and processor <gdpr_IV>

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.

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.

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.

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:

• Malware detection.

• Integrating with VirusTotal to detect and remove malware.

• Integrating with YARA to detect malware.

• Using constant database (CDB) lists to detect and remove malicious files.

• Active response.

• Vulnerability detection.