Заставьте вашу DLP-систему работать

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

Основные проблемы

Основной причиной возникновения проблем с DLP являются завышенные ожидания, базирующиеся на не совсем верном с точки зрения «чистого» консалтинга подходе. Этот подход предполагает, что выстраивание процессов вокруг внедренной DLP должно происходить постфактум. Наш опыт говорит об обратном: для эффективного функционирования DLP должна «выстраиваться» (внедряться) вокруг уже существующих процессов ИБ, а не наоборот. Иными словами, чтобы эффективно использовать DLP, компания должна обладать хотя бы начальным уровнем зрелости ИБ, «дорасти» до системы.

Приведем главные риски, сопутствующие процессу внедрения DLP:

• В системе DLP будут реализованы только шаблонные, не отражающие специфику бизнес-процессов правила

Согласно принципу сервисного подхода, бизнес-подразделения компании являются «клиентами» службы ИБ, которая оказывает им различные сервисы (услуги), например, защиту от утечек. К сожалению, знание своего бизнеса является слабым местом многих ИБ-служб в России. Ситуация с DLP усугубляется тем, что понимание бизнеса должно быть не просто на уровне бизнес-процессов и потоков данных, а еще глубже – на уровне конкретных информационных активов.

• Система DLP «by design» покрывает не все актуальные каналы утечки информации

Хрестоматийная ситуация – установка безагентского DLP и одновременное отсутствие контроля съемных носителей. Да, такая DLP позволит выявить сотрудника, который отправил себе на личную почту документы, чтобы поработать дома, да, система может помочь выявить тех, кто бездельничает (чатится, серфит в интернете и т.д.) на рабочем месте, но предотвратит/отследит ли она злонамеренный слив информации? Скорее всего, нет.

• Реализованные политики будут порождать большое количество ложных срабатываний, которые будет невозможно обработать за разумное время

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

• DLP не предотвращает утечку информации

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

• Выстраивание процесса вокруг DLP может негативно сказаться на самом процессе

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

Итак, что делать, если процессная составляющая отсутствует (по ряду причин: исторически унаследованная система, смена руководства, участие компании в M&A сделках, уход из компании ключевых ИБ-специалистов и т.д.), а DLP уже есть? Решение кроется в методологически верной реализации процессного подхода, учитывающего специфику DLP как средства защиты. Когда речь идет об организации процессного подхода, первое, что приходит на ум, – это классическая модель PDCA (Plan-Do-Check-Act) (см. рис. 1).

Рис. 1. Классическая модель PDCA

В случае с DLP эта модель оказывается наиболее подходящей. Как мы действуем:

• Планируем. Определяем цели системы, какую информацию будем защищать и как.
• Делаем. Реализуем политики DLP.
• Проверяем. Эксплуатируем систему, анализируем получаемые результаты (количество событий и реальных инцидентов, процент ошибок первого и второго рода, результаты тестов, технические показатели).
• Корректируем. Изменяем политики с учетом результатов анализа.
• Планируем. Новый цикл планирования. Учитываем изменившиеся цели, актуализируем информацию, применяем новые подходы. и т.д.

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

Планируем

Честное определение цели DLP

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

• Кто основные пользователи DLP, кто планирует пользоваться данными системы (служба ИБ/ЭБ/внутреннего контроля, непосредственно менеджмент и т.д.)?
• Каковы ожидания основных пользователей от применения DLP в ближайшей перспективе (1–3 года)?
• Каковы ожидания руководства компании от использования DLP в перспективе 1–3 лет, хочет ли руководство получать регулярную статистику, если да, то в каком виде?
• Существуют ли нетиповые внешние требования к компании относительно процесса защиты от утечек информации (например, требования материнских компаний)?

Что конкретно будем защищать

Мы определились с приоритетом, поехали дальше. Следующая потенциальная проблема: как перейти от абстрактных понятий вроде «информация ограниченного доступа» или «информация о топах» к конкретным информационным активам, то есть как опуститься на уровень конкретных документов, передаваемых между конкретными людьми? Это можно сделать с помощью классического анализа бизнес-процессов, в основе которого лежат инвентаризация и категоризация информационных активов. Это самая важная и сложная задача, которая, по сути, представляет собой отдельный проект по ИБ.

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

Самый главный вклад, который вносит режим применительно к настройке DLP, – преобразование абстрактного понятия «информация ограниченного доступа» в набор вполне конкретных и осязаемых документов. Работая с ними, можно выделять их типовые признаки: формат сообщения, гриф, формат учетного номера, иные особенности оформления, типовые фразы/преамбулы/титульные листы, стандартизированные формы документов и т.д. Другая важная особенность: можно осуществлять более «гранулированный» контроль сотрудников за счет их поименного или подолжностного допуска к коммерческой тайне.

Реальные утечки

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

Делаем

Тонкая настройка DLP

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

• контроль информации ограниченного доступа по ее конкретным выявленным признакам;
• контроль информации ограниченного доступа с помощью признаков типовых документов, одинаковых у всех компаний отрасли;
• контроль информации ограниченного доступа с помощью правил, косвенно позволяющих выявлять инциденты ИБ/аномальное поведение сотрудников.

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

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

Контролируем

Рис. 2. Составляющие системы защиты от утечек

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

В общем случае DLP связана со следующими ИБ-процессами:

• внутренние коммуникации между службой ИБ и руководством;
• управление рисками ИБ;
• управление доступом к информационным ресурсам;
• регистрация и мониторинг событий ИБ;
• управление инцидентами ИБ;
• повышение осведомленности сотрудников;
• моделирование угроз и нарушителей.

Анализируя эффективность этих процессов, можно сделать вывод об эффективности самой DLP и наметить пути дальнейшей модернизации политик.

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

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

Корректируем

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

• корректировке имеющихся правил;
• разработке новых правил;
• изменениях ОРД по процессам ИБ;
• выделении дополнительных человеческих ресурсов;
• технической модернизации системы.

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

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

Итак, не надо ставить телегу вперед кобылы. Система DLP может стать отличным помощником в решении огромного количества задач, однако её настройка и развитие – это не самоцель, DLP всего лишь инструмент, безусловно, полезный, но не единственный.

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