Вторая жизнь для DLP

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

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

В чем же заключаются главные риски, сопутствующие процессу внедрения DLP?

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

Другой риск – система DLP "by design" покроет не все актуальные каналы утечки информации. Живой пример – установка безагентского DLP и отсутствие контроля съемных носителей. Подобная система может выявить сотрудника, отправившего себе на личную почту документы, чтобы поработать дома; или тех, кто бездельничает на рабочем месте, но, скорее всего, не сможет предотвратить или отследить злонамеренный слив информации.

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

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

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

Что же делать, если DLP в компании уже есть, а процессная составляющая отсутствует?

Решение есть. И оно в методологически верной реализации процессного подхода, учитывающего специфику DLP как средства защиты.

Если речь идет об организации процессного подхода, то наиболее подходящей моделью является классическая модель PDCA (Plan-Do-Check-Act):

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

Все просто? Но есть нюансы.

Планировать

Первые сложности на этом этапе могут возникнуть при попытке ответить на вопрос, а зачем нам DLP. Система может "все и сразу". Но стоит все же приоритизировать задачи.

Чтобы определить, а что же все-таки нужно от DLP, достаточно ответить на ряд вопросов:

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

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

Тема, созвучная с процессом контроля утечек, – выстраивание режима коммерческой тайны. Этот режим существенно облегчает проведение анализа бизнес-процессов и инвентаризации информации. Применительно к настройке DLP он помогает преобразовать абстрактное понятие "информация ограниченного доступа" в набор вполне конкретных и осязаемых документов. Работая с ними, можно выделять их типовые признаки: формат сообщения, гриф, формат учетного номера, иные особенности оформления, типовые фразы/преамбулы/титульные листы, стандартизированные формы документов и т.д. Также можно осуществлять более "гранулированный" контроль сотрудников за счет их поименного или подолжностного допуска к коммерческой тайне.

Делать

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

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

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

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

Контролировать

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

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

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

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

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

Корректировать

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

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