Привет, я Артемий, архитектор систем информационной безопасности группы компаний «Гарда». Моя карьера в ИБ началась с работы у крупного производителя систем предотвращения утечек информации на позиции «Аналитик внедрения». Аналитики – это эксперты вендора по настройке пользовательских правил под бизнес-процессы заказчика. Мы помогаем формулировать требования к системе, готовим концепции настроек и использования лучших практик систем. Поработав у нескольких разработчиков DLP, я проанализировал сотни документов, написал множество регулярных выражений, сформировал десятки ворк-эраундов, а также провел неисчисляемое количество часов в тюнинге настроек правил DLP-систем.
По мере накопления опыта и обратной связи от клиентов я заметил, что многие заказчики, покупая DLP-систему, используют правила «из коробки». Без корректно настроенных правил система генерирует много мусорного трафика, при этом эффективно пользоваться продуктом становится практически невозможно. Чтобы помочь начинающим аналитикам DLP-систем разобраться в особенностях настройки различных технологий и правил, появилась идея переложить мои практические навыки и знания «на бумагу».
Опытным аналитикам эта статья может показаться банальной, но для новичков, а также для CISO без бюджета на консалтинговые и аналитические услуги от интегратора или вендора, этот материал станет полезным.
Будем искать ответы на следующие вопросы:
Кроме того, я расскажу о технологиях, опишу реальные примеры применения, неочевидные возможности DLP-систем и дам чек-лист по настройке.
Я старался не фокусироваться на продуктах конкретных производителей и описал принципы работы с DLP-системой на конкретных примерах, учитывая стандартные возможности большинства российских продуктов этого класса. Главная задача статьи – передать опыт внедрений и рассказать, как решать проблемы при настройке аналитической составляющей системы.
Что такое DLP?
DLP (Data Leak Prevention) — это система обнаружения и предотвращения утечек конфиденциальной информации или сведений, составляющих коммерческую тайну. DLP предназначена для мониторинга (аудита) трафика организации на соответствие заданной политике безопасности, предоставления информации для внутренних расследований и ведения архива данных с возможностью ретроспективного анализа. Решение используется службами информационной безопасности вне зависимости от отрасли бизнеса.
Типовая архитектура
Перед тем, как система сможет проанализировать трафик, этот трафик необходимо в систему подать. В типовом варианте у различных DLP-решений присутствует два способа подачи трафика на комплекс: централизованный (через точки «общего» трафика) и децентрализованный (агенты).
Централизованных способа три:
Подача почтового трафика с почтового сервера методами smtp-relay или bcc.
Подача веб-трафика с прокси-серверов, поддерживающих протокол ICAP.
Подача сетевого трафика с помощью зеркалирования трафика в комплекс.
К децентрализованному сбору трафика относится агентское решение.
На конечное устройство пользователей в корпоративной сети устанавливается специальная программа-перехватчик (агент) в скрытом или видимом режиме, которая журналирует действия пользователя. Как показывает практика построения комплексной защиты, чаще всего используется гибридный метод, чтобы охватить как можно больше событий: агенты + почта + SPAN.
Архитектурно комплекс работает следующим образом. На анализатор подается трафик из различных источников (см. выше). К этому трафику применяются настроенные правила реагирования — политики, после чего создаются события информационной безопасности. Затем уже сформированные события отправляются в хранилище для последующего ретроспективного анализа.
Что такое аналитическая настройка системы?
По завершению физического внедрения DLP в продуктовой среде на систему подают трафик, устанавливают агентов. Система работает, но количество срабатываний по политикам по умолчанию превышает 10 000/сутки, система «тонет» в ЛПС (ложноположительные срабатывания — легитимное событие, на которое система реагирует) и ЛОС (ложноотрицательные срабатывания — событие с нарушением политик, которое система пропускает). Получается классическая ситуация: «Система работает, но не срабатывает». Важно — без соответствующих настроек, то есть по умолчанию, система не понимает, что именно для конкретного заказчика критично, поэтому всегда будет работать неудовлетворительно.
Что делать дальше? Как сделать срабатывания более эффективными, качественными?
Необходимо настроить аналитическую часть системы — она отвечает за корректные срабатывания. Для этого в DLP существуют конструкторы политик безопасности — определенные правила, которые необходимо настраивать на старте боевого внедрения. В общем смысле эти правила и являются олицетворением политик ИБ. DLP должна отличать чувствительные данные от менее критичных, каким пользователям необходимо установить усиленный контроль, мониторить отдельные каналы (почта, мессенджеры, копирование на внешние носители и так далее).
Обычно политики состоят из сочетаний нескольких групп параметров:
периметры (направление адресатов);
информационные потоки/инфо-объекты/активы/объекты защиты. Это непосредственно контент актива, который мы защищаем: слова из документа, шаблон кредитной карты и т.д.;
дополнительные параметры (IP, порт, URL, расширение файла).
Для настройки детектирования контента и важных фрагментов-триггеров внутри документов (грифы, паспортные данные, номера кредитных карт и тому подобное) в системах DLP используются технологии контентного анализа. Разберем те, что представлены в большинстве DLP-систем.
Технологии контентного анализа
Лингвистический анализ
Технология лингвистического анализа позволяет настроить список слов или фраз для анализа текстовой информации. При перехвате текстового файла в потоке трафика DLP-система сравнивает наличие слов из списка в перехваченном документе и, если такие слова встречаются в определенном количестве, создает событие.
Лингвистический анализ позволяет решить следующие задачи:
Классифицировать документы: финансы, бухгалтерия, конструкторская документация и т.д.
Если документ имеет общий шаблон, но какая-то часть документа изменяется регулярно, например, шаблоны бланков, то технология помогает детектировать такие шаблоны.
Детектирование по триггерам (например, по словам в общении работников, связанных с незаконными действиями, обсуждением руководства, ненормативной лексикой и др.).
Регулярные выражения (RegExp или иные)
Если в случае с набором слов все понятно, то что делать с наборами цифр или сочетаниями цифр и букв в документе? Как отличить гриф от фразы в тексте? На помощь приходят регулярные выражения. Это формальный язык, который позволяет описывать варианты последовательностей символов. С помощью регулярных выражений система детектирует конкретный объект (номера карт, паспортные данные, номера деталей и так далее).
Важно понимать, что актив — это не всегда конкретный документ. Например, утечка паспортных данных в теле письма — тоже потенциальное нарушение. Актив — это конкретные данные в документе. Для детектирования активов регулярные выражения подходят наилучшим образом.
Как отличить конкретный номер документа (Пример: УРН 34П65), который проставляется на документы в организации, от любого другого номера?
Рассмотрим примеры применения регулярных выражений.
1. Регулярное выражение позволяет детектировать не просто сам актив, но и окружающие его символы. В случае детектирования грифа «Коммерческая тайна» необходимо описать регулярное выражение:
где \r|\n|\t — управляющая последовательность «возврат каретки»,
управляющая последовательность «горизонтальный табулятор»,
управляющая последовательность «перевод строки» соответственно,
^ и $ — начало строки и конец строки соответственно.
«Коммерческая тайна» в разных вариантах написания: разный регистр, табуляцией вначале и конце и так далее.
При такой форме описания объекта можно не переживать за ЛПС в обычном тексте (например, в подписи письма), при этом детектирование грифа «Коммерческая тайна» будет производиться корректно.
2. Не всегда получается ориентироваться на конкретный документ, так как слова внутри встречаются общие (например, любая форма договора). В таком случае приходится искать какой-то признак важности документа. Например, учетный номер документа.
Предположим, есть условный УРН (учетный регистрационный номер) – такой номер в организации проставляется на все важные документы. По регламенту компании наличие этого номера в заданном формате автоматически делает документ конфиденциальным.
Зная алгоритм формирования УРН, можно настроить регулярное выражение:
где УРН — фиксированные символы,
[0-9] — встречающиеся символы,
{2} — количество предыдущих символов,
(Д|А) Д — действующий, А – архивный.
Пример для проверки регулярного выражения: УРН 11А56.
Подобные документы передаются по каналам коммуникаций с уже проставленным номером. Это, как правило, скан-копии документов. Это значит, что мы говорим о детектировании растровых изображений (pdf-, image-форматах).
Для детектирования подобных кейсов зачастую DLP-системы имеют встроенный OCR-модуль, позволяющий извлекать текст из изображений. Дальше этот текст направляется на анализ всем вышеперечисленным технологиям.
Цифровые отпечатки
Под цифровыми отпечатками подразумеваются неизменяемые документы или файлы. Например, у ресторана есть свой рецепт блюда, этот рецепт статичен и никогда не изменяется. Файл, содержащий описание рецепта, необходимо защищать.
Технология работает просто: документ загружается в базу DLP как эталонный. Система записывает хеш этого документа (алгоритмы хеширования: SHA-1, MDA-5, SHA-256 или выше), после чего сверяет в проходящем трафике хеши всех передаваемых документов с базой эталонного и, если хеши совпадают, система подсвечивает срабатывание.
Преимущества:
Технология используется как для бинарных файлов, так и для текстовых. То есть если необходимо детектировать с помощью DLP конкретную аудиозапись, то данная технология будет решением.
Простота настройки. Один клик — система все запоминает и в дальнейшем работает автоматически.
Минусы слабая устойчивость к внесению изменений в файлы. Например, в эталоны загружается jpg‑файл и в DLP‑системе формируется эталонный хеш. Если злоумышленник при передаче меняет один пиксель в исходном файле, то хеш в этом передаваемом файле меняется. Как итог — DLP‑система не обнаружит инцидент и срабатывания не будет.
ML-модели
Что делать с изображениями паспортов, СНИЛС, водительских удостоверений и с другими графическими персональными данными (сканы, в частности), в которых логика построения элементов внутри одинаковая, но сами изображения всегда разные?
Для таких случаев существуют технологии машинного обучения для детектирования похожих картинок.
В некоторых DLP‑системах имеется ML‑модель (machine learning — от англ. машинное обучение), которая уже обучена на часто встречающиеся персональные данные: разворот паспорта, лицевая сторона СНИЛС и так далее.
Мы рассмотрели технологии контентного анализ, которые помогают определять содержимое файлов, но необходимо помнить, что сама политика безопасности формируется не только из технологий, но и из дополнительных параметров. Рассмотрим типовые дополнительные параметры.
Дополнительные параметры для настроек политик
Отправитель-получатель
Типовым сценарием для политики является настройка отправителя и получателя, что позволяет описывать направление движения трафика. Пример: «если сотрудник А отправит файл НЕ сотруднику Б, то это нарушение».
Обычно отправителем считается не один пользователь, а целый домен (практически у всех DLP‑систем имеется интеграция с системой каталогов пользователей по LDAP (протокол интеграции с Active Directory — самой распространенной на данный момент службой каталогов), который содержит информацию о сотрудниках организации, рабочей почте и так далее). Соответственно, все, что циркулирует в рамках домена подозрений не вызывает, а то, что выходит за пределы домена, требует контроля.
Каналы передачи данных (каналы коммуникаций)
В начале мы говорили о точках съема трафика для DLP: почта (почтовый сервер организации), мессенджеры, физические интерфейсы (копирование на внешние съемные носители), кейлогеры (запись нажатия клавиш), веб-трафик, облачные хранилища, буфер обмена и так далее. Каналы можно выбирать в политиках информационной безопасности, чтобы уменьшить количество ЛПС. Например, регулярное выражение, которое корректно реагирует на почтовые события, может генерировать большое количество ложных срабатываний на события кейлогера или веб-трафика. В таком случае в качестве канала передачи данных достаточно выбрать только почту.
Хост (по IP) для недоменных машин
В таком случае к домену конкретная машина никак не привязана, а единственным критерием для детектирования будет IP.
Сигнатуры файлов
Речь идет о MIME-типах файлов, не просто о расширении. Отличительной особенностью детектирования таких типов является то, что сигнатура файла не меняется, даже если меняется расширение.
Пользователь
Сотрудник (как правило, используется OU — organizational user, название подразделения в службе каталогов) из системы каталогов Active Directory.
Откуда брать базу документов для формирования политик безопасности
Итак, я описал общие принципы контентного анализа и того, как вообще система понимает, что находится внутри того или иного файла, или сообщения. Как работает DLP и как насыщать ее данными стало понятнее, но откуда взять эти данные в каждой отдельной организации? Как понять, какая информация критична для организации, а какая нет?
Любые настройки политик по защите данных представляют собой перенос регламентов компании/требований законодательства с бумаги в систему. Следуя этой логике, в первую очередь необходимо определить, что в конкретной компании считается безопасным взаимодействием, а что запрещено; что считается конфиденциальной информацией, а что нет.
Для этого существуют различные регламенты по безопасности. Необходимо прочитать документы, описывающие технологический процесс обработки информации.
Например, в документе может быть указано: «К коммерческой тайне относятся следующие документы: „Конкурсная документация“». Соответственно, необходимо настроить политику на детектирование данного рода документов с использованием какой‑то из технологий контентного анализа. Вопрос № 2 — где взять шаблон документов или посмотреть примеры?
Можно запросить примеры всех важных документов у владельцев процессов информационного обмена: по конкурсной документации — у отдела закупок, по конструкторским документам — у отдела по разработке и так далее.
А что делать, если регламентов нет? В таком случае стоит провести аудит путем интервьюирования владельцев бизнес-процессов: опросить начальников отделов и департаментов о том, с какой информацией они работают и что, с их точки зрения, является важным. Только они знают, утечка какой информации действительно будет критична. А что еще важнее – они понимают, как работает конкретный процесс.
Когда удастся получить важные документы, можно приступать к непосредственной настройке аналитической части.
ВАЖНО!
Когда идет речь о мониторинге конфиденциальных данных, имеется ввиду контроль конкретных объектов – будь то номера паспортов отдельно от документа или скан-копия самого документа.
Реальные примеры
Задача 1. Необходимо контролировать конструкторскую документацию (чертежи).
Риски: Любые чертежи в организации – это разработка, ноу-хау компании, утечкой которой смогут воспользоваться конкуренты во вред компании. При этом по регламенту, как правило, запрещено передавать подобного рода данные за периметр организации.
Целевая отрасль: производство.
Решение: политика детектирования сигнатур чертежей.
Загрузить всю базу конструкторской документации видится непосильной задачей, так как каждый день в организации появляются новые чертежи, многие устаревают. Значит мониторинг подойдет только на один важный проект и то на короткое время.
Можно детектировать все расширения, доступные DLP-системе от конкретного поставщика, вместе с сигнатурами данного типа файлов. Часто DLP уже содержат в себе предустановленные расширения для конструкторской документации (AutoCAD, dwg и так далее). Соответственно, политика будет выглядеть следующим образом:
Отправитель ≠ Компания (имеется ввиду домен службы каталогов);
Получатель ≠ Компания;
Формат файла = Конструкторская документация (предустановленный перечень сигнатур, MIME-типы файлов).
Такая политика покроет отправку во вне любой конструкторской документации, но в компании могут использоваться сигнатуры, которых нет у вендора DLP. Эту задачу тоже можно частично решить – добавить расширение как регулярное выражение для поиска в имени файла (пример регулярного выражения для расширения dwg: \.dwg$ )*.Само регулярное выражение можно проверить на сайте https://regex101.com/, если у вендора нет встроенной проверки.
*Если злоумышленник поменяет расширение, то DLP все равно увидит сигнатуру и проанализирует ее по полному стеку применяемых технологий. В случае с контролем только расширения, при его смене DLP уже ничего не задетектирует.
А что делать, если конструкторская документация в формате pdf?
В таком случае подойдет обучение системы на изображениях чертежей (pdf, jpeg и других). Необходимо собрать все похожие чертежи и попросить вендора обучить систему или обучить самостоятельно, если система позволяет это сделать.
Решение:
Настроить политику на детектирование сигнатуры конструкторской документации.
Настроить мониторинг специфичных расширений компании, если такие имеются.
Включить обучение ML-моделей на детектирование изображений конкретных чертежей.
Если настроить представленные три политики, то большая часть задач по данному направлению закроется.
Задача 2. Необходимо детектировать отправку запароленных архивов вовне.
Риски: пересылка запароленных архивов – всегда потенциально критична, так как нет контроля за информацией, которую отправили в этом «ящике Пандоры».
Целевая отрасль: любая.
Решение 1. Политика определения запароленных активов.
Настройка выглядит следующим образом:
Отправитель = Любой;
Получатель ≠ Компания;
Формат файла = Запароленные архивы (предустановленный перечень сигнатур, MIME-типы файлов).
Данная политика позволит детектировать отправку запароленных архивов.
Если же необходимо вскрыть запароленный архив — можно настроить дополнительную политику, которая будет детектировать весь текст ввода с клавиатуры в конкретных приложениях. Если архив защищают паролем [АН3] на рабочей станции с DLP‑агентом, то, как правило, это делают в типовых приложениях (7z, 7zip, RAR и так далее), и можно настроить политику на взаимодействие с типовым ПО.
К сожалению, если архив попал на АРМ уже запароленным, то шансы вскрыть его без применения специализированных средств стремятся к нулю.
Решение 2. Политика детектирования ввода текста с клавиатуры (ввода пароля) в приложениях-архиваторах.
Настройка выглядит следующим образом:
Отправитель = Любой;
Получатель = Любой;
Канал перехвата = Кейлогер (ввод с клавиатуры);
Приложение = Список имени приложений (заранее необходимо настроить список всех .exe-архиваторов).
Примерный список процессов программ-архиваторов, который можно загрузить в DLP-систему: *WinRar*; *WinZip*; *7z*; *7-z*.
Задача 3: Детектирование отправки конкурсной документации за пределы периметра организации.
Риски: разглашение результатов конкурса другим участникам, разглашение промежуточных результатов конкурса с указанием цен поставщиков.
Целевая отрасль: любая.
Как правило, шаблон на конкурс у компании свой, значения внутри меняются: имя компании, предмет конкурса, цена и так далее., но сам документ имеет определенные термины, которые встречают у всех организаций.
Просто добавить такой документ в систему, как хеш, недостаточно. Необходимо проанализировать документ и добавить конкретные слова и словосочетания в словарь приложения/политики.
Решение:
1. Поставить на контроль сам документ по конкурсной документации, создав правило:
Словарь: Заказчик, Поставщик, Объект закупки, Конкурсная документация, Цена контракта, Порядок оплаты, Требования к участникам закупки, участники закупки.
2. Мониторить характерные слова. Предположим, мы знаем участников конкурса: ООО «Ромашка», ГК «Рога и копыта». В документе есть слово «Цена», после которого всегда идет запись формата: «800000 РУБ. за ед. товара».
Поэтому для мониторинга утечки результатов конкурса можем так и указать
где \d — соответствует любой цифре от 0 до 9,
{1,10} — поиск не менее 1 и не более 10 вхождений предыдущего выражения,
\s* — любое кол-во пробела от 0 до бесконечности,
\. — экранирование знака «.»,
[Рр] — любой из 2-х символов.
Пример для проверки регулярного выражения: 4545454550 РУБ. за ед. товара.
Итак, решением станет политика:
Отправитель = Компания;
Получатель = Не компания;
Регулярное выражение выше, и термин «Цена», и список «Компании, участвующие в конкурсе».
Задача 4: Отправка списка с индивидуальными условиями (цены, информация о скидке) и персональными данными (номер телефона, паспортные данные, номер дебетовой карты) по любому из каналов передачи данных.
Риски: слив персональных данных, а также цен и условий скидок. Это чревато коммерческими и репутационными потерями, переманиванием клиентов конкурентами, и штрафами за нарушение требований законодательства в области защиты персональных данных.
Целевая отрасль: ритейл, банки и иные организации, работающие с клиентской базой.
Решение: политика детектирования персональных данных клиентов или сотрудников:
Отправитель = Компания;
Получатель ≠ Компания;
Детектирование (шаблона кредитных карт или Паспортных данных (шаблона) или шаблона номеров телефонов) в количестве больше пяти штук. Как правило, у большинства вендоров эти регулярные выражения уже имеются.
Таким образом, адаптируя настройки под свою компанию, инфраструктуру, особенности бизнеса и конкретную отрасль, можно значительно улучшить результативность работы DLP.
Неочевидные возможности DLP-систем
Зачастую DLP воспринимается только как система мониторинга корпоративной почты и еще некоторых каналов передачи данных. Мы говорили о них выше.
На самом же деле в DLP есть много смежных функций, которые напрямую или косвенно могут выполнять задачи других средств защиты информации. Например, сканировать сетевые хранилища на наличие критических данных внутри, что является прямым функционалом DAG-систем.
Разберем конкретные варианты:
1. Сканирование рабочих станций на предмет хранения конфиденциальных файлов (элемент DCAP- и DAG-систем).
Многие DLP-системы имеют встроенный поисковый робот, краулер, который позволяет при помощи агента или по SMB-протоколу сканировать рабочие места, а также файловые хранилища на наличие конкретных файлов. Поэтому, если задача состоит именно в том, чтобы провести ревизию рабочих мест, то встроенного модуля будет более чем достаточно.
2. Мониторинг запуска средств администрирования на рабочих станциях (функция PAM).
Нередко встает задача мониторинга использования средств администрирования и повышения прав пользователей.
Риски: Злоупотребление средствами администрирования на рабочих машинах пользователя.
Целевая отрасль: любая.
Решение: политика детектирования ввода с клавиатуры с термином из списка: admin, root, superuser, su, sudo в приложениях из списка: «ssh.exe, powershell.exe, WinSC.exe, putty.exe, cmd.exe, Code.exe, WindowsTerminal.exe, OpenConsole.exe».
3. Мониторинг ввода стандартных паролей (элемент Менеджера паролей).
Риски: многие пользователи при работе с корпоративными сервисами устанавливают стандартные пароли, такие пароли злоумышленнику просто подобрать. Ввод стандартных паролей необходимо детектировать с помощью кейлогера.
Решение: политика по детектированию ввода стандартных паролей в корпоративных приложениях.
Канал передачи = ввод с клавиатуры;
-
Термины из списка:
123456789
1000000
12345678
12345
123123
12345zz
qwerty
Qwerty123
1234567890
123456
Процесс = Корпоративные приложения (у каждой компании это свои .exe).
Заключение
Общий вывод можно сделать следующий: настройка DLP является одним из важнейших факторов в эксплуатации самой системы и ее результативности. Необходимо помнить, что, настроив один раз DLP‑систему с нуля, сразу все кейсы не решатся — правила необходимо дорабатывать и адаптировать в процессе эксплуатации системы.
Чтобы специалистам, работающим с DLP, было проще ориентироваться на этапы работ сразу после внедрения и в процессе эксплуатации, я подготовил чек‑лист.
Чек-лист по настройке DLP
-
Убедиться, что работают все требуемые функции DLP: установлены агенты на все необходимые рабочие станции, подан почтовый трафик, подан веб-трафик, сервисы системы работают в штатном режиме.
Сформировать требования к политикам DLP-системы по детектированию обращения с конфиденциальными данными организации и персональными данными путем изучения требований законодательства, локально-нормативных актов, внутренней нормативной документации компании или интервьюирования участников бизнес-процессов. После можно сформировать документ, описывающий настраиваемые правила политик – концепцию настройки политик.
Продумать концепцию настройки правил.
Реализовать первую итерацию настройки политик.
-
В течение первых суток после применения конфигурации проверить статистику притока срабатываний по политикам, чтобы убедиться, что не было допущено ошибок в настройках. Бывает, что при настройке какой-нибудь простой политики играет роль человеческий фактор и закрадывается шальная «*». В таком случае, будет много ЛПС, которые можно будет увидеть по слишком большому притоку событий в первые часы после настройки.
Следующую итерацию проверки и «тюнинга» политик реализовать через 3-7 дней.
Регулярно проверять политики на предмет актуальности (рекомендуется не реже одного раза в три месяца).
Надеюсь, я смог объяснить, как решать проблемы при настройке аналитической составляющей DLP-системы. Буду рад вопросам и конструктивному обсуждению.
А комплексно обсудить вопросы защиты данных приглашаю на нашу конференцию «Сохранить все: безопасность информации» 24 октября в конгресс-центре Soluxe — буду рад встрече на стенде группы компаний «Гарда».