DLP как сервис – маленькие радости реализации

Серьезные затраты также приходятся на сам процесс внедрения системы: разработка регламентов и политик для ее использования в компании может потребовать ресурсов и некоторого опыта. Внедрение занимает время. Переход от пассивного мониторинга событий к активному противодействию утечкам может легко превысить полгода, не считая затрат на подготовительные работы и согласование у заинтересованных лиц внутри компании. Стоимость оборудования, его размещения и обслуживания, обеспечение квалифицированными кадрами на продолжительный период также являются значительными статьями расходов.

В этой связи идея получить DLP-систему как сервис становится, как минимум, финансово интересной. Целью нашей статьи является попытка проанализировать технические и организационные аспекты вариантов такой реализации и оценить потенциальную эффективность сервисного подхода к эксплуатации DLP-решений.

Одним из возможных вариантов снижения затрат на оборудование и лицензии является получение их на арендной основе или по подписке у производителя или крупного сервис-провайдера. Располагаться система может как на площадке заказчика, так и в собственном облаке поставщика услуги. Классическая архитектура DLP-решения включает следующие стандартные компоненты:

• агенты рабочих станций и серверов, собирающих с этих источников информацию об активности с конфиденциальными данными;
• сенсоры сбора данных, как выступающие в роли точки централизованного сбора информации с агентов, так и собирающие и обрабатывающие ее на сетевом уровне (SPAN-порт, почтовый и веб-трафик);
• узел сбора инцидентов и исторический архив хранения, редактор политики.

Могут ли сенсоры сбора данных быть вынесены с площадки компании в облако? Да, но нужно учитывать ограничения такого подхода. Даже для средней компании объем трафика, поступающего на сенсоры непосредственно с инфраструктуры или с агентов, может быть значительным, поэтому размещение сенсоров DLP в облаке потребует увеличения полосы пропускания внешних каналов связи.

Реальным вариантом реализации такого подхода является получение сервиса контроля утечек непосредственно от провайдера каналов связи и сбор требуемых данных в «трубе» интернет-соединения. В принципе, для начала этого может быть достаточно. Но эта схема оставляет за скобками обеспечение контроля наиболее любопытных каналов утечки информации – рабочих станций, съемных носителей, шифрованных интернет-сессий и файловых серверов.

Таким образом, агенты и сенсоры сбора событий в большинстве случаев должны быть расположены на собственной площадке компании, а в облаке сервис-провайдера могут быть размещены архив инцидентов и редактор политики. При этом немаловажными вопросами становятся критерии сохранения событий и его максимальные сроки – в случае необходимости долгого хранения всей или большой части исходных событий мы неизбежно сталкиваемся все с той же проблемой нагрузки на интернет-каналы, а также со стоимостью архивирования значительных объемов информации.

Помимо самой технической возможности хранения в облаке стоит проанализировать, что именно в него попадает. В случае DLP-платформы речь идет о целевом хранении всех транзакций конфиденциальных данных за пределами компании – заметной части почтовой переписки, интернет-активности пользователей и результатов обработки файлов на рабочих станциях (передачи на съемные носители или в печать). Для обеспечения защиты от ранее не фиксировавшихся инцидентов существующие DLP-системы предоставляют возможность хранения обширных архивов событий. Полученное хранилище данных по своему содержимому вполне сопоставимо с почтовыми серверами компании, и размещение такого архива в облаке практически аналогично решению по использованию облачных сервисов электронной почты или документооборота. Но далеко не каждая компания готова пойти на это, так как требуется серьезный уровень доверия к поставщику подобной услуги. Стоимость решения будет заметной, хотя и дешевле по сравнению с тем, если бы организация сама купила оборудование, лицензии и обеспечила ресурсы ЦОД.

Тем не менее, несмотря на эти очевидные вопросы, интерес к подобному варианту использования DLP-системы сохраняется. Есть примеры, когда компании реализуют вынос обработки событий в собственные, принадлежащие им облака во внешних ЦОД, от такой схемы остается только один шаг до перехода на сервисную модель.

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

Есть ли место интегратору?

Для того чтобы проанализировать потенциальную полезность сервис-провайдера в обеспечении процесса контроля утечек конфиденциальной информации, необходимо разложить на составляющие сам процесс обработки утечки, зафиксированной системой. Его можно разделить на следующие этапы:

