Pages - Menu

Страницы

28.5.13

К черту контент, важен контекст!

После того, как в 21-м приказе ФСТЭК появилась мера по контролю утечек персональных данных (аналогичная мера по конфиденциальной информации будет и в 17-м приказе), а Банк России в Магнитогорске заявил о проработке вопроса о создании отдельного документа по DLP с банковской спецификой тема контроля утечек вновь стала более чем актуальной. Кто-то стал разрабатывать новые решения по части DLP, кто-то стал в очередной раз пиарить свой продукт. Вообще я уже не раз проходился по этой тематике, но хочу в очередной раз потроллить тему ;-) Да и на PHD III рассказывали как обойти современные DLP. Как будто это настолько распространенный продукт, что он стал стандартом де-факто в корпоративной среде.

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


Что это? Буква "В" русского алфавита? Буква "B" английского алфавита? Несчастливое число "13"? А вот фиг его знает. Мы не знаем. Да и DLP тоже не знает. Если не рассматривать анализ графических файлов и опять ограничить область распространения голым текстом, то максимум, что DLP может определить, что это символ какого-то алфавита или число.. 
Так и в более сложных случаях. Допустим мы встречаем в тексте набор "ключевых" фраз - "месторождение", "объем запасов", "миллион кубометров". По всем параметрам это утечка информации. А оказывается, что кто-то просто переслал рекламную листовку с соответствующими текстовыми вкраплениями. А все потому, что мы контролировали контент, забывая про контекст.
Я привел немного упрощенный пример, который просто показывает, что современные средства защиты (и не только DLP) уже давно устарели в своем желании контролировать адреса и направлении взаимодействия. И в желании контролировать контент они тоже устарели - сегодня этого не хватает. Нужно контролировать контекст. Под контекстом я понимаю не только ответ на вопрос «ЧТО можно», т.е. анализ трафика на сетевом и прикладном уровне, но и ответы на вопрос «КОГДА можно» (привязка ко времени попытки доступа), «КУДА и ОТКУДА можно» (куда и откуда осуществляется доступ), «КОМУ можно» (привязка не только к IP-адресу, но и к учетной записи пользователя), «КАК можно» (с какого устройства можно осуществлять доступ – с личного или с корпоративного, со стационарного или с мобильного). Все это позволяет более гибко выстраивать политики доступа и учитывать постоянно изменяющиеся потребности современного предприятия с точки зрения информационной безопасности.


Не могу сказать, что мысль нова. Но в последнее время становится все более понятно, что по другому (по старинке) выстраивать систему защиты уже неправильно. Она перестает выполнять стоящие перед ней задачи, а точнее выполняет их процентов на 20-30. Вот, например, что может сделать обычная система анализа сетевого трафика:
 

Ничего сверхестественного. Ну видим, что с определенных адресов уходит большой объем данных, на порядок превышающий установленные лимиты. Но в среде с динамической адресацией, это ничего и никому ни о чем не говорит. А если добавить контекст?


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


Тут вам и беспроводной и проводной доступ, доступ с личных (BYOD) и корпоративных устройств, доступ со станционарных и мобильных устройств, доступ с устройств, за которыми пользователь аутентифицируется и за которыми он не работает (IP-телефон или игровая приставка), пользователи, которые прошли оценку соответствия и которых дополнительно аутентифицируют по сертификатам... Очень гибкая схема, отличающаяся от стандартной "пользователю ivanov111 можно получить доступ к IP-адресу 10.10.10.10".

Думаю, что за такими системами будущее.

12 комментариев:

  1. Кстати многие DLP тоже поддерживают контекст.

    Но было бы ещё отлично объеденить контекст и контент
    Чтобы правила "ЧТО можно" содержало не IPадрес назначения, а содержимое или приложение

    А ещё хорошо бы чтобы больше сервисов поддерживало такие политики. В том числе чтобы DLP поддерживало такие политики (интеграция DLP и ISE). А то сейчас таких сервисов негусто

    ОтветитьУдалить
  2. А если сообощение эл. почты зашифровано на прикладном уровне? Зачем тогда DLP? Или уже имеются DLP, которые любые шифры вскрывают?

    ОтветитьУдалить
  3. Вообще, в свое время у Perimetrix была хорошая задумка в этом направлении - жаль не осилили.

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

    2 Target
    такие сообщения можно сразу не пропускать, например.

    ОтветитьУдалить
  4. Антон, у Cisco да. Но я специально продукты не упоминал, говоря о тенденции

    ОтветитьУдалить
  5. 2 Алексей

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

    ОтветитьУдалить
  6. Права была Наталья Касперская, что выиграют те DLP, которые будут не сами по себе, но внутри других решений. Скорее всего прикладных. Корпоративные заказчики со временем вполне сообразят, хотя многие настоящие CIO это уже давно вполне понимают, и из данного поста видно, что управлять информацией нужно не отвлеченно, а внутри бизнес-процесса и средств его автоматизации. Это впрямую означает "ограничения на свободу", в т.ч. выбора конечных устройств и их софта. И такие DLP есть, их никто не афиширует и так не называет, понимая, что это одно из важных преимуществ более крупного коммерческого продукта, одна из поддерживаемых им функций.
    DLP в нынешнем виде выглядит как волшебная пилюля с недоказанной эффективностью. В этот сегмент лезут все, кому не лень. Задача этой пилюли как многим кажется - поддерживать максимальную свободу и удобства при минимуме телодвижений в условиях зоопарка. Но это незрелый подход, детский можно сказать.

    ОтветитьУдалить
  7. Doom, контекстная модель применима к защите и контролю всех активов, включася сисиемы. DRM ориентирована только на информацию. Хотя я не исключаю комбинации этих моделей

    ОтветитьУдалить
  8. В частности, далеко ходить не надо: Exchange 2013 при покупке клиентских лицензий Exchange Enterprise CAL имеет функционал DLP. Причем заявляется, что разработан он в соответствии с PCI.
    Информация здесь.

    ОтветитьУдалить
  9. 2 Сергей Городилов

    Да не ведитесь вы на этот маркетинг!
    Если DLP говорит нам, что у них забиты политики PCI Compliance, то это значит, что там есть regexp вида "[0-9]{16}", если говорят про HIPPA, то соответствующий регэксп для номера социального страхования и т.п.

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

    ОтветитьУдалить
  10. а где там "мера по контролю утечек персональных данных" ? слово утечка в 21 упоминается 1 раз в контексте ТКУИ от коих DLP не спасает

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.