Data protection and data security are often mentioned in the same breath and are closely linked. In this issue, I focus on the contrasts between the two and show the pitfalls in combining the technical and legal aspects of IT security.

Data security describes the practical protection of data through technical security and monitoring measures. In this understanding, "data" means all data assigned to the domain of a person or organization. The existing data must be protected against various threats, taking into consideration the classical protection goals of integrity, availability, confidentiality, and assignability.

Data integrity means that stored data is not altered without authorization and without being noticed. One way to ensure integrity is to use versioning in combination with checksums. Availability is a data security component because access to data must be guaranteed. In practice, availability periods can define when the stored data can be used and new data can be created. Confidentiality must be guaranteed in two respects: for stored data and for data in transit from one system to another. Confidentiality for stored data is implemented in all common operating systems through filesystem access authorization. Transport Layer Security (TLS) ensures the confidential transmission of messages.

In many cases, assignability is not implemented by default. Classic operating systems store the time a file was last changed, but not the user who made the changes. Even if the Windows audit policy can be used to log changes to files, the changes to logged data are not comprehensively traceable. Collaboration tools such as Subversion or Git can help. All changes to a file are traceable there, except for low-level changes to the repository.

Data security can therefore be understood in the traditional sense. However, this does not include data backups (i.e., the creation of backups to at least restore the availability protection target after unintentional manipulation or deletion).

Protection and Security Contradictions

Great Britain, Spain, The Netherlands, and Germany have very strict data protection regulations. In contrast to data security, data protection is more about theoretical and legal aspects – in particular, the protection of personal data against misuse.

Personal data means not just personal information, but data that can lead to the direct or indirect identification of an individual (also called a "natural person"). The principle of informational self-determination is decisive: It's not just about protecting an individual's data; it's about letting them decide who owns and uses their information. However, technical data security is an important data protection instrument, in particular the confidentiality of personal data.

For example, Germany has defined high legal hurdles for the collection and storage of such data. Probably the most important aspect is voluntary consent when personal data is collected and stored. Even if a person deals very freely with information about their personality, concepts such as "data economy" and "limited purpose" further secure the data.

The principle of data economy stipulates that only such data as is necessary for the current process may be collected. Additionally, collected data must be anonymized or pseudonymized to the extent possible. Restriction of purpose ensures that the data collected is only used for the defined purpose; the purpose cannot be changed unilaterally afterward, and consent to a change cannot be forced.

The aim of anonymization or pseudonymization is to prevent correlation of stored data, which means the restrictions for use of the stored data cannot be lifted without considerable overhead (i.e., the illegal use of data beyond its defined purpose). A prominent example of the ability to correlate data is the pseudonymization of the AOL search history: The Internet giant passed on pseudonymized search data to researchers and journalists, who in turn were able to identify real persons, despite alleged protections, through skillful correlation of the information [1].

Even if it doesn't look likely at first glance, data security and data protection cannot be combined easily in some respects. Imagine an intrusion detection system (IDS) that monitors an organization's perimeter for Internet connections and scans for irregular behavior. Inevitably, even if private use of the Internet is prohibited in the company, personal employee data is collected there. Although the company has presumably agreed to use the data for the protection of its IT infrastructure, this agreement does not release it from the obligations of data economy and earmarking. Article 9 [2] of the European Union's new General Data Protection Regulation (GDPR) defines "special categories of personal data." Characteristics such as racial or ethnic origin, religion, and trade union membership are highlighted as particularly worthy of protection.

Pseudonymization

If you collect data to ensure data security and acquire the personal data of your employees, you must always record which protections you implement and why it might not be possible to pseudonymize the data. As long as the data is processed automatically and the IDS acts on this basis, it is not a problem. However, if events are written to a log that is evaluated manually, you need to take some simple precautions, in particular if the data relates to persons who have not consented to processing. If you process the sender addresses in email, you are inevitably processing personal data. Often you do not need this data; assigning it to your own employee is usually sufficient to process an incident, so exchanging all the external email addresses in your log data with a uniform placeholder is prudent.

This protection extends to you, as well, if you need to access personally identifiable information from time to time. Even as an administrator, it may not be advantageous to know your supervisor's preferences or to assign corresponding information. Data protection then also becomes self-protection, because anything you do not accidentally learn will not burden you in the future. To remain as free as possible from damage, the European Union's GDPR requires the preparation of a Data Protection Impact Assessment (DPIA). According to Article 35 of the GDPR [3], a DPIA is necessary, in particular where new technologies are used, if processing is "likely to result in a high risk to the rights and freedoms of natural persons."

A report of the responsible regulatory authority is decisive for the decision as to whether or not a DPIA is necessary. According to the GDPR, the relevant regulator is no longer the authority in whose sphere you operate, but the authority responsible for the location of the company's headquarters.

The regulatory authorities are responsible if you want to report an incident concerning your personal data. Companies are usually on the other end, and if they fail to comply with data protection regulations, they may face heavy fines. The GDPR specifies fines limited to EUR20 million or four percent of a company's worldwide annual turnover.

Even a mail circular inadvertently sent to several recipients, such as regular customers, can become a case for the data protection regulatory authority if you accidentally glean the address from the CC or TO header of the email instead of the BCC header. In principle, this can also have unpleasant consequences in your private environment, because as a private individual, you are only exempt from the requirements of data protection law if the data processing is carried out exclusively for personal or family purposes.

Conclusions

Although data security protects data, data protection is a legal construct codified in the GDPR that bestows informational self-determination. The role of the data protection officer and the IT security officer should therefore preferably not be filled by the same employee. The person responsible must observe the rules of the game (e.g., data economy and restrictions for use) and, if possible, anonymize or pseudonymize the data collected and guarantee data security.

Some companies headquartered in the United States are subject to the GDPR [4]. Depending on how and for what purpose you collect personal data, you must carry out a DPIA in accordance with the GDPR.