Not all DLP systems are equally helpful


Back to blog list

SITA company’s security became compromised by fraudsters who copied personal data of Lufthansa, Air New Zealand, Japan Airlines, Singapore Airlines and about 4.5 million Air India passengers in the beginning of the year. The processing company could confirm the leak only a few months later. CNA Financial had to cover the “expenses” brought by violators’ activity and pay $40 million to retrieve the breached data after a ransomware attack. Opting to pay ransom can not only be a high-priced choice but also an illegal one. How does ransomware needle through one’s network? An employee might open a malicious file, click a suspicious link, communicate with a violator and even keep doing the same mistake. There are monitoring systems which are capable enough or less powerful to deal with the most needed task.

What should a company know to tell a strong proactive system from a solution with annoying limitations.

For many companies a DLP system is a must-have solution when it comes to data leak prevention and protection from other insider threats. But customer experience while using a DLP is not always enjoyable. This article will comment on deserved and unfair reproaches to DLP systems, will clarify which are the natural limitations of such kind of systems and which are the drawbacks of particular products.

1.    Not enough functions to solve a task

DLP systems have long outgrown their original purpose of data leak control. Now they are used for a much wider range of tasks within information, economic and human resources security. Today DLP solutions are true supertools.
Nevertheless, a customer might need more and more functions. This often becomes clear soon after the deployment stage, as a customer ignores a full-fledged trial and relies on marketing description and third-party comparison tables. Testing does take your time in the beginning, but saves it notably when the real work with the solution begins. That’s why the actual implementation requires preparedness. Compile your own comparison table, test gradually each system and see how they work regarding the tasks you’re interested in the most.
For example, one our client wanted to block file transfer by metadata, and other cases of file transfer were of no trouble for them. Before they purchased a DLP system, their company tried a few other solutions, and it appeared that those products didn’t manage to tackle this problem, although the brochures seemed to ensure this type of blocking.
The functionality limits can also be associated with the fact that DLP systems use third-party technologies. Sometimes these are the whole engines, modules, platforms or even white-labeling a third-party product as a proprietary solution. As a result, vendors are limited by the functionality of someone else’s software and its development plan. This is a common problem for many DLP systems out there.
We have decided to build our system based on our own engine, and we use it not only in our DLP but in other solutions as well. All other elements of our systems are also coded by our team. If a client needs some adjustment, error fixing or technical support we guarantee our help. Often a DLP appears to be limited in its functionality when a customer wants some specific features. If these features are crucial, and other customers might benefit from them as well, vendors tend to include these ones in their development plan. This is how we made integration with access control systems possible, and enabled joint work with BI systems, task managers, phrase search elements, etc.
Anyway, sometimes specific capabilities aren’t needed to solve the majority of client tasks, and the combination of existing software functions is quite enough.  A client doesn’t necessarily know about it, the best practices are shared by a developer. But usually, vendors don’t include such an option, and technical support is their only customer accompanying.
One more factor to consider – whether a vendor can offer anything besides a DLP. This system has become the central element of protection from any insider risks, that’s why when choosing it a customer chooses the whole ecosystem of other protection tools. If a developer doesn’t have such a product line, a company can face a problem of product integration. Often, it’s a complicated even unsolvable task, companies should think about it beforehand.

2.    DLP is difficult to deploy, it “eats” a lot of resources

This is one of the primary issues. Developers approach a DLP system functioning optimisation differently, as a result software solutions differ significantly as it comes to their “voracity”. Despite the fact that vendors describe minimum technical requirements in detail, the deployment stage can still surprise you in a bad way. And the bigger the scope of deployment the higher the possibility of such an unpleasant surprise.
There are two options. The perfect one is to launch a comprehensive trial period (deploy all the modules on a maximum number of computers). But this is not always possible. The second option is to ask the opinion of those information security specialists who use a DLP system on a number of PCs similar to yours. Be curious, let the interesting or difficult moments get shared by them.
We work on minimising requirements to hardware. Last year we altered the architecture, and this allowed for DLP speed increase up to 30% and expand the variety of solved tasks – search for data in very large networks, for example. Earlier customers had to allot enough power, locate additional servers. Now our DLP requires 2-3 times less of server resources than many competitors’ solutions.
The speed of deployment also matters, it’s not normal if it takes weeks or months. Processes can last longer if a client limits access or doesn’t have a technical specialist. Anyway, the optimal pace of deployment of a typical pilot version is a few hours. We guarantee it thanks to providing a customer with our technical specialist (engineer) and implementation specialist (who will teach a company how to work with the solution, help configure the policies and solve specific tasks).

3.    Frequent false alarm

Experienced information security specialists understand that it’s unavoidable: it’s better to check through false alarm than to overlook something important. But it doesn’t mean that all the work comes down to analysis of potential incidents. Good software minimises the quantity of false alarm thanks to flexible security policies configuring. It’s crucial to stop and find balance.
For example, one can exclude the alerts which get triggered by the word “leave” in the meaning of “quit” as “left” can also mean “kept, saved”. But we insist a company doesn’t do that because it’s possible to overlook the talk that someone is going to quit the company. 
One of the most solid features of our DLP is flexible policy adjustment. A lot of various analysis methods are implemented in the solution:  by words, by dictionaries, by phrases, by attributes, by regular expressions, by digital fingerprints, the proprietary similar content search, statistical or complex queries, or any of these combined. If the approach is correct and implementation specialists are involved security policies can be configured precisely and effectively.

4.    The solution seems overly sophisticated, there is no one to work with it

DLP system doesn’t operate as antivirus (or as plug-and-play). Preconfigured settings are enough to protect from data breach, monitor, block the transfer of data which contains elements already considered by preset policies. Of course, this will ensure data safety, but to increase it these policies should be reviewed as well as business processes, whereas investigation should be conducted. And if a customer doesn’t know what to do with this information next, the company will benefit from only 10-20% of all the capabilities the DLP system offers.
Another problem is that there is no one to work with the solution, or the turnover of information security specialists is so high, that a new person simply doesn’t have time to learn enough. If vendors don’t take this aspect into account, their system at some point runs the risk of becoming a burden on the client's balance sheet. Together with the inevitable disappointment in DLP software as a whole. We have been working with this problem for a long time. This is how a training center and a strong implementation department appeared, which, in fact, shares a large amount of work with the client. As a result, we can deploy and ensure the operation of a DLP system, regardless of what the qualifications of information security specialists are and whether a client has enough of trained staff. But we went even further and launched MSSP solution to spare our clients the analytics and reporting headaches. In this format, outsourcing can also work for those companies where there is no information security department at all, and if there is one then serve as an indispensable instrument.

DLP Risk management Internal audit