Top menu

The GDPR Fever: DLP by Design

This is the last post in the GDPR Fever series aimed at explaining whether and how DLP technologies could be used for achieving GDPR compliance.

When a data protection solution for addressing a particular processing risk is being architected and designed, the success of this engineering phase and the quality of its results substantially depend on how thoroughly the following factors are considered in the engineering process: the maturity and availability of infosecurity technologies suitable for implementing required safeguards, the processing system’s business purpose, its application platform, architecture, and the types of components, as well as the threat profiles specific to the system and the types of risk addressed.

Get the "DLP: A Critical Piece of the GDPR Puzzle" Whitepaper!

These considerations are fully applicable in case DLP technologies are used in a project to neutralize the risk of personal data leakage. The way how they can be integrated into the processing system’s architecture and design is influenced by various factors, the most important of which are considered below:

DLP Implementation Options

Currently, not only are standalone DLP products available on the market, but also DLP technologies are used in several types of IT and IT security solutions and services as add-on components that implement data leak prevention functions for the specific application domains these solutions target. For example, various DLP functional options have been built into endpoint protection platforms (EPP), UTM appliances, cloud access service brokers (CASB), some information rights management (IRM) and data classification solutions, email and document management services, office suites, cloud file sharing services, next generation firewalls, and cloud “software as a service” (SaaS) platforms. In addition, a few DLP vendors offer their DLP SDKs for integrating complementary DLP capabilities into customer’s products. As a result, when organizations need DLP technologies to address the risk of personal data leakage in their processing systems, they have several options of implementing DLP functions – starting from embedding a DLP SDK into their custom applications, to using built-in DLP capabilities of office suites, or application or cloud file sharing platforms they have chosen for the system, to using DLP functions embedded into UTM or CASB appliances or services, and to finally using standalone DLP products. In each particular case, when choosing an optimal DLP implementation option, the following factors should be evaluated:

  • Chosen system architecture and types of its foundational components – infrastructure and application platform (e.g. Google Cloud Platform, Microsoft Azure, etc.). For instance, in case Google Cloud has been chosen, it makes sense to consider using its built-in DLP services accessible via APIs for implementing necessary DLP-related safeguards provided the Google DLP functionality scope is sufficient.
  • Chosen architecture and types of system components implementing its business application logic. In case, for example, Microsoft Office Suite has been chosen for use in the system as its office application suite, the system developers should check if the capabilities of Office’s built-in DLP functions are sufficient for implementing all DLP functions required by system to prevent personal data leak threats.
  • Market availability of those DLP implementation types anticipated or required to be used in the processing system design – e.g. software DLP SDKs, standalone DLP products, various IT and IT security solutions with built-in DLP functions, etc.
  • Cost of integration in terms of time, resources, expenses, as well as the total cost of ownership (TCO) should be evaluated for all DLP implementation types potentially suitable for the project.
  • When choosing among alternative DLP products or services, their functional sufficiency with respect to the project’s requirements shall be initially verified followed by a functional and feature comparison of all qualified DLP products complemented by and balanced with a comparative analysis of their TCOs. When performing the pair-wise feature comparison of DLP alternatives, special attention shall be paid to the following criteria: supported DLP types (data-in-use DLP, data-in-motion DLP, data-at-rest DLP); range of controlled local and network data channels; range of leakage scenarios blocked; quality of preventive controls and remediation actions; supported content-aware mechanisms and contextual controls; solution scalability; solution integration with dominant enterprise directories, and, least but not last, its tamper resistance.
  • It may happen that none of the evaluated DLP products and solutions alone has the functional scope covering all project requirements for data leak prevention. In this case, the approach of bundling complementary DLP solutions whose aggregate functionality is sufficient for the project should be chosen – for example, bundling an endpoint DLP product and a cloud DLP service from different vendors.

The Principle of Least Privilege in the DLP Context

The principle of least privilege is the native logical paradigm of managing access privileges in all IT security solutions that protect data confidentiality. The original definition of this principle states that “every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error.”

By applying this principle in DLP solutions, security administrators can precisely match user rights to job functions with regard to transferring, receiving, and storing data on corporate computers. The resulting secure computing environment allows all legitimate users’ actions to proceed unimpeded while blocking any inadvertent or deliberate attempts to perform operations outside of preset rules.

