Data loss prevention (DLP) systems have become a popular tool in the arsenal of corporate information security departments. But their choice of DLP system is often approached about as thoughtfully as some buyers approach the choice of detergent — whose brand is stronger, whose advertising is more persistent, whose price is more attractive.
Nevertheless, under the hood of DLP systems, you can find a lot of factors that are not mentioned in advertising brochures. In this regard, let us dive deeper into some of those factors before you start choosing a system to protect your data.
There are many solutions of different maturity levels on the market now. The presence of one more checkbox in a comparison table does not guarantee that in reality this function works the way the customer needs. Some vendors try to release the product as quickly as possible, while its quality, convenience, and reliability may leave much to be desired.
Below are several practical questions, which will help you understand how well a DLP system fits your current and future needs, and whether or not, having spent significant funds, you end up with a product that is far from generally accepted corporate software standards.
Questions to Ask When Choosing a DLP System
- Does it perform content blocking?
- Where is the content analysis performed?
- How does it behave when there is no connection to the corporate network?
- How convenient is it?
- What is the minimum number of servers required?
- What are the implementation options?
- Does it integrate with other corporate systems?
- Can it work on different endpoint platforms?
Does It Perform Content Blocking?
By definition, a DLP system must prevent data leaks caused by employees or malicious software. This can only be done by blocking a suspicious operation.
Nevertheless, many organizations prefer to use DLP systems in a monitoring mode without actively interfering with information flows because of the risks of false positives or DLP system failures. If due to the DLP system the functioning of email or some other vital service is disrupted, the damage to the reputation of information security and IT departments can be remarkably high.
But this argument only applies to immature DLP systems, which are hard to configure to run smoothly. A potential data breach caused by the lack of a blocking regime can be awfully expensive for a business. In addition, more and more regulations (for example, Europe’s General Data Protection Regulation, or GDPR) explicitly require building protection against data leaks by using a blocking mode and impose serious fines for violators that don’t.
Some communication channels monitored by DLP systems do not allow blocking due to technical reasons. For example, for WhatsApp and Telegram messengers, because of their encryption, only passive monitoring is possible, otherwise, they will not work. However, any DLP system can hardly be considered mature enough if it does not support blocking the following channels based on the content of files: email, external USB drives, printers, and web services (HTTP and HTTPS protocols).
So, the best DLP solutions should be able to block communications channels in case of suspicious content and clients should be able to fine-tune all settings associated with content blocking.
Where Is the Content Analysis Performed?
Not all DLP systems on the market today were initially created as complete systems with a well-designed architecture. Many vendors started with one main module. Later, around this module, all the rest of the environment was added to control the remaining channels. With such an approach, it was necessary to consider all the limitations and features that the first module had. Naturally, the result can rarely be called effective architecture.
Therefore, based on where the content analysis is performed, it is often possible to determine where the history of a particular DLP system began. For example, if an endpoint agent (software installed on the user’s computer) transmits information for analysis to a DLP server using a simple mail transfer protocol (SMTP), then we can assume that the product started with an email control module. In this case, the server may or may not return the analysis result to the DLP agent. In the latter case, there is no possibility of blocking by content when writing to a USB disk or printing.
It is clear that this architecture requires a constant connection to the server and the network load can be a weak point. Sometimes whether a DLP system supports the prioritization of network traffic becomes a concern.
But with proper design, content analysis should be performed at the place where the policies are applied (the endpoint agent). This approach eliminates the need to transfer large amounts of information over the network, and the issue of prioritizing network traffic becomes irrelevant.
How Does It Behave When There Is No Connection to the Corporate Network?
The DLP agent, in addition to performing content analysis, must also transmit information about events and send shadow copies and other data to the server. If the main archive is not accessible, all this important data should not be lost.
As a rule, data gets saved on a local disk and transferred to the server when the connection is established. Ideally, policies should be applied depending on the situation — whether there is a direct connection to the local network, whether the computer is connected via a VPN or whether there is no connection at all.
Good DLP systems should allow you to set the appropriate rules for each situation.
How Convenient Is It?
Ease and convenience of system usage and management are highly subjective factors. Some people are more accustomed to managing a DLP system using a command line, and others are more comfortable creating policies and rules with the help of scripting languages. Nevertheless, a well-thought-out and convenient interface can be an indirect sign that the developer can provide a high-quality product. And so, you can expect that important components of the system are also high-quality and efficient.
In terms of convenience and sophistication of the interface, it is important to note the following aspects. First, you should have a unified management console. Nowadays, web consoles are preferred. They are cross-platform, do not require additional software installation, and can work on mobile devices. If there are several consoles (for instance, separate consoles for managing individual modules), this indicates that the product was not designed and developed as a single, logically complete system. Perhaps the modules were added by different teams and attached (each with their own consoles) to each other in the course of the accelerated development circle, or maybe they were assembled and licensed from different manufacturers.
Second, a mature DLP system should have omnichannel policies. This means that if you want to create a policy to control, say, legal contracts, then you just need to do it once and simply indicate which channels it should be applied to, like email, web, and USB devices. A less perfect system will require creating several similar policies for each channel separately. This may seem like a small problem — until the number of policies keeps rising. When it exceeds 100, and the rules use complex conditions — where there are not only content rules, but also user groups, days of the week, and so on — keeping such a set well synchronized can turn into a serious problem.
What Is the Minimum Number of Servers Required?
Another clear sign of poor architecture, which can already be spotted during a pilot project, can be the number of servers required for the system to work. If more than one server is needed for a pilot project for 50 to 100 employees, this means that the system architecture is not optimal and, most likely, will require additional resources during the production phase.
A quality enterprise-level system scales equally well in all directions. Of course, for huge scaling, you will need to have the ability to separate individual components of the system and have several servers and cluster them. But for small projects, the DLP system should not require unreasonably large resources.
What Are the Implementation Options?
A good DLP system should support many implementation options. This, firstly, simplifies the task of combining a DLP system with the existing IT infrastructure, and, secondly, it allows you to flexibly balance the functional and computational load while controlling various channels.
Today, there are several systems on the market that provide for the control of all channels at the endpoint agent level only. This greatly simplifies the vendor’s work, as they can save on the development team and shorten the development time.
However, this architecture cannot be considered very good. It is more natural to control most network lines at the gateway level, especially for large-scale deployments. A mature DLP system, in addition to the endpoint agent, offers the following implementation options:
- Integration with mail servers. In this case, you can conveniently control your internal mail as well.
- The ability to receive mail from a technical mailbox.
- Integration with the existing Internet gateway via ICAP protocol.
- An additional mail server.
The best vendors also offer their own proxy servers that provide integration with a DLP system to control HTTP and HTTPS traffic.
Does It Integrate With Other Corporate Systems?
When implementing a DLP system, it is better if integration with the following software classes is supported:
- Security information and event management (SIEM). Most SIEM systems can independently download information from the DLP database, but it is much more convenient if your new DLP system can support Cisco express forwarding (CEF), Syslog, and other similar protocols. In this case, when configuring a DLP system, you can more flexibly control what information and in what form will enter the SIEM database.
- Enterprise digital rights management (EDRM). Basically, DLP and rights management systems complement each other and provide more reliable protection if properly deployed and configured. In this case, the DLP system understands EDRM policies and they can be used in DLP policies when searching the archive, building reports, and so on. Besides, the DLP system can itself apply EDRM policies based on certain rules, such as when a specific type of content is detected.
- Data classification systems. The most advanced DLP systems should be able to work with the labels and markings in documents added by data classification systems such as Boldon James and Titus. In this case, you can benefit from the effort already spent on data classification work.
Can It Work on Different Endpoint Platforms?
Finally, the ability to work with different endpoint platforms is also a hallmark of a solid DLP system. The simplest solutions offer a Windows-only agent module — but that might not be enough. For example, look at the growing popularity of Mac devices. So, look for DLP solutions where the agent works well with all popular operating systems: Windows, Linux, and Mac.
