How is the consolidation of archives in DeviceLock DLP

Not so long ago, we released a new minor version 8.3.75005 of the DeviceLock DLP data leakage prevention software and, among other improvements, included a rather useful function for large companies to consolidate data from storage servers.

I would like to talk about consolidation a little more ...

First, a little about how the collection and storage of intercepted data in DeviceLock DLP is arranged. Being an agent-based solution to prevent information leaks, DeviceLock DLP intercepts, analyzes, and enables / disables the transfer of data directly to users' computers using agents. In addition to intercepting, analyzing and deciding whether to allow or prohibit the transfer, agents can also (if this is specified by the policy) accumulate audit and shadow copy data (a copy of the information transmitted by users).

For the centralized storage and subsequent post-analysis of the data accumulated by agents (for example, generating reports, searching the archive, etc.), the DeviceLock Enterprise Server (DLES) storage server is used. An unlimited number of such servers can be set up in an organization (we do not limit their number to a license), which makes it possible to evenly distribute the load on individual network segments and minimize the time of data collection from agents. For agents, several DLES servers can be specified and the rules for choosing a server when transferring accumulated data to the archive are specified. Each DeviceLock Enterprise Server connects to the SQL server and stores its data in a separate database. Moreover, multiple storage servers can be connected to a single SQL server.

If an organization has several branches, the scheme is most often used when each branch has its own server (or several servers) of storage, and the central office collects accumulated data according to a predetermined schedule (once a day, week, etc.).

Prior to the release of this update, data could be replicated by means of a SQL server, which was not entirely good in terms of the overall convenience of setting up the complex. The nontriviality of replication was especially evident in the situation when several storage servers were connected to the same SQL server.

Now we suggest using the consolidation function, which is much simpler to configure and use, in which the replication of data on a schedule is performed solely by the built-in tools of DeviceLock Enterprise Server.

I will show on a “live” example the basic configuration of consolidating accumulated data from four storage servers to the main server.

The diagram above shows that two servers (Test28-w10x64 and PC-55OSI) are connected to one SQL server (SQL2), while the other two servers (VSamsonov-PC and mamaev-pc) are connected to their own SQL server (SQL1 and SQL3, respectively). Data replication will be performed on the DLSRV main server connected to the SQL master.

To set up a schedule and specify a master server to which data should be replicated, on each of the “downstream” servers of Test28-w10x64, PC-55OSI, VSamsonov-PC and mamaev-pc, you need to set the consolidation parameters.

Among other things, you can additionally indicate what exactly needs to be replicated (which logs), whether to copy data or transfer it, whether to shape the network channel or give it up for consolidation.

After the successful establishment of the connection between the "downstream" and the main server, the consolidation statistics will appear in the interface of the latter.

You can see the collected data, as usual, in the standard viewer of the corresponding log. For example, for a shadow copy log, it would look like this:

The original server that collected the data from the agents is displayed in the “Server” column.

Separately, I want to note that the "nesting level" of consolidation is not limited. If it is necessary to replicate data from DLSRV somewhere else “to the top”, then simply in the consolidation settings for DLSRV it will be necessary to prescribe its “upstream server”. And so almost to infinity;)