AWS обновила публикацию в Security Blog о команде AWS Customer Incident Response Team (CIRT). Практический смысл изменений прост: клиентам стало проще понять, куда обращаться во время активного инцидента безопасности в AWS и как подготовиться к такому сценарию заранее.
Материал впервые вышел в июле 2022 года, а 26 мая 2026 года был обновлен. По словам AWS, изменения отражают актуальные варианты взаимодействия с командой, новые ресурсы по киберразведке, включая Threat Technique Catalog for AWS (TTC), дополнительные инструменты с открытым исходным кодом и более четкое разделение между поддержкой AWS CIRT и управляемым сервисом AWS Security Incident Response.
Эта граница важна. Во время инцидента путаница стоит времени. Если команда не понимает, какой канал AWS использовать, какие данные доступны AWS и где заканчивается зона ответственности поддержки, можно потерять критически важные часы.
Что изменилось в публикации AWS#
AWS описывает CIRT как специализированную глобальную команду, работающую круглосуточно и помогающую клиентам во время активных инцидентов на стороне заказчика в рамках модели AWS Shared Responsibility Model. В качестве примеров приводятся несанкционированный доступ, эксфильтрация данных и атаки с использованием программ-вымогателей.
Процесс обращения описан максимально практично. AWS рекомендует открыть запрос через AWS Support Center Console из затронутой учетной записи AWS, выбрать сервис, наиболее связанный с инцидентом, и запросить помощь. В качестве примеров указаны EC2, IAM и S3. Обращение из пострадавшей учетной записи помогает подтвердить право владения и дает номер обращения для отслеживания.
Если у клиента есть выделенная команда сопровождения AWS — TAM, Account Manager или Solutions Architect — AWS рекомендует уведомить их для запуска эскалации. Если доступ к учетной записи утрачен, запрос на помощь все равно можно подать.
Обновленная публикация также содержит больше материалов для подготовки. Самое заметное дополнение — Threat Technique Catalog for AWS (TTC). AWS описывает его как открытый каталог на базе MITRE ATT&CK Cloud Matrix, построенный на тактиках, техниках и процедурах, которые AWS CIRT наблюдала в ходе работы с клиентами. Для каждой техники доступны рекомендации по обнаружению и меры защиты, специфичные для AWS. Также каталог можно фильтровать по используемым сервисам.
Это важное изменение: знания, накопленные внутри CIRT, постепенно превращаются в публичные рекомендации. Каталог не делает подготовку исчерпывающей, но помогает командам безопасности выстраивать контрольные меры, детектирование и tabletop-сценарии вокруг техник, которые AWS действительно наблюдает на практике.
Почему это важно для SOC и команд реагирования#
Главная ценность CIRT не в том, что AWS может полностью взять расследование на себя. В публикации такого обещания нет. Речь идет о помощи в анализе данных из журналов сервисов AWS и элементов AWS control plane, а также о поддержке при триаже, анализе, локализации инцидента, выдаче рекомендаций и последующих действиях.
Важно понимать границы этой помощи. AWS обладает глубоким пониманием собственной инфраструктуры и видимостью на уровне своих сервисов. При этом значительная часть ответственности за происходящее внутри среды остается на стороне клиента. Согласно модели Shared Responsibility Model, AWS отвечает за security of the cloud, а клиент — за security in the cloud.
Для команд безопасности это означает, что AWS CIRT может стать особенно полезным партнером при расследованиях, связанных с активностью IAM, журналами сервисов, событиями S3, поведением control plane и другими артефактами на стороне AWS. Возможности команды значительно менее применимы там, где нужны форензика хостов, анализ памяти, исследование артефактов операционной системы или аудит исходного кода приложений. AWS прямо рекомендует дополнять поддержку CIRT специализированными DFIR-возможностями для этих уровней.
Здесь же возникает вопрос обращения с доказательствами и рисками приватности. Перед запросом помощи организация должна понимать, какая учетная запись затронута, какие журналы доступны, кто имеет право санкционировать взаимодействие с AWS и какие сторонние специалисты могут потребовать доступ к данным расследования. Поспешная эскалация без ясного понимания владельцев учетных записей и состояния логирования легко превращает инцидент в расследование вслепую.
TTC полезен еще и тем, что дает возможность проверить собственные механизмы обнаружения. Практический вопрос звучит так: соответствуют ли ваши правила мониторинга техникам, которые AWS регулярно наблюдает, или защита построена преимущественно на общих предположениях о безопасности облака?
Для дополнительного контекста по теме практического использования артефактов безопасности см. материал GigaTap об инициативе OpenSSF: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational
Что проверить до инцидента#
Самая важная проверка предельно проста: убедитесь, что команда знает, как открыть обращение в AWS из затронутой учетной записи и кто имеет право это сделать. Пока все работает нормально, такой вопрос кажется мелочью. Во время инцидента ситуация меняется.
Также проверьте процедуру обращения за помощью при потере доступа к учетной записи. AWS указывает, что такой путь существует, но знакомиться с ним впервые во время атаки вымогателя, подозрения на эксфильтрацию данных или компрометации учетных данных — плохая идея.
Полезный аудит перед инцидентом должен включать:
- Проверьте, какие учетные записи AWS критичны для бизнеса и кто способен подтвердить право владения ими.
- Определите канал поддержки, который команда будет использовать во время активного инцидента безопасности.
- Убедитесь, что Account Team, если она есть, включена в план эскалации.
- Проверьте, что журналы, необходимые для расследования событий в control plane, включены и хранятся достаточно долго.
- Настройте покрытие обнаружения для IAM, S3, EC2, EKS и других сервисов повышенного риска.
- Проведите аудит внутренних DFIR-возможностей или наличия внешнего партнера для анализа хостов, памяти и приложений.
- Изучите техники TTC, относящиеся к используемым сервисам AWS.
AWS также ссылается на ряд инструментов с открытым исходным кодом и обучающих материалов. В публикации упоминаются открытые фреймворки реагирования, инструменты включения логирования, решения для проверки средств защиты и оповещений с помощью имитации событий, а также Athena Security Analytics Bootstrap для расследования журналов сервисов AWS, архивированных в корзинах S3.
Кроме того, AWS указывает на открытые практические лаборатории по темам несанкционированного использования учетных данных IAM, атак вымогателей на S3, криптомайнинга, SSRF против IMDSv1 и инструментов подготовки к реагированию на инциденты.
Рассматривать эти материалы как замену полноценной программе безопасности не стоит. Их лучше использовать как тренировочную площадку. Если сценарий лабораторной работы напоминает реальный путь атаки в вашей инфраструктуре, полезно спрашивать не о том, прошла ли команда обучение, а о том, выдержат ли аналогичную атаку ваши журналы, оповещения, процедуры локализации и модель принятия решений.
Дополнительный материал по управлению доказательствами и рисками в AWS: https://gigatap.top/en/articles/aws-ky3p-report-gives-customers-a-cleaner-risk-evidence-path
Чего не стоит ожидать от AWS CIRT#
Обновленная публикация не обещает, что CIRT возьмет на себя все этапы реагирования. Она не заменяет клиентское логирование, сбор артефактов с конечных точек, анализ приложений, юридические процедуры или планы восстановления бизнеса.
Не стоит воспринимать TTC и как доказательство того, что любой инцидент в AWS можно полностью описать через каталог техник. Каталоги помогают готовиться к известным шаблонам атак. На практике злоумышленники продолжают комбинировать слабые учетные записи, открытые сервисы, ошибки конфигурации и специфические для бизнеса уязвимости способами, которые не всегда укладываются в матрицы и классификации.
Тот же принцип относится к инструментам с открытым исходным кодом. Они снижают затраты на внедрение и помогают перенять практики реагирования, но не отменяют необходимость тестировать средства защиты в собственной среде. Инструмент, который не встроен в процессы мониторинга, хранения журналов, распределения ответственности и эскалации, остается бесполезным независимо от числа звезд на GitHub.
Практический вывод проще и полезнее громких обещаний: AWS делает процессы взаимодействия с клиентами во время инцидентов и накопленные знания о типовых угрозах более доступными и понятными. Этим стоит воспользоваться заранее — проверить доступ к учетным записям, маршрутизацию обращений, состояние логирования, покрытие TTC и пробелы в DFIR.
Лучше сделать это до инцидента. Во время инцидента взаимодействие с AWS должно сводиться к открытию правильного обращения из правильной учетной записи с правильными доказательствами, а не к поиску нужной статьи в блоге под давлением.