Microsoft Storm-0558 и сбой с ключом подписи, сделавший облачную идентичность проблемой публичной ответственности

Кратко

• Storm-0558 не взломала парольную защиту отдельного федерального ведомства. Группировка использовала потребительский ключ подписи Microsoft, чтобы изготавливать внешне действительные токены идентичности, а затем воспользовалась дефектом проверки в Microsoft, который позволял токенам, подписанным потребительским ключом, достигать корпоративной почты Exchange Online.
• Путь получения ключа остаётся невыясненным. Объяснение Microsoft от сентября 2023 года о дампе памяти при сбое позже было сужено до ведущей гипотезы после того, как компания признала, что не нашла ни дамп памяти с ключом, ни логи, подтверждающие его утечку. Устаревший ключ, дефект проверки на границе доменов, слабое обнаружение аномальных токенов и ограниченное хранение криминалистических данных — более обоснованные выводы о сбоях.
• Ответственность следует за возможностью контроля. Только Microsoft могла ротировать ключ платформы, исправить проверяющий компонент на стороне сервиса, выявлять невозможные комбинации токенов в своём облаке, сохранять соответствующие внутренние доказательства и закрыть вектор атаки. Клиенты могли улучшить мониторинг и реагирование, но в 2023 году решающая телеметрия MailItemsAccessed была привязана к более дорогим лицензиям E5/G5.

Сбой контроля идентичности, а не обычная утечка из почтовых ящиков

Вторжение Storm-0558 легко сжать в привычную фразу: китайские хакеры украли ключ Microsoft и читали правительственную почту. Эта фраза верна по направлению, но аналитически недостаточна. Она сливает в одно событие действия злоумышленника, невыясненную потерю Microsoft криптографического материала, отдельный дефект проверки в программном обеспечении, решение о жизненном цикле устаревшего ключа, успешное обнаружение на стороне клиента и реакцию поставщика сервиса. Если разделить эти механизмы, распределение ответственности становится гораздо яснее.

Вторжение не было прежде всего случаем, когда госслужащий сдал пароль, ведомство не внедрило многофакторную аутентификацию или внутри министерства остался незапатченный сервер. У Storm-0558 была приватная половина потребительского ключа подписи Microsoft Account (MSA), созданного в 2016 году. Приватный ключ подписи позволяет его обладателю создавать токены, подписи которых можно проверить по соответствующему публичному ключу. Актор мог подтверждать идентичность, не получая паролей жертв.

Второй дефект Microsoft позволял ключу, предназначенному для потребительских учётных записей, аутентифицировать запросы против корпоративного Exchange Online.

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

Втехническом анализе Microsoft за июль 2023 годаобъясняется базовый механизм: актор подделывал токены Azure Active Directory с помощью полученного потребительского ключа, использовал легитимный поток Outlook Web Access, получал токены Exchange Online через интерфейс GetAccessTokenForResource и извлекал почту через API OWA. Microsoft сообщила, что из-за дефекта проектирования актор также мог получать новые токены доступа, предъявляя токен, ранее выпущенный этим интерфейсом. Это был не простой повтор украденных учётных данных. Это был несанкционированный выпуск и продление учётных данных, которые сервисы Microsoft считали действительными.

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

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

Облако может оставаться технически «работающим», пока поддерживаемая им публичная функция становится менее заслуживающей доверия.

Что установлено, что является реконструкцией, а что остаётся неизвестным

Три категории доказательств следует держать отдельно.

Во-первых, публичные материалы твёрдо устанавливают, что Storm-0558 использовала созданный Microsoft потребительский ключ подписи MSA 2016 года для подделки токенов; что дефект проверки в Microsoft позволял этим токенам получать доступ к корпоративным учётным записям Exchange Online; что Госдепартамент обнаружил подозрительную активность с помощью расширенных журналов доступа к почтовым ящикам; и что Microsoft закрыла известную технику серией изменений на стороне сервиса. Раскрытия Microsoft, рекомендация CISA, заявления пострадавших ведомств и реконструкция Совета по обзору кибербезопасности сходятся в этих пунктах.

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

