An overview of the MyDLP open data control system

    A little lyrical introduction.

    In my humble experience. People involved in IT data security are divided (among other things) into two large groups. With good funding of their activities and not very. I mean, first of all, technical equipment and specialized software.
    In the context of controlling the discharge of data from internal intruders - insiders, the situation is approximately as follows. There are specialized data control systems, Data Leak Prevention systems. The business wants to protect the data, but when it sees a price tag of several million to provide such protection, enthusiasm abruptly fades.
    It goes out even more when it turns out that the system cannot provide 100% reliable data control. A smart user will be able to trick the system. The business asks: “For what are we dense, then? Come on, my friend, spin as you like, but so that the sheep are safe and the wolves are full. ”
    As a result, an IT security guard with power roots issues a bunch of prohibitive papers, heartily threatens the people with his fist, just say try to merge. And the techie’s security guard, yesterday’s admin, begins to invent a bicycle with square wheels in order to somehow control the information. (A combination of both approaches is generally good :)
    We will talk about one system that can be built into a bicycle.

    Among the open data control solutions, I came across only two.
    These are OpenDLP and MyDLP.
    Of these, MyDLP seemed more mature and functionally advanced.

    MyDLP, an open source data leak prevention software. There are 2 usage licenses. Free Community and paid Enterprise. The fundamental difference between them is the Archiving of transmitted data.
    If there is a trigger on the protected file, then Community will only post Alert on the event. Enterprise will also save a copy of the file.

    So, go to the site www.mydlp.com and take 2 files.
    The server side is an ISO image.
    The agent part is an msi file.

    Installation of the server side.
    The server is built on a friendly Ubunt. Insert the disk, Next-Next-Reboot. The server side is ready. This is really so :)
    Assign the server an ip address and release it on the Internet (this is necessary for updates and license verification).
    In case of difficulties with installation, the instructions are also on the site.
    www.mydlp.com/documents

    Next, open any browser and go to our server.
    We see a nice window.

    Now we need to follow the link to secure.mydlp.com and get a Community license.
    Everything is obvious there too.
    After registration (the server crawls on the Internet to check the license!), Enter the default Login and Password.
    login: mydlp pass: mydlp



    And we are in the server side.
    To control Mail and Web traffic, you need to additionally configure the server as a gateway to your proxy and smtp servers. I have not tested this function, but it is also described in detail in the documentation.

    Agent Installation.
    We take the installer of the agent 88 MB in size mydlp_0_9_104.msi and install it.
    The large size of the installer is explained by the fact that it includes the Erlang, Java, cygwin environments and the program components themselves, the total size of the agent directory after installation will be about 200 mb.
    During installation, the installer will ask only 1 question, what is the address of the server. After that, the installation process actually ends.

    The installer can also be distributed through group policies, the server address in this case is blocked with the help of a batch file along the way

    [HKEY_LOCAL_MACHINE \ SOFTWARE \ MyDLP]
    "ManagementServer" = "MYDLP_SERVER".

    Overview of the server side of the system.
    We return to the server.
    There are 7 bookmarks in the system: Dashboard, Policy, Objects, Options, Logs, Endpoints, Revision.
    Of these, the first and last are not of particular interest. Frequently used tasks panel and system version.

    The rest are more interesting ...
    + Policy


    Here we form data control rules.
    On the left are data sources and key control objects. The rules themselves are on the right. Now there are three of them.

    + Objects
    Here you can see ready-made predefined data types (Word, Excel documents, etc.), create your own.


    + Options
    Various settings for the interval of polling agents, determining users to access the server side. Here the only thing I will focus on is the need to check the Print Monitor checkbox to enable printer control globally.
    You can not touch the rest.


    + Logs
    Actually, then what was the purpose of all this. Log for monitoring protected data.

    You can filter by date, user, rules, ip, etc.

    + Endpoints
    List of agents online and offline.


    Agent part overview.
    A rather large agent is installed rigidly in the Program Files directory MyDLP. The path cannot be changed. Inside the directory, you can see the java, erlang, and cygwin components. 3 services and 1 driver are also installed.
    It looks like a typical open source approach is being tracked, 1 component - 1 task. :)
    At the first start, the agent scans installed printers and creates their virtual duplicates. Not at all embarrassed, calling them according to the following principle - (MyDlp) the name of your_printer. Naively puts one of the takes by default printer.

    All components consume about 50 megabytes of RAM in total; they have not been noticed in a malicious processor devour.
    To control printers under XP, you also need to perform a tricky batch file (lies on the site).
    Under the seven, and so it works.

    Setting up the server side.
    So, in the Policy section, clicking on the Add Rule button, we can choose from 5 types of controlled channels.


    Web and Mail will work if, as I wrote above, the server will be the gateway to these channels.
    Endpoint Rule is the control of removable devices and the movement of protected data on them (data is obtained from the agent part).
    Printer Rule –print control (data is received from the agent part).
    Discovery, the movement of protected data within the local network.

    Having selected a control channel, you need to name the new rule with a unique name and it will appear in the general list.
    In the screenshot above, I have 2 rules for controlling removable media and one printer rule.
    In each rule, you need to define the Source of control and the type of Data to control (files and contents).
    Our sources and data types are described on the left side, just drag and drop them with our mouse on our rules.
    In all 3 rules, I have one source - the entire network. This means collecting events from all agents regardless of their ip address.



    The data type describes the data to monitor. You can filter both by type and insert regular expressions to search by content.



    And the last, available action, when the rule is triggered: Pass - skip, Block - block, Log - write to the log. Archive function - creating a shadow copy is not available.

    In my case, the last 2 rules log all events indiscriminately, printing and copying any file to a USB flash drive. These are the Printer and Remote_drive rules.
    The first rule throws an alert only if there is a keyword (words) in the file copied to the USB flash drive. This is the Secret_keywords rule.
    For all agents to pick up the rules, click on the large Install Policy button in the upper right corner.


    System testing.
    The emphasis was on the part that interests me, namely the control of printers and removable media.

    What can I say.
    Printer control looks just nothing. The bypass is elementary. It is enough for the user to select the original printer, not the take, and the agent will not see anything. Moreover, the agent does not see the new printers installed after its launch.


    And so it works, we send a document to the virtual printer - we see a log entry.

    For removable media, the situation is better.
    We stuff the keywords in the Secret_keywords rule, you can use regular expressions. Files in which these words are found begin to pour in the log. Everything else is poured into the log marked with the Remote_drive rule.
    Russian words are parsed normally, numbers and Latin and even more so.


    Accordingly, you can make groups of rules by type.
    Banking data, Accounting, Resume, Scientific, etc., each has its own keywords. Then you can see what kind of topics files go on USB flash drives.

    Summary
    Of course, the system is still damp, small kosyachki fall out. However, on emerging issues, you can contact the community, or even dig yourself into the source code and the server side. I think after finalizing with a file, the system is quite usable.

    ps. Taking this opportunity, I want to ask Habrausers to share their practical experience in using and implementing commercial DLP solutions. On the website of the vendors, as usual, one advertisement. Nobody will tell about jambs and difficulties.

    Also popular now: