Устранить «уязвимость» всех DLP-систем за один месяц (без звонков, смс и регистрации)

Устранить «уязвимость» всех DLP-систем за один месяц (без звонков, смс и регистрации)

Чтобы предоставить доступ удаленным сотрудникам к корпоративной электронной почте, компании используют веб-приложение, наиболее популярное сейчас – Outlook Web Application (OWA). Это максимально удобно и при этом в той же степени небезопасно. Почтовые веб-сервисы, такие как OWA, являются неконтролируемым каналом утечек информации – это ахиллесова пята DLP-систем. Поскольку веб-приложение публикуется в сеть Интернет, сотрудник может войти в учетную запись с личного устройства и скачать содержимое черновиков или вложения из любого письма, и  DLP-система это не зафиксирует.

Автор: Петр Куценко, руководитель направления Solar webProxy компании «Ростелеком-Солар»

Атакуя, защищай

Маршрутизатор организации является единственной точкой выхода в интернет. Через него OWA обращается к внутреннему ресурсу и выходит в интернет. При подключении пользователя к адресу OWA, пакет отправляется в маршрутизатор, тот направляет его на конкретный сервер внутри сети. В нашем случае – на Outlook Web Application.


Иллюстрация 1: Типичная схема канала утечки информации через OWA

В архитектуре веб-приложения Outlook Web Application не предусмотрена возможность отправки информации о черновиках для анализа в сторонние системы. Классический проброс портов не дает возможности анализировать содержимое почтового трафика. На первый взгляд кажется, что внешний веб-ресурс и доступ к нему с внешнего устройства не поставить под контроль DLP-системы, но так лишь кажется.

На деле чтобы эффективно контролировать внешний ресурс OWA, нужно научиться вскрывать трафик HTTPS. Для этого необходимо, используя принцип «Человек посередине» (MITM), встать промежуточным звеном между веб-приложением и сервером с помощью режима обратного прокси-сервера. Поскольку в экосистему Центра продуктов Dozor входит Solar webProxy (шлюз веб-безопасности, поддерживающий режим прямого прокси-сервера), решение лежало на поверхности, требовалось лишь дополнить его возможностью работы в обратном режиме. Таким образом, все обращения, которые совершит удаленный пользователь к веб-приложению, SWG зафиксирует и при необходимости отправит в DLP-систему на анализ.


Иллюстрация 2: Схема контроля канала утечки информации через OWA с использованием Обратного прокси и/или DLP

Сценарии применения обратного режима для контроля утечек

1. Контроль черновиков

Самый долгожданный среди пользователей DLP-систем сценарий связан с контролем скачивания документов через черновики с почтового веб-сервиса.

Гипотетическая ситуация – предположим, сотрудник Иван находится в сговоре с линейным руководителем Яковом, они выполняют заказы «на сторону». Оба пытаются слить файл с проектными данными сначала по исходящей почте, затем при изменении расширения файла по исходящей почте, далее копированием на USB – однако это контролируемые DLP каналы утечки и политика их блокирует. Наконец, дома Якова посещает гениальная по простоте идея – сохранить документ в черновиках и, придя домой, скачать на личное устройство через веб-приложение. Фактически для DLP это «слепая зона», но при интеграции с решением на базе технологии обратного прокси есть возможность зафиксировать факт движения коммерческой тайны и заблокировать перемещение документа по политике безопасности.

2. Синхронизация политики в отношении особых групп контроля

Вот еще один пример – в секретариате АО «Завод Лютик» проходит испытательный срок новый главный бухгалтер Евдокия Иванова. В «Лютике» также долгое время безукоризненно выполняет свои обязанности руководитель хоз.обеспечения Егор Иванов. В компании организована внутренняя рассылка «Планы-финансы» для ключевых и руководящих сотрудников, куда отправляют документы, относящиеся в том числе к категории «Коммерческая тайна» (КТ). Сотрудников, проходящих испытательный срок, туда не включают.

Как-то раз в рассылку по ошибке добавляют не e.ivanov@lutik.ru, а e.ivanova@lutik.ru. Евдокия, чувствуя, что не пройдет испытательный срок, планирует забрать с собой все накопленные материалы из рассылки и тем самым спровоцировать серьёзную утечку.

Евдокия пытается выгрузить в облако документы, попытки блокируются DLP-системой, после чего ее переводят в особую группу контроля. В частности, она используется в политике webProxy для запрета доступа к OWA с домашнего ПК. Таким образом, без взаимодействия с другими подразделениями планам Евдокии не суждено сбыться – все каналы, по которым мог произойти слив информации, заблокированы. Синхронизация досье сотрудников – одна из ключевых особенностей использования комплекса продуктов Solar Dozor и Solar webProxy.

3. Аутентификация публикуемых веб-приложений

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

Это очень помогло, когда одному из заказчиков – назовем его для удобства «Промстройлаб» – потребовалось опубликовать внутреннее приложение, где вход был широко доступен без ввода логина и пароля. Очевидно, что предоставлять пользователям доступ к внешнему веб-приложению, в котором аутентификация не предусмотрена, – не самая хорошая идея. Контролировать трафик и анализировать источник нарушений для «Промстройлаб» будет невозможно. Благодаря тому, что обратный прокси встает между сервером и пользователем, для чего принудительно запрашивает логин и пароль пользователей, трафик привязывается к конкретным сотрудникам и проблема решается средствами обратного прокси-сервера.

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

4. Контроль Share Point

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

DLP или не DLP: вот в чем вопрос

Функциональные возможности Solar webProxy доступны и тем, у кого DLP Solar Dozor, и тем, у кого нет DLP.

  • DLP

Для интеграции с DLP-системой в соответствии с документацией настраивается пересылка по протоколу ICAP. Происходит это в несколько простых шагов.


Иллюстрация 3: Настройка публикации ресурса OWA


Иллюстрация 4: Настройка политики безопасности

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

При интеграции с DLP-системой администратор безопасности может увидеть полное движение документов (вне зависимости от того, были ли они отправлены адресату или скачаны через черновик).

В экосистеме Центра продуктов Dozor (Solar Dozor, Solar webProxy и др.) применяются общие механизмы, которые упрощают взаимодействие заказчика с этими системами. С Solar Dozor возможна глубокая интеграция за счет синхронизации с модулем общего расширенного досье для продвинутой аналитики персон Dozor Dossier. Это позволяет осуществлять более комплексные меры противодействия, чем блокирование отправки конфиденциального файла. Например, если по политике Solar Dozor зафиксирует нарушение, эта информация может быть использована для полной блокировки доступа в интернет в режиме реального времени.

  • Нет DLP

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

А можно все посмотреть?

Для объективной картины — задачи контроля веб-ресурсов, опубликованных снаружи, могут решаться разными способами.

1. Бесплатный прокси-сервер с поддержкой обратного режима

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

2. Web Application Firewall (WAF)

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

Конечно, будет несправедливо не упомянуть другие коммерческие решения с функционалом обратного прокси (UTM/SWG). Однако как показало наше исследование рынка, в них отсутствует интеграция по протоколу ICAP. А это лишает возможности интегрировать прокси-решение с DLP-системой.

Выводы

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

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

Чтобы оценить объем трафика, утекающего через неконтролируемые DLP-решением каналы, установите демоверсию Solar webProxy.

Ваша приватность умирает красиво, но мы можем спасти её.

Присоединяйтесь к нам!