В-третьих, фактический маршрут, по которому Storm-0558 получила приватный ключ 2016 года, остаётся неизвестным в публичных материалах. Эта неопределённость центральная. В сентябре 2023 года Microsoft опубликовала подробную историю о дампе памяти при сбое, а затем в марте 2024 года добавила поправку о том, что не нашла дамп памяти, содержащий затронутый ключевой материал. CSRB сообщил, что Microsoft рассмотрела 46 гипотез кражи ключа и до сих пор не знает, как и когда актор получил ключ. Любая версия, представляющая дамп памяти как доказанную первопричину, преувеличивает доказательства.

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

Криминалистическая хронология

2016–2021 годы: долгоживущий ключ и отложенная миграция

Microsoft создала потребительский ключ подписи в 2016 году. Возраст ключа сам по себе не является доказательством небезопасности, но возраст становится существенным, когда организация не может уверенно показать непрерывное хранение, а ротация ограничивает срок годности украденного материала. CSRB установил, что потребительская система MSA в Microsoft полагалась на ручную ротацию, тогда как корпоративная система идентичности перешла к автоматизации. Компания намеревалась перевести потребительскую систему на автоматизированную технологию, но не завершила эту работу до вторжения.

По данным CSRB, Microsoft прекратила ручную ротацию потребительских ключей подписи в 2021 году после крупного сбоя облака, связанного с ручным процессом. Тогда компания не развернула ни автоматическую замену ротации, ни предупреждение, которое уведомляло бы ответственные команды о старении активных ключей. Поэтому ключ 2016 года оставался принимаемым в 2023 году. Это классическое решение между доступностью и безопасностью со скрытой отложенной ценой: приостановка рискованной ручной процедуры может снизить непосредственный риск сбоя, но незавершённая компенсирующая автоматизация сохраняет уязвимость безопасности бессрочно.

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

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

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

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

Реконструкция CSRB помещает ещё одно релевантное событие в 2021 год. Storm-0558 скомпрометировала корпоративную сеть Microsoft через учётную запись инженера в период с апреля по август. Инженер работал в Affirmed Networks, которую Microsoft приобрела в 2020 году; Microsoft полагала, что устройство было скомпрометировано до приобретения и позже подключалось к среде Microsoft с корпоративными учётными данными. Актор перехватил и воспроизвёл токен аутентификации и получил доступ к материалам в SharePoint, включая информацию, относящуюся к управлению сервисами Azure и идентичности.

Совет критиковал Microsoft за то, что она не обнаружила скомпрометированное устройство приобретённой компании, прежде чем допустить его в корпоративную сеть.

Этот компромисс 2021 года — доказательство доступа и интереса злоумышленника. Это не доказательство того, что актор тогда получил ключ MSA 2016 года. Microsoft сообщила Совету, что вторжение 2021 года, вероятно, связано с кражей, поскольку это было единственное другое известное вторжение Storm-0558 в сеть Microsoft за всю зафиксированную историю, но компания не представила конкретных доказательств, связывающих его с кражей ключа. Дисциплинированное изложение должно сохранить этот пробел.

Май–июнь 2023 года: доступ начинается до того, как провайдер его обнаруживает

Storm-0558 развернула идентифицированную внешнюю инфраструктуру и приступила к доступу к целевым учётным записям Exchange Online не позднее 15 мая 2023 года. CSRB предупредил, что окно компрометации могло начаться раньше, потому что стандартное 30-дневное хранение журналов Microsoft ограничивало ретроспективную картину, доступную после начала расследования. Таким образом, «первое наблюдение» — это граница доказательств, а не обязательно истинное начало атаки.

Цели отражали приоритеты шпионажа. В окончательном учёте CSRB названы 22 организации и более 500 человек по всему миру, включая жертв в Соединённых Штатах, Соединённом Королевстве и других странах. В их числе были учётные записи министра торговли Джины Раймондо, посла США в Китае Р. Николаса Бёрнса, помощника госсекретаря по делам Восточной Азии и Тихоокеанского региона Дэниэла Критенбринка и конгрессмена Дона Бэкона. Первоначальноеуведомление Microsoft об инциденте от 11 июляупоминало около 25 организаций и связанных потребительских учётных записей.

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

