До 40% проектов по внедрению DLP заканчиваются имитацией защиты, когда система работает, но не ловит реальные утечки из-за некорректных политик. Приемка проекта не может основываться на фразе «все работает» — только на жестких метриках False Positive и True Positive.
Метрики качества срабатываний: FP и FN
Главный показатель эффективности интегратора — соотношение ложноположительных (False Positive, FP) и ложноотрицательных (False Negative, FN) срабатываний. В идеале уровень FP не должен превышать 15-20% от общего объема инцидентов после этапа тонкой настройки. Если на 1 реальную утечку аналитик получает 50 «шумов», система становится бесполезной, а отдел ИБ перегружается.
Кейс: В компании на 500 рабочих станций интегратор настроил поиск по ключевым словам «Секретно» и «Конфиденциально». Итог — 2000 уведомлений в день при 0 реальных инцидентов. Профессиональный подход предполагает использование цифровых отпечатков (fingerprinting) и регулярных выражений с проверкой контрольных сумм, что снижает FP до 5-10%.
Экспертный вывод: Принимайте работу только после тестового периода (2-4 недели), когда кривая FP пошла на спад, а не в первый день запуска.
Покрытие векторов утечек и охват сети
Эффективность определяется процентом перекрытых каналов передачи данных. Стандартный пакет внедрения должен закрывать минимум 80% критических путей: HTTP/HTTPS (включая веб-почту и мессенджеры), SMTP, USB, печать и облачные хранилища. Если интегратор проигнорировал SSL-инспекцию (расшифровку трафика), вы теряете до 70% видимости, так как почти весь современный трафик зашифрован.
Пример: Подрядчик развернул агентскую часть на 90% ПК, но забыл про терминальные серверы и Linux-станции разработчиков. В результате возникла «дыра» в безопасности самого критичного сегмента. Норма охвата рабочих мест в корпоративном секторе — 98-100%.
Экспертный вывод: Требуйте карту потоков данных (Data Flow Diagram) и сверяйте её с фактически настроенными политиками контроля.
Производительность системы и влияние на бизнес
DLP не должна «вешать» компьютеры пользователей. Критическим показателем является загрузка CPU агентом: в режиме простоя — не более 1-2%, при активном сканировании файлов — не более 10-15%. Если пользователи жалуются на тормоза системы, это значит, что интегратор неправильно настроил исключения для тяжелых приложений (например, CAD-систем или IDE).
Цифры: В проектах на 1000+ пользователей задержка при отправке письма из-за анализа DLP не должна превышать 2-3 секунды. Превышение этого порога ведет к массовым жалобам в IT-отдел и попыткам сотрудников саботировать систему.
Экспертный вывод: Включайте в KPI задержку отклика системы (latency) и нагрузку на endpoint-устройства.
Сроки развертывания и стоимость этапов
Реальные сроки развертывания DLP для сети в 500-1000 узлов составляют от 3 до 6 месяцев. Попытка сократить этот срок до 1 месяца обычно приводит к тому, что этап «настройки политик» пропускается, и вы получаете «пустую коробку». Сравнение стоимости услуг по внедрению DLP показывает, что настройка правил и контента занимает до 40-50% общего бюджета проекта.
Кейс: Компания выбрала дешевого подрядчика, который пообещал запуск за 2 недели. В итоге через месяц выяснилось, что политики настроены поверхностно, а база словарей не адаптирована под отраслевой сленг компании, что сделало систему слепой к специфическим утечкам.
Экспертный вывод: Избегайте аномально коротких сроков; качественный тюнинг политик требует итерационного подхода: внедрение — анализ — корректировка.
Вывод
Чтобы внедрение DLP не стало дорогой игрушкой, переходите от оценки «наличия софта» к оценке «качества детектирования». Начинайте с жесткого ТЗ, где прописаны допустимый процент FP (<20%) и обязательный охват SSL-трафика. Избегайте подрядчиков, которые предлагают фиксированные сроки без этапа пилота и калибровки правил. Лучший выбор — интегратор, который готов зафиксировать в SLA показатели точности срабатываний и производительность агентов, а не просто факт установки ПО.