• • • реализация политики безопасности – разработка и отладка правил автоматического реагирования на события для системы;
    • выявление инцидента – активный мониторинг событий, зарегистрированных в системе, фактическое обнаружение и фиксация инцидента;
    • разбор инцидента – отсечение ошибок первого рода или ложных срабатываний, уточнение его критичности, эскалация факта возникновения инцидента (при необходимости);
    • анализ инцидента – определение его источника (в данном случае речь чаще всего идет о конкретном сотруднике компании), причины возникновения (например, недостаточно жесткая политика блокирования веб-трафика или нарушения в бизнес-процессах), анализ сопутствующей активности пользователя в момент возникновения утечки, эскалация на соответствующие подразделения;
    • блокирование инцидента – активное техническое противодействие произошедшей утечке и возможности ее повторения;
    • дальнейшее расследование инцидента – коммуникация с пользователем, его непосредственным руководителем и внутренней службой безопасности и прочие нетехнические способы получения и обработки информации о пользователе и инциденте.

Крайне редко компания готова предоставить сервис-провайдеру доступ для просмотра и анализа исходных событий утечки (тела электронного письма, файла, передаваемого на флеш-носитель), поскольку данная информация имеет очень высокий уровень конфиденциальности и не может быть передана для анализа сторонней организации даже при соответствующем уровне соглашений. Поэтому популярным сценарием вовлечения сервис-провайдера является делегирование ему частичных прав на исходные события: с маскированием или шифрованием исходной информации, с предоставлением только общих данных о структуре утечки, названиях файлов, их размере и т.д.

Какие из описанных этапов расследования при таком подходе может полноценно выполнять партнер? Первичный разбор инцидентов – это основной сценарий. Такой подход позволяет снять нагрузку с офицеров безопасности, при этом оставляя возможность контроля над ситуацией.

Варианты привлечения сотрудников интегратора также имеет смысл рассмотреть, если параллельно оказываются прочие услуги по безопасности – анализ событий, учет уязвимостей и т.п. Еще одним хорошим сценарием может являться организация на площадке поставщика услуги выделенного узла защиты интернет-коммуникаций для компании – комплексного решения по защите входящих данных от спама, malware, phishing и других подобных рисков, дополненного DLP-средствами для исходящих данных.

Для самого факта фиксации срабатывания правил системы и регистрации инцидента не требуется высокого уровня доступа и анализа информации. В процессе более глубокого анализа инцидента уже могут возникать сложности. Провести корректное отсечение ошибок второго рода достаточно сложно, если не иметь доступа к исходному сообщению, особенно в случаях, когда политики выявления базируются не на простых высоковероятных событиях (ключевые слова, регулярные выражения или умные идентификаторы, такие как номер кредитной карты, паспорта и социального страхования), а требуют детального анализа текста, например, с использованием технологии цифровых отпечатков.

При этом одной из наиболее оптимальных является схема совместной ответственности за этап: сервис-провайдер выполняет разбор инцидента самостоятельно для простых правил срабатывания или тогда, когда вероятность совпадения файла с цифровым отпечатком близка к 100%, в противном случае запрашивает дополнительную информацию по исходному сообщению у ответственного специалиста компании или передает ему разбор инцидента целиком. Безусловно, при этом оба участника процесса серьезно зависят от возможностей и качества работы используемой программной платформы: если внутренние алгоритмы системы или реализуемые политики допускают высокую погрешность в результате, достаточно сложно выстроить комфортное для обеих сторон взаимодействие.

В процессе рассмотрения и блокирования инцидента роль сервис-провайдера может быть достаточно существенной: и оценка политик вместе с разработкой инструкций по их ужесточению или оптимизации, и ретроспективный анализ событий зачастую требуют не непосредственного доступа к конфиденциальной информации, а достаточно высоких компетенций относительно анализа данных, современных способов организации утечек и применяемых средств защиты. При этом принятие решения о применении политик блокирования и сам процесс дальнейшего расследования инцидента остаются на стороне компании и вряд ли могут быть переданы интегратору.

Более глубокие методы взаимодействия с накопленным архивом инцидента, например, с использованием возможностей интеллектуального поиска невыявленных инцидентов по историческому архиву сообщений, находятся уже за пределами доступа специалистов интегратора. Данная аналитическая задача требует максимального уровня доступа к информации и чаще всего остается в зоне ответственности компании. Интегратор может выступать как консультант по наилучшим практикам и возможностям системы, не имея непосредственного доступа к данным.

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