Кампанию обнаружил Госдепартамент, а не Microsoft. 15 июня центр операций безопасности Госдепартамента заметил аномалии. 16 июня пользовательское правило, известное внутри как Big Yellow Taxi, сгенерировало оповещения из события аудита MailItemsAccessed, которое фиксирует доступ к элементам почтовых ящиков Exchange Online. Госдепартамент провёл расследование, несмотря на возможность ложных срабатываний, и в тот же день связался с Microsoft. К 19 июня Госдепартамент установил, что затронуты шесть учётных записей, включая учётные записи, связанные с подготовкой поездки госсекретаря в Пекин.

Он выявил ещё шесть учётных записей, скомпрометированных в период с 21 по 24 июня, и ещё одну — через анализ изъятого виртуального частного сервера.

Даты показывают, что обнаружение и сдерживание перекрывались с продолжающимся доступом. Оповещение Госдепартамента было успехом обнаружения, но оно не сразу выявило подделанное платформенное учётное удостоверение. Microsoft сначала проверяла привычные объяснения, такие как скомпрометированные устройства и украденные корректно выпущенные токены. Затем её аналитики увидели, что артефакты аутентификации Exchange Online не соответствуют токенам Azure AD в ожидаемых журналах. Примерно 26 июня Microsoft установила, что актор использует потребительский ключ 2016 года для создания токенов, действующих против потребительской и корпоративной почты.

Совместная рекомендация CISA и ФБР AA23-193Aнеобычно прямо говорит о распределении мер смягчения. В ней сказано, что все меры смягчения для этой активности были ответственностью Microsoft, поскольку затронутая инфраструктура была облачной. Там также сказано, что ведомствам не известно о других журналах аудита или событиях, которые позволили бы обнаружить эту активность. Клиент обнаружил инцидент, но только провайдер мог закрыть эту технику.

26 июня — 3 июля: поэтапное смягчение, а не один переключатель

Подробная хронология Microsoft фиксирует несколько отдельных действий:

• 26 июня OWA перестала принимать токены, выпущенные GetAccessTokenForResource, для продления, закрыв поведение продления, которым злоупотреблял актор.
• 27 июня Microsoft заблокировала использование OWA токенов, подписанных похищенным ключом MSA, прекратив дальнейший доступ к корпоративной почте через наблюдавшийся путь.
• 29 июня Microsoft завершила замену ключа, отозвала все ключи подписи MSA, действовавшие во время инцидента, и выпустила новые ключи из укреплённых систем.
• 3 июля Microsoft заблокировала использование ключа для затронутых потребительских клиентов, чтобы предотвратить использование ранее выпущенных токенов.

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

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

Июль 2023 года — март 2024 года: раскрытие, реформа логирования и исправленное заявление о первопричине

Microsoft публично раскрыла кампанию 11 июля и опубликовала более глубокий технический анализ 14 июля. Её ранние публикации корректно описывали злоупотребление ключом и ошибку проверки, одновременно заявляя, что получение ключа остаётся предметом расследования. 19 июля, после координации с CISA, Microsoft объявила, что подробные журналы доступа к электронной почте и более 30 других типов событий аудита станут доступны клиентам стандартного тарифа без дополнительной платы. Компания также сообщила, что срок хранения по умолчанию для Audit Standard увеличится с 90 до 180 дней.

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

6 сентября Microsoft опубликовала то, что назвала результатами своих основных технических расследований. Исходный отчёт утверждал, что сбой потребительской системы подписи в апреле 2021 года породил дамп памяти; что состояние гонки позволило ключу попасть в дамп; что дамп переместился из изолированной производственной среды в корпоративную среду отладки с доступом в интернет; что сканеры учётных данных его пропустили; и что Storm-0558 позже скомпрометировала учётную запись инженера с доступом к этой среде. Поскольку срок хранения соответствующих журналов истёк, Microsoft назвала это наиболее вероятным механизмом получения.

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

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

