Размышления о DLP: тяжелый агент - зло

Аватар пользователя prozorov
Автор: Прозоров Андрей, Независимый эксперт и блоггер
(0)
()
На размышления в этой заметки меня натолкнул диалог на презентации-встрече с Gartner (про нее, а точнее лишь про часть про UBA, я написал вчера).

Во время презентации Антон Чувакин напомнил про "классические" 3 направления контроля DLP: DAR (данные в покое/хранении), DIM (данные в движении) и DIU (данные в использовании). Правда еще упомянул, что сейчас появился "DLP в CASB", и это уже 4й тип, но пока не будем об этом. Тут все стандартное, ничего неожиданного.
Ну, а чуть позже мы обсудили, что внедрять DLP лучше всего с сетевого модуля, "это самый безопасный способ". А вот к внедрению хостовой (endpoint) части DLP, стоит относиться очень очень настороженно. Антон даже рассказала про одного из заказчиков, который как-то сказал, что "он согласен чтобы его дата-центр был уничтожен цунами, чем будет внедрять хостовое DLP". Хм, забавно.
В чем же проблема? Задумался и обсудили с коллегами:

Проблема 1. Конфликт ПО
Чем сложнее агент (DLP), и чем больше стороннего ПО на хосте, то тем больше вероятность их конфликтов (прям аж до "синих экранов" бывает). Уж слишком часто все обновляются, а совместимость проверяется лишь в редких случаях и не для всех версий. Среда работы агента уж слишком непредсказуема и не стабильна...

Из моей практики работы с различными DLP, такие проблемы чаще всего бывают с агентами средств АВЗ, средствами контроля рабочего времени, средствами защиты от НСД (дада, сертифицированными в том числе), специализированным банковским ПО (с функциями ЭП) и даже иногда с редкими драйверами. Причем такие проблемы характерны даже и для технологических лидеров MQ DLP. По словам Антона: "Конфликты есть у всех" и "Технологию не смогли довести до состояния безопасной установки на endpoint"... Вот так вот.

Проблема 2. Нужны вычислительные ресурсы для контентного анализа и блокировки
Если агентское DLP выполняет стандартную для него функцию, а именно, производит анализ по контенту (именно по контенту, а не только контексту) на самом агенте, и при этом еще и блокирует передаваемую информацию, то требования к "железу" хоста существенно возрастают. Не все готовы ради контроля USB и локальных принтеров обновлять парк рабочих станций. Проще же программно/аппаратно запретить, и давать к ним доступ по запросу (большинству сотрудников для рабочих целей они не нужны).

Проблема 3. А всегда ли можно установить DLP на хост?
Лишь редкие DLP вендоры готовы предоставлять агенты для "невиндовс" ОС (и для старых сборок, например, XP). А кто-то даже уже использует "тонкие клиенты" (свежую аналитику не нашел, но в 2013 году их доля составляла 32% от всего парка рабочих мест), обычно на которые агента и не ставят. Для таких случаев нет ничего лучше правильных процессов и контроля модулем сетевого (network) DLP.

Проблема 4. Пользователи с расширенными правами могут обнаружить (и отключить) агент
Не каждый агент DLP защищен от обнаружения для пользователей с расширенными правами (да, таких од сих пор очень много), например, недавно на Хабре была статья на эту тему. И если пользователи могут его отключить, то его использование создает обманчивое чувство безопасности и контроля. А оно нам надо?


Нет, я не призываю отказываться от хостового DLP, часть задач контроля без него не решить (например, контроль буфера обмена). Но, пожалуй, к выбору endpoint-решения и его внедрению стоит подходить аккуратнее...


P.S. Ради полноты картины, стоит упомянуть, что с агентами все же не все так плохо. Антон рассказывал про проект на 300 000 хостов, на котором реализовали контентную блокировку. Правда внедрение шло 6 лет, блокировку включили на 3й, весь проект стоил 12 млн.долларов, а проектная команда состояла из 35 человек... Но это уже другая история, про DLP-консалтинг...
Оцените материал:
Total votes: 10
 
Комментарии в Facebook
 

Вы сообщаете об ошибке в следующем тексте:
Нажмите кнопку «Сообщить об ошибке», чтобы отправить сообщение. Вы также можете добавить комментарий.