Мониторинг даркнета не означает «видеть всё»: как компании превращать признаки утечки в действия
Ценность мониторинга даркнета — не в обещании видеть всё, а в возможности как можно раньше обнаружить признаки утечки, затрагивающей компанию, проверить их, определить приоритет и передать тем командам, которые действительно могут снизить ущерб.
Обычно компании хотят узнать не то, «насколько загадочен даркнет», а нечто гораздо более практичное: если учётные данные сотрудников, данные клиентов или внутренние документы уже открыто выставлены на продажу, сможет ли компания узнать об этом до того, как проблема разрастётся?
Мониторинг даркнета помогает находить зацепки, но не даёт возможности увидеть все риски. Надёжный подход — сопоставлять сведения из открытых источников или специализированных каналов с собственным перечнем активов компании и связывать их с процедурами реагирования на инциденты, проверяя каждое обнаруженное свидетельство.
Что такое даркнет и почему компаниям стоит обращать на него внимание
Под даркнетом обычно понимают часть сетевых сервисов, для доступа к которым нужны специальное программное обеспечение или особые настройки. Среди них есть форумы, торговые площадки и закрытые сообщества. Там могут появляться похищенные учётные данные, услуги по предоставлению вредоносного ПО, корпоративные документы или обсуждения злоумышленниками возможных объектов атак. При этом многие утечки впервые обнаруживаются на обычных сайтах, в репозиториях кода, группах в мессенджерах или каналах перепродажи данных. Если сосредоточиться только на слове «даркнет», можно упустить более ранние и более надёжные сигналы.
Первый вопрос мониторинга: что нужно защищать
Компания может начать с перечня объектов, действительно связанных с её деятельностью: корпоративных доменов и поддоменов, точек входа в системы для сотрудников и клиентов, названий брендов, почтовых доменов, ключей API, названий облачных сервисов, а также документов и кодовых названий проектов, которые не должны становиться общедоступными. Без такого перечня инструменты мониторинга легко выдают массу постороннего информационного шума.
Затем следует задать несколько чётких условий срабатывания: обнаружены учётные данные, принадлежность которых компании подтверждена; появилась новая учётная запись с высокими привилегиями; найдены фрагменты внутренних документов; ведётся обсуждение атаки на конкретную систему; обнаружены образцы, соответствующие известному инциденту. Чем конкретнее условия, тем легче команде безопасности определить следующий шаг.
Между зацепкой и выводом обязательно должна быть проверка
Публикация, скриншот или архив, который якобы содержит данные, — это лишь зацепки. Команде необходимо проверить время, источник, формат данных, наличие в них реальных полей и то, остаются ли эти сведения актуальными. Многократные перепубликации могут выглядеть как несколько инцидентов, хотя на деле это повторное распространение одного старого материала. И наоборот: даже неприметный образец учётных данных может быть достаточным основанием для немедленной смены паролей и токенов.
Сервис мониторинга может собирать сведения и отправлять уведомления, но он не заменяет компанию в решении вопросов о том, реален ли инцидент, какие системы затронуты и кто уполномочен действовать. Разделение «обнаружения» и «подтверждения» помогает сократить число ложных тревог и избежать поспешной блокировки обычных пользователей из-за одного непроверенного сообщения.
Действительно полезный процесс: обнаружить, подтвердить, отреагировать, разобрать результаты
Обнаружить: постоянно собирать сведения, связанные с активами компании, и фиксировать время и источник их первого появления.
Подтвердить: поручить специалистам по безопасности или ответственным за системы проверить образцы и определить, какие учётные записи, системы или данные затронуты.
Отреагировать: сменить учётные данные, изолировать затронутые системы, уведомить тех, кто должен принять меры, и сохранить записи, позволяющие проследить ход реагирования.
Разобрать результаты: выяснить, почему существующие средства контроля не обнаружили проблему вовремя, и скорректировать перечень активов, права доступа, журналирование и правила оповещения.
Как это связано с системными вопросами, которые обсуждает Лу Хэн
В своих Notes Лу Хэн неоднократно напоминает читателям, что нужно различать обозначения, записи и реальные возможности системы. У мониторинга даркнета есть та же граница: оценка риска или уведомление об «обнаружении» не равнозначны самому факту. Централизованный инструмент может предоставлять услугу, но это ещё не даёт ему права принимать за компанию все решения.
Поэтому хорошее решение для мониторинга должно помогать компании видеть зависимости, проверять доказательства и сохранять альтернативные пути действий, оставляя суждение за теми, кто действительно несёт ответственность за последствия для бизнеса. Его ценность — не в нагнетании страха, а в том, чтобы дать организации более ясное представление о возможных действиях, пока проблему ещё можно решить.