Ваш периметр больше, чем вы думаете. И меняется без заявки в ИБ…

С этой публикации стартует цикл статей, посвященный PT EASM - решение класса EASM (External Attack Surface Management), предназначенное для автоматического обнаружения и постоянного контроля внешней поверхности сетевой атаки компании. 

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

А теперь начнем.

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

Через несколько месяцев его обнаруживает служба ИБ (хорошо, если обнаруживает). На странице - логотип компании, внутри - старая версия приложения. В реестре такого ресурса нет. Подрядчик считал, что выключение согласует заказчик. Владелец проекта думал, что подрядчик всё удалил после приёмки. Задача не появилась ни у одной из сторон. В этой истории прекрасно всё.

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

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

Довольствуемся тем, что есть

С чего обычно начинается история? Как правило, наиболее распространенных ситуаций две:

1.    Вызов. Мы компания «Рога и Копыта». Попробуйте найти все, что у нас есть на внешнем периметре.

2.    Передача целей. Вот наш периметр. Давайте действовать, исходя из этих данных.

Но в каждом из случаев это различные форматы и сущности. Иногда это выгрузка из системы учёта: IP-адреса, сети, полные доменные имена - FQDN, сведения о сервисах и владельцах. Иногда - несколько основных доменов, которые знает системный администратор. А иногда из исходных данных есть только название организации (когда-то это вызов, а когда-то данность).

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

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

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

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

Есть и ещё одна граница. Найденный объект, подтверждённый актив и ресурс, разрешённый для активной проверки - три разных состояния. Уверенность в технической связи не заменяет согласования допустимых действий.

А если найду?

Поиск начинается с гипотез о том, где компания могла оставить след. Один источник редко позволяет восстановить все связи. DNS показывает соответствие имён и адресов, сертификаты дают дополнительные имена, страницы и клиентский код - ссылки на соседние приложения и API. История наблюдений помогает понять, как менялось размещение.

Каждая находка становится отправной точкой для следующего вопроса. У сайта обнаружился отдельный API. В ответе API появилось имя другого сервиса. У этого имени есть история адресов. Так растёт карта связей, а вместе с ней - набор кандидатов для проверки принадлежности. Некоторые из векторов, с которыми обычно возникают сложности, представлены ниже.

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

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

Мигрирующая инфраструктура. Приложение переехало, DNS обновили, а прежний экземпляр забыли выключить. Или компания отказалась от IP-адреса, и теперь его использует другой клиент хостера. Исторические данные помогают найти оба случая, но трактовать их нужно по-разному. В первом остаётся лишняя экспозиция. Во втором прежняя принадлежность уже не подтверждает текущую. В карте должны сохраняться время наблюдения и история связи, а не вечная отметка «наш адрес».

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

Похожие страницы и фишинг. Совпадение логотипа или сходство содержимого может вывести на забытое зеркало, стенд подрядчика, типовой шаблон или поддельный сайт. CyberOK разбирала применение нечёткого хеширования к похожему содержимому в исследовании «SSDeep и все-все-все». Метод полезен для поиска кандидатов, но сам по себе не устанавливает владельца и не доказывает фишинг.

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

В своем решении мы делим сущности на несколько категорий:

1.    Triage – входной поток активов, которые размечает агент или оператор

2.    Scope – активы, принадлежащие внешнему периметру Заказчика

3.    Muted – активы, не принадлежащие внешнему периметру Заказчика

4.    Third Party – активы Заказчика, размещенные на ресурсах другой компании

5.    Shadow IT – активы, по которым агент или оператор однозначно не может установить связь с Заказчиком, но при есть признаки, указывающие на него (похожие страницы, фишинг и т.д.)

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

Время - деньги

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

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

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

На первом проходе достаточно зафиксировать: объект существует, наблюдался в такое-то время, обнаружен таким-то способом, связь с заказчиком требует подтверждения. Следующий проход может добавить назначение актива, сведения о размещенных на нем ресурсах, его историю, сходные страницы или адреса API из APK. Новые сведения порождают новые гипотезы, и цикл повторяется. Особенно это важно, когда одновременно в исследовании десятки или сотни организаций, каждый внешний периметр имеет свою специфику как с точки зрения состава, так и с точки зрения изменяемости и время обратной связи у каждого Заказчика отличается (иногда очень сильно).

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

Дальше работа становится постоянной. Новые наблюдения сравнивают с предыдущими: появился домен, сменился адрес, открылся сервис, вернулся старый стенд. Частота наблюдения может различаться в зависимости от важности объекта и скорости изменений. Сам факт постоянного процесса не делает наблюдение мгновенным - задержка обнаружения должна оставаться измеримой.

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

Первую версию внешнего периметра собрали, синхронизацию настроили, а дальше что? А дальше непрерывная работа агентов и операторов по обновлению. Но каждый раз проводить полный цикл разведки дорого, а главное долго: пока он идет, может появится поддомен уже известного домена (кому-то из разработчиков ну очень нужно проверить новый сервис перед релизом), который, как назло, если и найдется, то под конец очередной итерации (это могут быть несколько часов или дней, при этом при инцидентах счет может идти на минуты). Пока он не найден, мы не знаем ни о сервисах, которые с ним связаны, ни о возможных уязвимостях. Как следствие, мы не можем оповестить организацию, Заказчик не может исправить угрозы.

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

Вместе мы сила

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

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

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

Со стороны команды EASM тоже нужна подготовка. Вопрос заказчику должен содержать основание связи, актуальное наблюдение и конкретное решение, которое требуется принять. Например: «На этом домене находится форма записи, на которую ведёт ссылка с официального сайта. Подтвердите владельца сервиса и допустимость включения в проверки». На такой вопрос проще ответить, чем на очередную таблицу IP-адресов без контекста.

Карточка актива помогает сохранить результат этого диалога. В нашей работе мы практикуем двустороннее взаимодействие с Заказчиком. Это важно и для корректного принятия решения Заказчика о принадлежности ресурса, и для более детальной разведки экспертами (или остановки процесса по какими-то из веток, которые были отклонены).

Теги позволяют выделить полезные срезы: подрядчик, облако, тестовая среда, личный кабинет, конкретное подразделение. Описание объясняет назначение и/или причину связи. Статусы показывают, что известно и какое действие требуется. 

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

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

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

Начать можно с одного вопроса: если завтра обнаружится забытый стенд подрядчика (и "если" тут ключевое), кто и за какое время проведёт его от «похоже на наш» до проверенного решения?