Поправка меняет эпистемический статус отчёта. Правдоподобная гипотеза — это не вывод о первопричине. CSRB сообщил, что Microsoft сказала Совету в ноябре 2023 года, что поняла вскоре после публикации, что сентябрьские заявления неточны, но опубликовала поправку только в марте 2024 года после неоднократных вопросов Совета. Эта задержка стала частью вывода Совета о культуре безопасности, потому что клиенты используют раскрытие первопричин, чтобы судить, закрыт ли фактический путь получения.

Первопричина, триггер и сбои обнаружения

Анализ инцидента точнее, когда отделяет триггер от первопричин и от сбоев обнаружения и реагирования.

Триггер

Операционным триггером стало использование Storm-0558 украденного приватного ключа подписи MSA 2016 года для создания токенов и их предъявления через пути доступа Exchange Online. Актор выбирал цели, управлял инфраструктурой, выпускал поддельные токены, получал доступ к почте и выносил сообщения. Актор ответственен за злонамеренное вторжение. Атрибуция шпионскому актору, связанному с Китайской Народной Республикой, — это разведывательная оценка, о которой сообщили Microsoft и CSRB; эта статья не даёт собственную атрибуцию государственного командования.

Технические первопричины и способствующие условия

Первый вопрос о первопричине — как приватный ключ вышел из-под контроля Microsoft — не решён. Его следует фиксировать как открытый материальный факт, а не заполнять гипотезой о дампе памяти.

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

Третьей причиной был сбой проверки области действия токенов. Сервис проверял подпись по ключевому материалу, доступному через общие метаданные, но не доказывал должным образом, что домен идентичности ключа уполномочен санкционировать запрошенный корпоративный ресурс. Текущаядокументация Microsoft по проверке токенов доступавелит серверам ресурсов проверять подпись токена, аудиторию, издателя, тенанта и издателя ключа подписи. Случай Storm-0558 показывает, почему эти проверки не избыточны.

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

Четвёртой причиной был дефект проектирования продления токенов OWA. После того как поддельная идентичность была принята через легитимный поток, GetAccessTokenForResource позволял одному токену получать другой так, что позже Microsoft изменила это поведение, чтобы различать выпуск Azure AD и MSA. Это не создавало исходную способность подписи, но делало путь доступа полезнее и долговечнее.

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

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

Сбои обнаружения и реагирования

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

В то время MailItemsAccessed был доступен через Microsoft Purview Audit Premium и требовал лицензии E5 или G5. У Госдепартамента был G5, и он мог создать Big Yellow Taxi. Другие жертвы без премиального логирования не имели той же исторической видимости. Поэтому рекомендация CISA и ФБР призывала организации включить премиальное логирование, явно отмечая требование лицензии. Семь дней спустя Microsoft обязалась убрать тарифный барьер для ключевых типов событий. Директор CISA Джен Истерли назвала это изменение шагом к практике безопасности, встроенной в архитектуру, взаявлении CISA от 19 июля.

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

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

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

Проблема логирования и лицензирования

Логирование иногда рассматривают как вспомогательную функцию продукта. В этом инциденте оно было механизмом безопасности и источником информационной асимметрии.

Microsoft обладала сервисной телеметрией и внутренней видимостью системы идентичности, недоступной ни одному клиенту. Каждый клиент мог наблюдать только свой тенант и только те типы событий, которые включены в его подписку и конфигурацию. Решающее оповещение пришло из MailItemsAccessed — события, созданного для показа, когда были открыты элементы почтового ящика. CISA и ФБР заявили, что им неизвестно о другом событии аудита, которое обнаружило бы эту активность. Клиент без этого события мог заметить контекстные признаки, но у него не было той же прямой доказательной поверхности.

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

Последующее изменение признаёт это различие. Microsoft обязалась сделать более широкие облачные журналы безопасности доступными по всему миру без дополнительной платы, добавить детальные события доступа к электронной почте в Audit Standard и удвоить стандартный срок хранения по умолчанию до 180 дней. В феврале 2024 года CISA, Административно-бюджетное управление, Офис национального директора по кибербезопасности и Microsoft объявили, что расширенное логирование становится доступным всем федеральным ведомствам, использующим Purview Audit, независимо от тарифа, с автоматическим включением и более длительным хранением по умолчанию.

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