In order to use the least privilege technique for configuring DLP policies in the most optimal way, a certain specifics of DLP preventive mechanisms should be taken into account. There are two types of them: content-aware inspection, which performs content analysis and classification of data, and contextual controls, which detect and use various parameters of the operation context in order to decide whether this operation is allowed or must be prevented. For instance, these parameters include who (a user) or what (a process) initiates the operation, when, where from, where to or to whom, and how – through which channel or device – the data are used or transferred. Both content-aware and contextual mechanisms can be used in a single DLP policy for implementing the principle of least privilege as precisely as possible.

The specifics of optimizing DLP enforcement is that the mix of both contextual controls and content inspection methods should be used only in rules for those leakage scenarios where the decision on allowing or preventing the inspected operation depends exclusively on the content of its data. At the same time, in all those scenarios where the analysis of the operation’s contextual parameters is sufficient for detecting security policy violations, only contextual controls should logically be used in the relevant DLP rules – without involving unnecessary content analysis, which can be quite CPU-intensive and take considerable time to complete. Another substantial advantage of using contextual DLP controls whenever possible is the simplicity of relevant DLP policies, their configuration and troubleshooting. Besides, contextual controls do not have the caveat of false positives, which affects the accuracy and usability of many content analysis methods.

Modern DLP systems can enforce preventive controls with a multitude of contextual parameters including users, computers and their groups, sender and recipient email addresses, user identifiers (IDs) for instant messaging, types of local ports and peripherals, device serial numbers in combination with vendor and product IDs, data transfer flow directions, network application or protocol used for the operation, network ports and addresses, whether the storage media is encrypted or the communication is SSL-protected, the date and time of the operation, etc. – there might be dozens of such parameters used in DLP policies. The use of contextual DLP controls has proven to be highly effective in corporate IT practice where typically most potential data leakage scenarios can be controlled without content analysis.

Using DLP Beyond Data Security

The set of security functions specific to DLP technologies enables them to be used not only for enforcing the GDPR’s I&C principle, but also for implementing safeguards for some other data privacy principles enacted in Article 5 of the regulation.

Specifically, the DLP’s ability to collect extensive audit and shadow logs on user actions related to data access, storage, and transfer operations can be effectively used for facilitating the “transparency” principle, which, according to Recital 39 of the GDPR, “requires that any information and communication relating to the processing of those personal data be easily accessible and easy to understand, and that clear and plain language be used.”

Another DLP function – content discovery of data stored on corporate assets – can be used to enforce the “storage limitation” principle, which requires that storage periods of personal data be limited by the time when they are lawfully processed. “Data-at-rest” DLP components can scan the content of data residing on endpoint computers, file shares, network attached storage, document repositories in the corporate network, as well as data kept in approved cloud storage. If personal data with expired storage periods are located by the scan, DLP components can protect them with automatic remediation actions, and can initiate incident management procedures with real-time alerts sent to SIEM systems and/or emailed to IT security personnel in the organization.

The Focus on Preventing Insider Data Leaks

Essentially, the GDPR is aimed at protecting personal data against two types of threats originating primarily from inside the organization that uses these data in its business process. The first type relates to information privacy violations resulting from a misuse of personal data, access to which has been authorized for lawful processing purposes. The threat of second type is data breaches resulting from unauthorized access to personal information by insiders – legitimate users of corporate IT systems.

This is why when evaluating various DLP options for implementing confidentiality safeguards against personal data leakage, system designers should give priority to DLP solutions focused on preventing insider data leaks as the most effective for achieving GDPR compliance.

An important differentiating feature of such solutions is enhanced functional capabilities of their endpoint DLP agents, which should prevent not only data leakage through local endpoint channels (“data-in-use” DLP) but also unauthorized data transmissions via network communications (“data-in-motion” DLP), as well as support content discovery in the local file system and accessible network shares (”data-at-rest” DLP).

One of the DLP solutions that fully support these capabilities is DeviceLock DLP, whose mission is to prevent data leakage from corporate endpoint computers.

There Is No Privacy Without Security
Deciphering the "Integrity & Confidentiality" Principle
From Legal to Technical – Landing the GDPR at the IT Field
DLP Is Necessary for GDPR Compliance
Engineering Information Privacy
DLP by Design