После того, как в 21-м приказе ФСТЭК появилась мера по контролю утечек персональных данных (аналогичная мера по конфиденциальной информации будет и в 17-м приказе), а Банк России в Магнитогорске заявил о проработке вопроса о создании отдельного документа по DLP с банковской спецификой тема контроля утечек вновь стала более чем актуальной. Кто-то стал разрабатывать новые решения по части DLP, кто-то стал в очередной раз пиарить свой продукт. Вообще я уже не раз проходился по этой тематике, но хочу в очередной раз потроллить тему ;-) Да и на PHD III рассказывали как обойти современные DLP. Как будто это настолько распространенный продукт, что он стал стандартом де-факто в корпоративной среде.
Давайте сразу исключим из области рассмотрения задачу контроля голосового и видео трафика. Допустим, что у нас никакая конфиденциальная информация по этим каналам не передается. И ActiveSync нам контролировать не надо. И в базах данных у нас нет критичных данных. Будем тупо контролировать утечки в почте, в файлах, при печати. Т.е. то, что умеют делать большинство продуктов. Представим, что в контролируемом трафике мы встречаем нечто похожее на:
Так и в более сложных случаях. Допустим мы встречаем в тексте набор "ключевых" фраз - "месторождение", "объем запасов", "миллион кубометров". По всем параметрам это утечка информации. А оказывается, что кто-то просто переслал рекламную листовку с соответствующими текстовыми вкраплениями. А все потому, что мы контролировали контент, забывая про контекст.Давайте сразу исключим из области рассмотрения задачу контроля голосового и видео трафика. Допустим, что у нас никакая конфиденциальная информация по этим каналам не передается. И ActiveSync нам контролировать не надо. И в базах данных у нас нет критичных данных. Будем тупо контролировать утечки в почте, в файлах, при печати. Т.е. то, что умеют делать большинство продуктов. Представим, что в контролируемом трафике мы встречаем нечто похожее на:
Что это? Буква "В" русского алфавита? Буква "B" английского алфавита? Несчастливое число "13"? А вот фиг его знает. Мы не знаем. Да и DLP тоже не знает. Если не рассматривать анализ графических файлов и опять ограничить область распространения голым текстом, то максимум, что DLP может определить, что это символ какого-то алфавита или число..
Я привел немного упрощенный пример, который просто показывает, что современные средства защиты (и не только DLP) уже давно устарели в своем желании контролировать адреса и направлении взаимодействия. И в желании контролировать контент они тоже устарели - сегодня этого не хватает. Нужно контролировать контекст. Под контекстом я понимаю не только ответ на вопрос «ЧТО можно», т.е. анализ трафика на сетевом и прикладном уровне, но и ответы на вопрос «КОГДА можно» (привязка ко времени попытки доступа), «КУДА и ОТКУДА можно» (куда и откуда осуществляется доступ), «КОМУ можно» (привязка не только к IP-адресу, но и к учетной записи пользователя), «КАК можно» (с какого устройства можно осуществлять доступ – с личного или с корпоративного, со стационарного или с мобильного). Все это позволяет более гибко выстраивать политики доступа и учитывать постоянно изменяющиеся потребности современного предприятия с точки зрения информационной безопасности.
Не могу сказать, что мысль нова. Но в последнее время становится все более понятно, что по другому (по старинке) выстраивать систему защиты уже неправильно. Она перестает выполнять стоящие перед ней задачи, а точнее выполняет их процентов на 20-30. Вот, например, что может сделать обычная система анализа сетевого трафика:
Ничего сверхестественного. Ну видим, что с определенных адресов уходит большой объем данных, на порядок превышающий установленные лимиты. Но в среде с динамической адресацией, это ничего и никому ни о чем не говорит. А если добавить контекст?
Картина уже иная. Мы смогли привязать информацию к пользователю и даже его устройству. С учетом же контекста мы можем не только что-то мониторить и отслеживать, но и писать политики, которые будут реализовываться. Например, вот так может выглядеть политика доступа к внутренним ресурсам организации:
Тут вам и беспроводной и проводной доступ, доступ с личных (BYOD) и корпоративных устройств, доступ со станционарных и мобильных устройств, доступ с устройств, за которыми пользователь аутентифицируется и за которыми он не работает (IP-телефон или игровая приставка), пользователи, которые прошли оценку соответствия и которых дополнительно аутентифицируют по сертификатам... Очень гибкая схема, отличающаяся от стандартной "пользователю ivanov111 можно получить доступ к IP-адресу 10.10.10.10".
Думаю, что за такими системами будущее.
Cisco ISE?
ОтветитьУдалитьКстати многие DLP тоже поддерживают контекст.
ОтветитьУдалитьНо было бы ещё отлично объеденить контекст и контент
Чтобы правила "ЧТО можно" содержало не IPадрес назначения, а содержимое или приложение
А ещё хорошо бы чтобы больше сервисов поддерживало такие политики. В том числе чтобы DLP поддерживало такие политики (интеграция DLP и ISE). А то сейчас таких сервисов негусто
А если сообощение эл. почты зашифровано на прикладном уровне? Зачем тогда DLP? Или уже имеются DLP, которые любые шифры вскрывают?
ОтветитьУдалитьВообще, в свое время у Perimetrix была хорошая задумка в этом направлении - жаль не осилили.
ОтветитьУдалитьНу и в целом современные DLP не так плохи с технической точки зрения, сложно одно - построить эту самую политику и сопровождать ее. Вот в этом направлении надо работать - разрабатывать методики, инструменты и т.п.
2 Target
такие сообщения можно сразу не пропускать, например.
Антон, у Cisco да. Но я специально продукты не упоминал, говоря о тенденции
ОтветитьУдалить2 Алексей
ОтветитьУдалитьОднако, если говорить о тенденциях, то непонятно почему должна победить такая модель, а не DRM, к примеру. Тот же RMS позволяет задать достаточно гибкую политику использования информации, которая распространяется даже за пределы организации.
Права была Наталья Касперская, что выиграют те DLP, которые будут не сами по себе, но внутри других решений. Скорее всего прикладных. Корпоративные заказчики со временем вполне сообразят, хотя многие настоящие CIO это уже давно вполне понимают, и из данного поста видно, что управлять информацией нужно не отвлеченно, а внутри бизнес-процесса и средств его автоматизации. Это впрямую означает "ограничения на свободу", в т.ч. выбора конечных устройств и их софта. И такие DLP есть, их никто не афиширует и так не называет, понимая, что это одно из важных преимуществ более крупного коммерческого продукта, одна из поддерживаемых им функций.
ОтветитьУдалитьDLP в нынешнем виде выглядит как волшебная пилюля с недоказанной эффективностью. В этот сегмент лезут все, кому не лень. Задача этой пилюли как многим кажется - поддерживать максимальную свободу и удобства при минимуме телодвижений в условиях зоопарка. Но это незрелый подход, детский можно сказать.
Doom, контекстная модель применима к защите и контролю всех активов, включася сисиемы. DRM ориентирована только на информацию. Хотя я не исключаю комбинации этих моделей
ОтветитьУдалитьВ частности, далеко ходить не надо: Exchange 2013 при покупке клиентских лицензий Exchange Enterprise CAL имеет функционал DLP. Причем заявляется, что разработан он в соответствии с PCI.
ОтветитьУдалитьИнформация здесь.
2 Сергей Городилов
ОтветитьУдалитьДа не ведитесь вы на этот маркетинг!
Если DLP говорит нам, что у них забиты политики PCI Compliance, то это значит, что там есть regexp вида "[0-9]{16}", если говорят про HIPPA, то соответствующий регэксп для номера социального страхования и т.п.
Вообще, "готовые политики DLP" - это самый настоящий миф. Их не существует. Более того, ни один вендор до сих пор не предложил нормальной методики построения этой политики. Все вендорские документы посвящены вопросу встраивания DLP шлюза в существующую ИТ инфраструктуру (будто это так сложно, ей-богу).
а где там "мера по контролю утечек персональных данных" ? слово утечка в 21 упоминается 1 раз в контексте ТКУИ от коих DLP не спасает
ОтветитьУдалитьОЦЛ.5
ОтветитьУдалить