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

Файл открыли. Внутри действительно была инструкция, как выстроить схему получения денег от поставщиков. СБ проверила сотрудника и подтвердила: менеджер уже брал откаты.

Его уволили. Внутри компании отдельно объяснили, что решение принято не по одному сигналу системы. Расследование подтвердило действующую коррупционную схему. Позже были и более крупные эпизоды, по которым материалы передавали в полицию.

Руководство утвердило масштабирование DLP до формального окончания пилота. После такого инцидента вопрос звучал уже не «существует ли риск», а «сколько похожих случаев компания пока не видит».

Я запускал DLP-проекты на нескольких крупных российских платформах. Названия компаний, вендоров и детали защищенных контуров раскрывать не могу. Масштаб пилотов составлял от 100 до 300 рабочих мест.

Первые недели система только наблюдала

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

На рабочих местах использовали endpoint-компоненты. На сетевом периметре контролировали в том числе зашифрованный HTTPS/TLS-трафик через SSL inspection. Это позволяло видеть передачу данных до шифрования на конечной станции или после расшифровки на шлюзе.

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

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

Базовая защита к этому моменту уже существовала. USB-носители ограничивали, сетевые контуры разделяли, права к папкам и системам выдавали по ролям. Сотрудники подписывали положения о коммерческой тайне.

Такая модель показывала, кто может открыть документ. Но не показывала, что с ним делают после открытия.

Однажды собственник спросил службу безопасности, почему на следующее утро после ежемесячного совещания знакомые уже присылают ему скриншоты P&L и обсуждают цифры.

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

У сотрудника оставалось право открыть отчет. Публиковать его он уже не должен был. Обычная проверка доступов такой разрыв не показывала.

За первые недели пилота мы получили карту реального движения информации. После этого директор по безопасности, CFO, COO, CCO и CEO определили, какие данные компания будет защищать в первую очередь: финансовые отчеты, договоры поставки, закупочные условия, сведения об остатках и себестоимости, другие документы, влияющие на деньги и переговорную позицию компании.

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

Пилот и стабилизация первой рабочей версии занимали около трех месяцев. В отдельных проектах - до шести. За это время команда убирала повторяющийся шум, оформляла легитимные исключения и разбирала операции, которые система не могла однозначно классифицировать.

Точных данных о доле ложных срабатываний у меня сейчас не сохранилось. Поэтому я не буду придумывать false positive rate ради технической убедительности. Практический показатель был проще: правила должны были перестать мешать регулярным операциям, а специалист СБ - успевать разбирать значимые события, не утопая в повторяющемся потоке.

Один сигнал - разные причины

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

В другом эпизоде директор магазина решил поделиться опытом с директором конкурирующей точки в том же торговом центре. Он показал структуру отчетов, затем попытался удалить чувствительные данные и отправить шаблоны. Удалил не все. Система заблокировала отправку.

Был и случай с обычной просьбой о помощи. У специалиста поддержки был разрешен USB. Коллега прислал ему Excel и попросил записать на флешку: якобы сделал таблицу для ребенка, а со своего компьютера перенести ее не мог. При записи DLP обнаружила внутри P&L и остановила операцию.

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

Поэтому процесс разделили. Оператор DLP фиксировал событие и собирал первичную фактуру. СБ расследовала контекст. Решение принимал директор по безопасности вместе с владельцем соответствующего процесса. Тот, кто увидел сигнал, не имел права сразу назвать сотрудника виновным.

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

Как мы сами создали обходной путь

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

Система не могла проверить содержимое и блокировала отправку. Но сотрудник не получал уведомления. Он считал, что файл ушел, адресат ждал, затем начинались повторные отправки, звонки и попытки использовать другой канал.

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

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

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

На пилоте работали один сотрудник ИТ и один специалист СБ. Для промышленной эксплуатации состав команды зависел от масштаба и потока событий. Но оставлять весь контур на одном человеке нельзя: отпуск или увольнение сразу превращают срабатывания в неразобранную очередь.

Что сказать сотрудникам

Сотрудникам прямо сообщили, что DLP контролирует движение информации на корпоративном оборудовании. Объяснили, какие рабочие каналы входят в периметр и что происходит после сигнала.

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

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

Доступ к событиям ограничивали. Специалисты DLP могут видеть документы, адресатов, фрагменты переписки и историю действий. Материалы расследований получали только сотрудники СБ, которым они требовались для проверки.

Как считать экономику до инцидента

После обнаружения схемы с откатами масштабирование утвердили до окончания пилота. Руководство увидело подтвержденное мошенничество и работающий способ его обнаружения.

В других проектах экономику собирали итерациями. Вместе с собственником и владельцами рисков определяли возможные сценарии, оценивали последствия и согласовывали допущения по вероятности до и после внедрения.

В таких случаях считали ROSI - Return on Security Investment:

ROSI = (снижение ожидаемого ущерба - TCO решения) / TCO решения.

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

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

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

Чтобы вернуть 57 млн рублей:

  • за два года проект должен снижать ожидаемый ущерб минимум на 28,5 млн рублей в год;
  • за полтора года - минимум на 38 млн рублей;
  • за один год - минимум на 57 млн рублей.

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

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

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

Что дала DLP

В одном из проектов около года по контролируемым каналам не регистрировали утечек. Во внутренней отчетности защищенность контура оценивалась в 99,9%.

Это была внутренняя метрика зрелости контролируемого контура, а не вероятность утечки. Точная формула сейчас не сохранилась. Сегодня я не стал бы защищать такой показатель перед советом директоров без знаменателя.

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

Внедрить DLP можно за несколько недель. Настроить ее так, чтобы она не мешала бизнесу и находила реальные угрозы, занимает месяцы.

На защите такого проекта я бы показывал собственнику не количество установленных агентов и не число собранных событий. Я бы показывал четыре ответа:

  • какие данные пытались передать;
  • имел ли сотрудник на это право;
  • почему действующий процесс позволил это сделать;
  • сколько стоит закрыть найденный канал.

Именно эти ответы доказывают, что компания управляет риском, а не просто купила DLP.