Как устаревает список внешнего периметра

Обычно список периметра собирают при подготовке к аудиту. Кто-то выгружает зону DNS, кто-то переносит адреса из облачной консоли — так рождается таблица.

В тот день таблица верна. На следующий маркетинг просит поддомен под лендинг, разработчик поднимает тестовый стенд, интегратор открывает временный API — и ничего из этого в таблицу не попадает.

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

Зона DNS показывает только то, что вы туда записали. Сервис, поднятый в облаке и работающий по собственному IP, там вообще не появится.

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

Журналы сертификатов особенно полезны. Каждый публичный сертификат попадает в открытый журнал, поэтому `test-2.internal.example.uz` становится виден сразу после выпуска сертификата — даже если он нигде не публиковался.

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

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

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

Запись «владелец: ИТ-отдел» — красивая форма бесхозности. Оповещение открывает не отдел, а конкретный человек.

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

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

Поддомен указывает на внешний сервис (облачное хранилище, статический хостинг, сервис форм), потом ресурс в этом сервисе удаляют. А запись DNS остаётся.

Теперь если кто-то заново займёт это имя в том же сервисе, он сможет размещать содержимое на вашем поддомене. Это называется захватом поддомена, и сертификат он тоже получит, потому что проверку контроля над доменом пройдёт.

Искать такие записи несложно: достаточно выделить те, чья цель не отвечает или сообщает «такого ресурса нет». Сложность в том, чтобы делать это регулярно.

Внешнее сканирование даёт список открытых портов, но сам по себе он ничего не говорит о риске. Открытый 443-й — это нормально.

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

Поэтому в список добавляют третью колонку: обязан ли этот сервис быть доступен из интернета? Каждая строка с ответом «нет» полезнее самого результата сканирования.

Сканер выдаёт сотни находок, и у каждой свой балл. Эти баллы внешние и вашего контекста не знают.

Правильная приоритизация опирается на три вопроса: доступен ли актив из интернета, есть ли на нём настоящие пользовательские данные и существует ли публичный эксплойт для этой уязвимости?

Находки, где все три ответа «да», обычно составляют несколько процентов общего списка. Работа начинается именно с этих процентов, а не с самых высоких баллов.

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

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

Третий показатель говорит больше всех. Если это часы — процесс работает. Если недели — у вас не список, а периодический отчёт.