Функциональность систем DLP (Data Leak Prevention, предотвращение утечек данных) со временем усложняется, чтобы соответствовать современным стандартам. При этом различные DLP-решения развивались исторически по-разному и в зависимости от этого обладают соответствующими сильными и слабыми сторонами. Рассмотрим один из подходов к выбору DLP-системы, связанный не с перечислением необходимой функциональности, а со способностью этих систем решать реальные производственные задачи по предотвращению утечек приватных данных.
- Введение
- Для каких каналов возможна блокировка по контенту
- Где выполняются контентный анализ и применение политик
- Как работает агент системы, когда нет соединения с корпоративной сетью
- Удобно ли управлять системой
- Какое минимальное количество серверов нужно для внедрения
- Легко ли развернуть систему, набор вариантов внедрения
- Поддерживает ли облачную инфраструктуру
- Интеграция с другими корпоративными системами
- Мультиплатформенность
- Выводы
Введение
Сегодня DLP-системы стали настолько обыденным инструментом в арсенале корпоративных служб информационной безопасности, что к их выбору подходят примерно так же вдумчиво, как домохозяйки подходят к выбору стирального порошка. Чей бренд симпатичнее, чья реклама более настойчива, чья цена привлекательнее… Тем не менее «под капотом» DLP-систем можно обнаружить много такого, о чём не пишут в рекламных буклетах, а цена ошибки здесь намного выше, чем при покупке бытовой химии. В связи с этим ИБ-службам было бы полезно глубже погрузиться в технические подробности, не ограничиваясь формальным сравнением галочек по списку «фич». На рынке сейчас много решений разного уровня зрелости, и наличие плюса в строке таблицы сравнения не гарантирует, что в реальности эта функция работает так, как нужно пользователю. Некоторые вендоры стараются выпустить продукт как можно быстрее, и при этом его качество, удобство и надёжность оставляют желать лучшего.
Имея значительный опыт на рынке DLP, мы решили собрать несколько практических вопросов, ответы на которые помогут понять, насколько зрелое решение вы рассматриваете и не получится ли так, что, потратив значительные средства, вы вложитесь в продукт, которому ещё далеко до общепринятых стандартов корпоративного ПО.
Кроме этого, преимущество технологически зрелого корпоративного решения заключается в том, что у вендора не будет проблем с его поддержкой и выпуском новой функциональности. Обычно DLP-системы выбираются исходя из трёх-, а то и пятилетнего горизонта планирования, поэтому соответствие текущим требованиям — не единственный критерий выбора. Надо понимать, куда двигается вендор, и прогнозировать, какие задачи могут возникнуть у вашей компании в среднесрочной перспективе. Если вендор сможет за это время только довести продукт до надлежащего enterprise-уровня, возможно, связываться с ним не стоит.
Для каких каналов возможна блокировка по контенту
Этот вопрос может показаться странным, ведь буква «P» в аббревиатуре DLP означает «prevention». То есть DLP-система по определению должна предотвращать утечки, а это можно сделать только заблокировав подозрительную операцию. Тем не менее многие организации предпочитают использовать DLP-системы в режиме наблюдения, без активного вмешательства в информационные потоки. При этом вся информация сохраняется в архив и служба безопасности реагирует на утечки постфактум, выявляя нарушителей и применяя к ним меры дисциплинарного воздействия. В связи с этим потребность в функциях блокировки отходит на второй план, поскольку активное их использование и не планируется.
Часто такая постановка задачи объясняется рисками ложноположительных срабатываний или сбоев DLP-системы. Если из-за DLP-системы будет нарушено функционирование электронной почты или какого-то другого жизненно важного сервиса, ущерб репутации ИБ- и ИТ-отделов может быть очень высоким. Однако этот аргумент относится только к незрелым DLP-системам, которые практически невозможно внедрить и настроить так, чтобы они работали без сбоев. При этом потенциальная утечка из-за отсутствия режима блокировки может стоить бизнесу очень дорого. Кроме этого, многие руководящие документы (например, GDPR) прямо требуют иметь защиту от утечек в режиме блокировки и предусматривают серьёзные штрафы для нарушителей.
Некоторые каналы, которые контролируются DLP-системами, не позволяют реализовать блокировку по сугубо техническим причинам. Например, для мессенджеров WhatsApp и Telegram возможен только пассивный мониторинг, в противном случае они не будут работать. Однако вряд ли рассматриваемую DLP-систему можно считать достаточно зрелой, если в ней нет блокировки по содержимому файлов следующих каналов:
- электронная почта,
- внешние USB-диски,
- принтеры,
- веб-сервисы (протоколы HTTP / HTTPS).
Где выполняются контентный анализ и применение политик
Смысл этого вопроса заключается в том, что очень мало DLP-систем, присутствующих сейчас на рынке, изначально создавались как единые полноценные системы с продуманной архитектурой. Большинство вендоров начинало с какого-то одного модуля. Далее вокруг этого модуля достраивалось окружение для контроля остальных каналов, хорошо если разработанное тем же вендором. При таком хаотичном развитии приходилось учитывать все ограничения и особенности, которые имелись у первого модуля. Естественно, что результат нельзя назвать образцом эффективной архитектуры, а это неизбежно сказывается на потребительских характеристиках продукта.
Таким образом, по тому, где выполняется контентный анализ, зачастую можно определить, с чего начиналась история той или иной DLP-системы. Например, если endpoint-агент передаёт информацию для анализа на DLP-сервер по протоколу SMTP, то можно предположить, что продукт начинался с модуля контроля электронной почты. При этом сервер может возвращать результат анализа на агент, а может и не возвращать. В последнем случае возможность блокировки по содержимому при записи на USB-диск или при печати вообще отсутствует. Понятно, что при такой архитектуре требуется постоянное соединение с сервером, а загрузка сети может быть слабым местом. В тендерной документации даже иногда можно встретить вопрос, поддерживает ли DLP-система приоритизацию сетевого трафика (QoS, Quality of Service). Это, скорее всего, означает, что рассматривалась только одна такая система, поскольку при грамотном проектировании контентный анализ выполняется там же, где применяются политики. Необходимость в передаче больших объёмов информации по сети просто отсутствует, и вопрос приоритизации сетевого трафика неактуален.
Как работает агент системы, когда нет соединения с корпоративной сетью
Этот вопрос является логическим продолжением предыдущего. Но проблема — не только в том, чтобы оптимизировать использование сетевого трафика. Агент кроме выполнения контентного анализа и применения политик должен передавать информацию о событиях, теневые копии и другие данные на сервер для записи в архив. Если связь с архивом отсутствует, вся эта информация не должна теряться. Как правило, она сохраняется на локальном диске и передаётся на сервер в момент, когда соединение установлено.
В идеале политики должны применяться на агенте в зависимости от того, есть ли непосредственное подключение к локальной сети, или компьютер подключён через VPN, или подключение отсутствует. Таким образом для каждой среды можно устанавливать соответствующие правила. Это бывает важно, когда сотрудник с рабочим компьютером находится вне офиса — например, в командировке или на «удалёнке».
Удобно ли управлять системой
Удобство управления — это весьма субъективный критерий. Кому-то привычнее управлять системой с помощью командной строки, кому-то удобно создавать политики и правила программируя на скриптовом языке. Тем не менее, продуманный и удобный интерфейс может быть косвенным признаком того, что разработчик в состоянии обеспечить качественную разработку и функциональные компоненты системы также качественны и эффективны.
В плане удобства и проработанности интерфейса важно отметить два аспекта. Во-первых, единая консоль управления. Сейчас чаще всего предпочтение отдаётся веб-консолям. Они платформонезависимы, не требуют установки дополнительного ПО, могут работать на мобильных устройствах. Если же консолей несколько — например, отдельные консоли для управления отдельными модулями, — это говорит о том, что продукт не проектировался и не разрабатывался как единая, логически законченная система. Возможно, модули дописывались разными командами и «прилеплялись» (каждый со своей консолью) друг к другу в ходе ускоренного эволюционного развития. Может, они вообще собраны «с миру по нитке» — лицензированы у разных производителей и интегрированы не так, как следовало бы, а так, как получилось.
Во-вторых, зрелая DLP-система должна иметь омниканальные политики. Это означает, что если требуется создать политику для контроля, например, тендерной документации, то достаточно сделать это один раз и просто указать, к каким каналам она будет применяться — электронная почта, веб, USB-устройства и т. д. Менее совершенная система потребует создавать однотипные политики для каждого канала отдельно. Это может показаться небольшой проблемой, но количество политик имеет тенденцию к росту. Когда оно переваливает за сотню, а в правилах используются сложные условия, где присутствуют не только контентные правила, а ещё и группы пользователей, дни недели и т. д., поддержание такого набора в синхронизированном состоянии может превратиться в серьёзную головную боль.
Какое минимальное количество серверов нужно для внедрения
Ещё одним явным признаком дефектной архитектуры, видимым уже на «пилоте», может стать количество серверов, необходимых для работы системы. Если для «пилота» на 50–100 клиентов нужно более одного сервера, это означает, что архитектура системы неоптимальна и, скорее всего, будет требовать повышенных ресурсов и на этапе промышленной эксплуатации. Качественная система уровня «enterprise» одинаково хорошо масштабируется в обе стороны. Безусловно, при увеличении масштаба внедрения потребуются возможность разнесения отдельных компонентов системы на разные серверы и их кластеризация. Но на малых внедрениях DLP-система не должна требовать неоправданно больших ресурсов.
Легко ли развернуть систему, набор вариантов внедрения
Для серьёзной DLP-системы характерна поддержка множества вариантов внедрения. Это, во-первых, упрощает задачу совмещения DLP-системы с существующей ИТ-инфраструктурой, а во-вторых, позволяет гибко балансировать функциональную и вычислительную нагрузку при контроле различных каналов. Сегодня на рынке есть ряд систем, предусматривающих контроль всех каналов на уровне только endpoint-агента. Это сильно упрощает задачу вендору, позволяет сэкономить на команде разработчиков и сократить сроки разработки и выпуска новых версий. Однако такая архитектура не может считаться уровнем «enterprise». Большинство сетевых каналов более естественно контролировать на уровне шлюза, особенно для масштабных внедрений.
Зрелая DLP-система кроме агента для конечных точек предлагает следующие варианты шлюзового внедрения:
- Интеграция с почтовыми серверами (например, Microsoft Exchange). В этом случае можно удобно контролировать и внутреннюю почту.
- Приём почты из технического почтового ящика.
- Интеграция с имеющимся интернет-шлюзом по протоколу ICAP.
- Собственный почтовый транспортный сервер.
Наиболее зрелые вендоры предлагают ещё собственный прокси-сервер, который обеспечивает интеграцию с DLP-системой для контроля HTTP- и HTTPS-трафика.
Поддерживает ли облачную инфраструктуру
Несмотря на небыстрое принятие облачных технологий в отечественной корпоративной среде, проблема использования в ней DLP-системы возникает весьма часто. При этом она может возникать в разных аспектах.
Во-первых, иногда требуется установить серверные компоненты DLP-системы в облаке. Такое случается, как правило, на «пилотах» или у небольших организаций. Всё-таки архив DLP-системы хранит в себе все корпоративные секреты, и размещать его в неконтролируемой среде рискнут немногие. Тем не менее, если DLP-система не поддерживает размещение собственных серверных модулей в облачной среде, это в какой-то момент может стать неприятным сюрпризом.
Второй аспект — это контроль облачных хранилищ и сервисов. Речь тут может идти как о банальной выгрузке файла с конфиденциальной информаций в облако, так и о более сложных схемах, например когда организация использует почтовые сервисы Office 365 или G Suite. Здесь есть много нюансов и возникающих из-за них проблем. Скажем, для выгрузки файлов в облачные хранилища могут использоваться веб- или «толстые» клиенты. Та же история с почтовыми службами — для доступа к ним можно использовать как браузерный клиент, так и классический, например Microsoft Outlook. И для каждого варианта приходится применять различные протоколы и разные варианты внедрения. Также при использовании облачных хранилищ в организации необходимо обеспечить их регулярное сканирование DLP-системой для выявления хранящейся там конфиденциальной информации. Для решения подобных задач появился целый класс решений — CASB (Cloud Access Security Broker, брокер безопасности облачного доступа), но по решаемым задачам эти системы концептуально очень близки к DLP. Так или иначе, эти задачи необходимо решать, поэтому соответствующая функциональность будет появляться и в DLP-системах.
Интеграция с другими корпоративными системами
Здесь речь, конечно, не идёт об интеграции с Microsoft Active Directory, которая должна быть реализована в любой современной DLP-системе. Чаще всего при внедрении DLP-системы бывает полезно, если поддерживается интеграция с нижеперечисленными классами ПО.
Управление информацией и событиями по безопасности (SIEM). Это, пожалуй, наиболее частый вопрос о совместимости, что вполне объяснимо: сейчас постройка центров SOC — одна из самых горячих тем в ИБ, и всем хочется, чтобы события из DLP попадали в поле зрения SIEM. В принципе большинство SIEM-систем умеют самостоятельно загружать информацию из базы данных DLP, но гораздо удобнее, если DLP-система поддерживает Syslog, CEF и другие подобные протоколы. В этом случае при настройке DLP-системы можно более гибко управлять тем, какая информация и в каком виде будет попадать в базу данных SIEM, и добиваться большей эффективности.
Управление правами документов (EDRM). Чаще всего в этом контексте упоминается Microsoft RMS. В принципе, системы DLP и управления правами удачно дополняют друг друга по функциональности и обеспечивают более надёжную защиту, если правильно развёрнуты и настроены. В этом случае DLP-система понимает политики документов RMS и их можно использовать в политиках DLP, при поиске в архиве, построении отчётов и т. д. Кроме этого, DLP-система может сама применять политики RMS по определённым правилам, например при обнаружении определённого контента.
Системы классификации данных. Наиболее совершенные DLP-системы понимают метки в свойствах документов, которые проставляют системы классификации данных, такие как TITUS, Bolden James и т. п., и позволяют их использовать в политиках. В этом случае можно извлечь двойную выгоду из уже потраченных усилий на работы по классификации данных. Впрочем, в наших широтах такие системы встречаются не так уж и часто, в основном у крупных корпоративных заказчиков.
Мультиплатформенность
Поддержка нескольких endpoint-платформ также является признаком солидной DLP-системы. Самые простые решения предлагают агентский модуль только для Windows. Однако сегодня этого может быть уже недостаточно. Давно взятый политический курс на импортозамещение может привести к массовому переходу на один из клонов Linux в обозримом будущем. Понятно, что связанная с этим замена DLP-системы — самая маленькая боль при решении этой проблемы. Тем не менее уже сегодня есть более зрелые продукты, в которых агент работает и на Linux, и на Mac.
Отдельно стоит сказать о поддержке мобильных устройств на базе iOS и Android. О ней часто спрашивают, но, к сожалению, реализовать полноценный агент для смартфонов и планшетов, особенно от компании Apple, практически невозможно по объективным техническим причинам. С другой стороны, при реализации стратегии BYOD можно (и нужно) использовать решение класса Mobile Device Management. Оно позволит задействовать встроенные возможности мобильной ОС, настроить политики конфиденциальности и снизить риск утечки через гаджеты до приемлемого уровня.
Выводы
Как мы увидели, DLP-системы развивались неоднородно, что может сказываться и на степени целостности системы как слаженно работающего механизма, и на наличии поддержки отдельных каналов распространения информации, и на объёме данных, которые необходимо передавать по каналам связи для функционирования системы. Конечно, в современном мире также имеют значение и страна происхождения используемого программного продукта, и цена решения, и стоимость владения им. Но всё же DLP должны в первую очередь решать реальные производственные задачи и по возможности работать не только в режиме мониторинга.