Реформа не отменяет ответственность клиента. Журналы нужно направлять в поисковые системы, хранить в соответствии с рисками и правовыми требованиями, настраивать базовые линии, запрашивать и связывать с процедурами реагирования. Рекомендация CISA предлагает именно эти меры. Но клиентская операционная дисциплина обретает смысл только после того, как провайдер выдаёт соответствующее событие и делает его доступным. Доступность телеметрии и использование телеметрии — два отдельных механизма контроля, принадлежащих разным сторонам.

Лицензирование также повлияло на криминалистическое равенство жертв. Среда G5 Госдепартамента имела более сильную историческую запись, чем среды стандартного тарифа. Включение события после инцидента не восстанавливает то, что никогда не записывалось. Это означает, что один и тот же сбой провайдера может давать разный уровень уверенности о последствиях в зависимости от подписки клиента, хотя ни один из клиентов не контролировал лежащий в основе ключ подписи. Поэтому минимальные криминалистические доказательства следует рассматривать как часть базового уровня безопасности сервиса, а не просто как допродажу.

Влияние на федеральных клиентов и непрерывность государственного сектора

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

Госдепартамент позже сообщил, что из 10 учётных записей было загружено примерно 60 000 писем. Впресс-брифинге 28 сентября 2023 годаведомство описало затронутые материалы как несекретные и заявило, что никакие секретные почтовые системы взломаны не были. Более широкая реконструкция CSRB выявила больше затронутых учётных записей Госдепартамента, что отражает разные способы подсчёта доступа к учётным записям и подмножества, из которого были загружены сообщения. Эта статья не делает выводов о содержимом сообщений сверх того, что раскрыли ведомства.

Служебный и личный почтовые ящики министра торговли были среди затронутых, согласно CSRB. Палата представителей США также была в затронутом множестве, включая конгрессмена Дона Бэкона.Запрос Комитета по надзору Палаты представителейв августе 2023 года добивался брифингов от Госдепартамента и Минторга об обнаружении, последствиях, реагировании и будущей безопасности. Эти факты устанавливают чувствительное воздействие на госсектор и озабоченность надзора; они не устанавливают, что конкретные политические решения изменились из-за вторжения.

Непрерывность в этом контексте имеет по меньшей мере пять измерений.

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

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

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

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

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

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

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

Выводы CSRB и почему они важны

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

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

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

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

Если бы существовало более сильное криминалистическое хранение, Microsoft могла бы ответить на вопрос о получении ключа.

Эти контрфактуалы демонстрируют принцип многослойной безопасности. Вторжение не требовало, чтобы каждый контроль отказал одинаково. Любой из нескольких независимых контролей мог предотвратить корпоративную компрометацию или существенно её сократить:

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

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

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

Реакция Microsoft

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

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

В ноябре 2023 года Microsoft запустила инициативу Secure Future Initiative. Еёпервоначальное объявление SFIпредусматривало единую полностью автоматизированную систему управления ключами для потребительских и корпоративных нужд на основе конфиденциальных вычислений и аппаратных модулей безопасности, с архитектурой, спроектированной так, чтобы ключи оставались недоступными, даже если нижележащие процессы скомпрометированы. Сопутствующая инженерная публикация обещала высокочастотную автоматическую ротацию без доступа человека.

После отчёта CSRB и отдельного вторжения российского государства в корпоративную почту Microsoft компания расширила SFI в мае 2024 года.Расширенная программапоставила цели, включая быструю автоматическую ротацию и аппаратную защиту ключей подписи, стандартные SDK идентичности во всех приложениях, проверку токенов идентичности с учётом состояния, более мелкое разделение ключей, устранение боковых переходов идентичности, двухлетнее хранение журналов безопасности и шесть месяцев подходящих журналов для клиентов. В ней также сказано, что часть вознаграждения старшего руководства будет зависеть от достижения целей безопасности.

