Утёкший пароль — это состояние, а не растущее число

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

Причина в устройстве рынка. Сборки вроде «Collection #1» собраны из десятков старых утечек и до сих пор перевыпускаются под новыми именами. В телеграм-каналах один и тот же файл получает свежую дату при каждой перезаливке. То есть рост измеряет не качество разведки, а скорость переупаковки.

В итоге через три месяца у вас есть число 11 000, но вы не знаете: сколько из них действительны сегодня? Сколько уже сменено? Означает ли рост числа рост вашего риска?

Ответ — нет. Только растущий показатель не может быть инструментом управления, потому что никакое действие его не снижает. Что бы вы ни сделали, график идёт вверх, и через год на него перестают смотреть.

Утечка — это не событие, а состояние. Каждая находка находится в одном из четырёх состояний: новая находка, активный риск, закрыто, в архиве. И движется она только в одну сторону.

Тогда меняется и показатель: вместо общего числа в отчёт выносится число активных рисков. Оно может уменьшаться — именно поэтому от него есть польза. Это единственное число, понятное правлению, потому что оно отвечает на проделанную работу.

Это не украшение отчёта. Автомат состояний ещё и распределяет ответственность: новая находка у аналитика, активный риск у команды IAM, закрытое в архиве. В списке без состояний не отвечает никто — потому ничего и не закрывается.

Переходы между состояниями тоже должны фиксироваться: кто, когда и на каком основании. Иначе отметка «закрыто» превращается в флажок, который ставят руками и никто не проверяет.

Когда появляется новый комболист, первый вопрос не «нет ли там нашего». Первый вопрос — «это новое или переупакованная копия дампа 2019 года».

Если учётные данные уже сменены, их повторное появление — не событие, а шум. Без этой проверки система каждый квартал шлёт один и тот же алерт по одним и тем же паролям, и аналитик перестаёт их читать. А значит, перестанет читать и настоящую новую находку.

Технически это несложно: для каждой находки хранится устойчивый идентификатор — обычно связка адреса и хеша пароля, — и новая запись сверяется по нему. Сам пароль хранить не нужно и не следует.

Сложность в том, чтобы делать это с самого начала. Потом связывать со старыми данными будет уже не с чем: у вас останутся только числа, и к какой находке они относятся, неизвестно.

Уведомить — не значит закрыть. Утёкший пароль считается закрытым только когда сделаны три вещи: пароль сброшен, активные сессии отозваны, и для этой учётной записи включена многофакторная аутентификация.

Не отозвать сессии — самая частая ошибка. Пароль сменили, а открытая сессия атакующего продолжает работать. Это естественное следствие устройства приложений: refresh-токен или долгоживущая cookie сами по себе не знают о смене пароля, если система не отзывает их намеренно.

На практике для этого есть конкретные, документированные операции: `Revoke-MgUserSignInSession` в Microsoft Entra ID, сброс сессий пользователя в Google Workspace, удаление записей из таблицы refresh-токенов в собственном приложении. Если этого действия нет в чек-листе, оно не выполняется.

Поэтому право поставить отметку «закрыто» должно принадлежать не человеку, а системе: состояние меняется само, когда зафиксированы все три действия. Флажок, который ставит человек, всегда оптимистичен.

Если утекли учётные данные сотрудника, у вас есть все права их закрыть: сменить пароль в каталоге, отозвать сессии, включить MFA. Это работа на несколько минут, и она не требует согласований.

С клиентскими так нельзя. Принудительный сброс нагружает поддержку и стоит части клиентов — особенно если восстановление идёт по почте, а эта почта лежит в том же дампе.

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

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

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

Поэтому принадлежность находки домену нужно подтверждать: есть ли адрес в вашем каталоге, активна ли учётная запись, когда был последний вход. Без этой проверки половина списка — несуществующие сотрудники: уволенные, рассылочные адреса, тестовые учётки.

Второй фильтр — сам пароль. Если утёкший пароль вообще не соответствует вашей текущей политике (короче минимума, состоит только из цифр), скорее всего он из старой системы или вовсе из другого сервиса. Это не отменяет находку, но снижает приоритет.

Третий случай — логи инфостилеров. Они качественно отличаются от комболистов: данные сняты с устройства, а значит, вместе с паролями могли уйти cookie и сессионные токены. Здесь смены пароля недостаточно — само устройство считается недоверенным.

В утечках основная метрика не количество, а скорость. Каждый час, пока учётные данные в открытом обороте, — это время на их подстановку в другом месте, потому что люди повторяют пароли в нескольких сервисах.

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

Для первого нужна дата публикации источника, а она известна не всегда. Поэтому практичная метрика — «от появления в канале до появления в нашей панели»: это проверяемое число, и за него отвечает поставщик.

Эти два числа говорят больше, чем «11 000», и оба могут улучшаться — то есть их можно ставить как цель. Только растущее число целью быть не может.

Когда поставщик говорит «мы нашли N утечек», задайте три вопроса. Сколько из них сейчас в состоянии активного риска? Как вы отделяете переупакованные старые дампы? Есть ли интеграция с каталогом или IAM, то есть закрытие на вашей стороне или на моей?

Четвёртый вопрос про отчёт: снизилось ли число активных рисков за последние три месяца? Покажите график. Если он только рос, значит либо процесс закрытия не работает, либо метрика поставлена неверно — и то, и другое стоит знать.

Пятый про данные: вы храните найденные пароли? Правильный ответ — нет, только хеш или частичное представление. Иначе поставщик собирает вашу базу учётных данных, и она тоже может утечь.

Если внятных ответов нет, вы покупаете не сервис, а фид. Фид может быть полезен — но превращать его в конечный автомат придётся вам самим, и в решении о покупке эта работа обычно не учтена.