В июне 2024 года вице-председатель и президент Microsoft Брэд Смит сказал Комитету Палаты представителей по внутренней безопасности, что компания принимает ответственность за каждый вопрос, указанный в отчёте CSRB. Егописьменные показаниягласят, что Microsoft выполняет все 16 рекомендаций Совета, применимых к компании, выделила эквивалент 34 000 штатных инженеров на SFI, переводит потребительскую и корпоративную системы идентичности на аппаратно-поддерживаемую систему управления ключами и достигла прогресса в автоматической ротации, общих библиотеках аутентификации и сигналах проверки токенов.

Запись парламентских слушанийдаёт публичный контекст надзора и вопросов.

К сентябрю 2024 года Microsoft отчиталась о Совете по управлению кибербезопасностью, заместителях директоров по информационной безопасности в инженерных подразделениях, включении безопасности в оценки эффективности сотрудников и регулярных обзорах на уровне исполнительного руководства и совета директоров.Отчёт SFI о прогрессе— доказательство изменений в управлении и заявленного прогресса внедрения.

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

Подотчётность по возможности контроля

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

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

Госдепартамент контролировал мониторинг своего тенанта, пользовательскую логику оповещений, триаж, эскалацию и координацию с CISA и ФБР. Он выполнил эти задачи достаточно эффективно, чтобы обнаружить вторжение уровня провайдера. Другие клиенты контролировали собственный мониторинг и реагирование в пределах доступной им телеметрии. Ответственность клиентов остаётся реальной, но она не может заменить контроль провайдера, который клиенты не могут видеть или изменить.

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

Storm-0558 контролировала враждебную операцию и несёт ответственность за вторжение. Этот очевидный факт не стирает предотвратимость. Расследования безопасности регулярно изучают, почему вредоносный или опасный вход достиг защищённых систем, несмотря на вину актора. Атрибуция и защитная подотчётность отвечают на разные вопросы.

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

Распределение не следует механически превращать в процент юридической ответственности. Контракты, суверенный иммунитет, ущерб, причинно-следственная связь, обязанности по раскрытию и юрисдикция регуляторов различаются.Запрос сенатора Рона Уайденаот июля 2023 года просил Министерство юстиции, Федеральную торговую комиссию и CSRB расследовать практики Microsoft. Этот запрос — доказательство регуляторной озабоченности, а не доказательство того, что запрошенные ведомства пришли к выводу о применении мер. Ни один используемый здесь публичный источник не устанавливает окончательного правового решения по Storm-0558.

Что должно доказать устойчивое устранение последствий

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

Хранение и жизненный цикл ключей

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

Корректность проверки

Каждый полагающийся сервис должен использовать одобренные библиотеки, проверяющие подпись, издателя, аудиторию, тенанта, класс учётных записей, издателя ключа, срок действия и авторизацию, специфичную для сервиса.Документация Microsoft по OpenID Connectобъясняет, что метаданные обнаружения раскрывают конечные точки провайдера и публичные ключи подписи; это не делает каждый перечисленный ключ взаимозаменяемым для любого ресурса. Тесты соответствия должны намеренно предъявлять корректно подписанные, но ошибочно ограниченные по области токены и проверять их отклонение.

Устойчивость к подделке за пределами подписей без состояния

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

Телеметрия провайдера и клиента

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

Коммуникация об инцидентах

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

Независимая гарантия

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

Практические уроки для облачных клиентов и государственных закупщиков

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

Во-первых, закупайте доказательства, а не только функции. Контракты и базовые уровни сервиса должны определять, какие события доступа, идентичности, администрирования, токенов и почтовых ящиков доступны; как быстро они поступают; как долго остаются доступными для поиска; и могут ли клиенты их экспортировать. Логирование следует тестировать на имитированных событиях до инцидента.

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

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

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

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

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

Оценка

Вторжение в Exchange Online через Storm-0558 было предотвратимым сбоем облачной идентичности с невыясненным начальным путём получения ключа. Публичные доказательства поддерживают вывод с высокой уверенностью, что Microsoft позволила старому потребительскому ключу подписи оставаться доверенным, не обеспечила границу между потребительской и корпоративной проверкой токенов, не имела достаточной детекции на стороне провайдера для комбинаций токенов, которые её собственные системы не выпустили бы, и сохранила слишком мало доказательств, чтобы реконструировать вынос ключа.

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

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

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

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