Кратко

  • Кампания Orion удалась, потому что злоумышленники скомпрометировали производственный процесс разработки ПО, внедрили SUNBURST во время автоматизированной сборки и позволили штатным механизмам подписания и распространения SolarWinds доставить модифицированный компонент. Действительная подпись подтверждала скомпрометированный процесс выпуска, но сама по себе не устанавливала, что итоговый код соответствует одобренному состоянию исходного кода.
  • Менее 18 000 заказчиков могли получить затронутые релизы, но эта цифра не является числом организаций, проникновение в которые произошло в ходе последующих операций. Более поздние публичные оценки относили подтверждённые или предполагаемые последующие компрометации к девяти федеральным ведомствам США и менее чем 100 негосударственным организациям, а SolarWinds отдельно оценивала число взломанных через SUNBURST заказчиков менее чем в 100.
  • Ответственность за шпионскую операцию несёт Служба внешней разведки России. Тем не менее именно SolarWinds контролировала среду сборки, происхождение релизов, путь подписания и архитектуру продукта, которые превратили одну внутреннюю компрометацию в доверенный код на площадках заказчиков. Заказчики и государственные покупатели контролировали сегментацию, логирование, усиление идентификации, закупки и восстановление. Каждая сторона отвечает за те меры защиты, которыми реально могла управлять.
  • Правовой след уже, чем операционный. SEC подала иск к SolarWinds и её директору по информационной безопасности в 2023 году, федеральный суд отклонил большую часть требований в 2024 году, а SEC прекратила оставшееся разбирательство с запретом повторного предъявления иска в ноябре 2025 года. Эта история не доказывает ни первоначальные утверждения SEC, ни то, что все решения по безопасности сборки были адекватными; она показывает, почему техническую предотвратимость, законодательство о раскрытии информации и окончательную юридическую ответственность нужно анализировать раздельно.

Обновление сделало ровно то, что ему велела инфраструктура доверия

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

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

Оригинальное техническое раскрытие SUNBURST от Mandiant задокументировало подписанный SolarWinds плагин Orion, содержащий бэкдор. Компонент мог ждать до примерно двух недель, изучать своё окружение, связываться по DNS- и HTTP-паттернам, имитирующим легитимный трафик Orion, и получать команды только после того, как атакующий выбирал жертву. Первоначальная закладка была задумана как тихая, избирательная и совместимая с основным продуктом. Её цель состояла не в том, чтобы мгновенно взломать все установки, а в том, чтобы разместить надёжный вариант внутри многих сетей и задействовать лишь малую их часть.

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

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

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

Что устанавливает публичный архив

Наиболее сильная картина складывается из источников с разными институциональными интересами: раскрытий SolarWinds об инциденте и её документов о ценных бумагах; технических анализов CrowdStrike и Mandiant; материалов CISA, АНБ (NSA), ФБР (FBI) и затронутых ведомств; отчёта GAO о реакции федерального правительства; показаний в Конгрессе; и более поздних судебных материалов. Они отвечают не на все вопросы, но устанавливают несколько ключевых фактов.

Во-первых, продвинутый атакующий сохранял доступ к среде SolarWinds достаточно долго, чтобы изучить производственный процесс Orion. В обновлении с итогами расследования от мая 2021 года SolarWinds сообщила, что не может точно определить, когда и как произошло первоначальное проникновение. Компания сообщила о доказательствах скомпрометированных учётных данных и устойчивого доступа к среде разработки ПО и внутренним системам, включая Microsoft 365, в течение как минимум девяти месяцев до тестового запуска в октябре 2019 года.

Компания сузила возможные первоначальные пути до стороннего zero-day, перебора паролей (например, password spraying) или социальной инженерии, но не заявила, что доказала какой-либо из них.

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

В-третьих, атакующие проверили способность изменять сборки до развёртывания операционного бэкдора. В январских выводах о сборочной системе SolarWinds отнесла самую раннюю известную подозрительную внутреннюю активность к сентябрю 2019 года, тестовую модификацию — к релизу Orion в октябре 2019 года, начало внедрения SUNBURST — к 20 февраля 2020 года, а удаление вредоносного кода из среды — к июню 2020 года. Более поздние отчёты компании отодвинули свидетельства доступа ещё дальше в прошлое, сохранив октябрьский тест и окно распространения с марта по июнь.

В-четвёртых, затронутые версии Orion распространялись обычными каналами. В форме 8-K от 14 декабря 2020 года SolarWinds сообщила, что продукты, загруженные, внедрённые или обновлённые в соответствующий период, содержали уязвимость, и оценила, что менее 18 000 заказчиков могли установить затронутые релизы. В форме 10-K за 2020 год компания позднее описала SUNBURST как внедрённый в сборки, выпущенные с марта по июнь 2020 года, сообщила, что затронутое ПО устанавливалось на площадках заказчиков, и подчеркнула, что число эксплуатированных установок значительно меньше числа тех, кто мог установить затронутую версию.

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

В-шестых, правительство США позднее официально возложило кампанию на российскую СВР. В совместном уведомлении CISA от апреля 2021 года зафиксированы атрибуция США и соответствующие рекомендации NSA-CISA-FBI; Великобритания также публично связывала СВР с операцией. Атрибуция устанавливает ответственность враждебного атакующего и геополитический контекст. Но она не отвечает на вопрос, были ли меры защиты вендора или заказчиков соразмерны предвидимому классу атак на цепочку поставок.

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

От разведки до подписанного бэкдора

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

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

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

Анализ SUNSPOT от CrowdStrike объясняет механизм. SUNSPOT следил за процессомMsBuild.exe, изучал информацию командной строки, чтобы распознать решение Orion, и заменял файлInventoryManager.csвредоносным вариантом во время сборки продукта. Он сохранял оригинальный файл, чтобы восстановить его позднее. Он включал меры, направленные на предотвращение сбоев сборки, и операционные механизмы, позволявшие злоумышленнику чисто остановиться, а не оставить очевидно сломанную компиляцию. Конструкция рассматривала подозрения разработчиков как главную опасность.

Получившийся вредоносный код стал SUNBURST внутриSolarWinds.Orion.Core.BusinessLayer.dll. Поскольку подмена произошла во время сборки, итоговый пакет мог пройти последующие шаги упаковки и подписания как обычный продукт. Подпись была настоящей. Стоявшее за ней утверждение о происхождении было неполным.

После установки SUNBURST задерживал выполнение и проверял условия среды, которые могли указывать на анализ. Он генерировал уникальные для жертвы DNS-запросы и позволял оператору решать, каким маякам перейти к более активному управлению. Дополнительный технический анализ Mandiant описал антианалитические проверки, генерацию доменов, режимы команд и усилия по встраиванию состояния в легитимную конфигурацию Orion. Избирательность снижала вероятность того, что 18 000 потенциальных установок породят 18 000 видимых инцидентов.

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

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

Почему рецензирования кода и подписания недостаточно

Инцидент с Orion вскрыл разрыв между контролями целостности ПО, которые часто считают взаимозаменяемыми.

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

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

Это версия проблемы цепочки поставок: правдивое утверждение, построенное на ложной посылке. Пакет был правдиво подписан SolarWinds. Заказчики выводили из этого нечто более широкое: что пакет представляет собой продукт, который SolarWinds намеревалась выпустить. Инцидент разрушил этот вывод.

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

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

Воспроизводимые или независимо повторяемые сборки могут помочь, но это не волшебство. Если якобы независимые сборщики используют общие учётные данные, оркестрацию, зависимости или скомпрометированную плоскость управления, они могут воспроизвести один и тот же вредоносный результат. Сравнение имеет значение только тогда, когда пути доверия действительно разделены. Аналогично, спецификация состава ПО (SBOM) может выявить компоненты, но не показать, что сборочный узел вставил дополнительный собственный код. Инвентаризация полезна; она не эквивалентна происхождению.

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

Проблема знаменателя: 18 000 — это подверженность, а не подтверждённая эксплуатация

Немногие цифры из этого инцидента повторялись так часто, как 18 000. Она полезна, только если указан её знаменатель.

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

В мае 2021 года SolarWinds оценила, что через SUNBURST были взломаны менее 100 заказчиков. В марте 2021 года показания ФБР описывали более 16 000 затронутых публичных и частных заказчиков, девять федеральных ведомств с последующей компрометацией и менее 100 негосударственных организаций в этой категории. Цифры совместимы, если «затронуты», «установили», «отправили маяк», «были целью» и «скомпрометированы» остаются различными категориями.

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

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

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

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

Обнаружение и цена поздней видимости

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

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

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

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

Первая публичная реакция CISA отражала серьёзность этой неоднозначности. В уведомлении от 13 декабря были указаны затронутые версии, а чрезвычайная директива 21-01 предписывала федеральным гражданским ведомствам отключить затронутые продукты Orion. Распоряжение было не просто «установите патч». Уже скомпрометированный сервер управления мог содержать доказательства, учётные данные или персистентность за пределами исходной DLL. Относиться к нему как к обычной уязвимости означало риск сохранить атакующего после замены исходного файла.

Более поздние рекомендации CISA по «выселению» касались сетей, где атакующий мог переместиться в Active Directory и Microsoft 365. Выселение могло потребовать скоординированного восстановления идентификаций, аннулирования токенов и учётных данных, проверки облака, пересборки хостов и мониторинга. Эти шаги могут нарушить операции и поглотить дефицитный персонал, даже когда публичные сервисы остаются онлайн. Цена непрерывности при конфиденциальной компрометации частично измеряется работой, необходимой для восстановления обоснованного доверия.

Рекомендации Национального центра кибербезопасности Великобритании (NCSC) аналогично различали затронутые бинарные файлы и серьёзное последующее воздействие. Они советовали изоляцию, проверку хешей и DNS, сброс учётных данных, расследование учётных записей, связанных с сервером Orion, и рассмотрение полной пересборки. Глобальная согласованность этих рекомендаций показывает, что отказ доверия не ограничивался средой закупок одного правительства.

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

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

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

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

Непрерывность госсектора без видимого блэкаута

GAO описало кампанию как одну из самых масштабных и сложных хакерских операций, проведённых против федерального правительства и частного сектора. В обзоре федеральной реакции за 2022 год ведомство отметило, что агентства сформировали Единую координационную группу по кибербезопасности (Cyber Unified Coordination Group), разработали технические рекомендации и инструменты, обменивались информацией и извлекли уроки в области координации, доступа к информации и реагирования на инциденты. Реакция была масштабной, потому что компрометация затронула механизмы, через которые правительство понимает и администрирует собственные системы.

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

Непрерывность в этом контексте имеет несколько слоёв.

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

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

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

Четвёртый — непрерывность идентификации. В рекомендации АНБ от декабря 2020 года объяснялось, как привилегированный локальный доступ может привести к подделке федеративной аутентификации и доступу в облако. Как только локальное доверие к идентичности скомпрометировано, простая очистка исходного хоста Orion не восстанавливает действительность каждого сеанса или токена, производного от него.

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

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

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

Ответственность SolarWinds: контроль над фабрикой

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

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

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

Октябрьский тест 2019 года и более поздняя операция SUNSPOT показывают, что атакующий нашёл возможность модифицировать сборку, не создавая расхождения, останавливающего выпуск. Длительный период внутреннего доступа и необнаружение производственной манипуляции — неблагоприятные факты в оценке контроля. Сложность атакующего важна для определения требуемого уровня сопротивления, но она не является индульгенцией. Вендор, чей продукт занимает привилегированные позиции в правительствах и крупных предприятиях, должен ожидать нацеленности со стороны capable субъектов и проектировать фабрику соответственно.

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

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

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

Ответственность заказчика: ограничить доверенный продукт

Заказчики не контролировали сборочную систему SolarWinds, но контролировали среду, в которую устанавливался Orion. Их ответственность начинается там, где продукт входит в эту среду.

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

Это конкретный пример защиты на стороне заказчика, ограничивающей сбой, источником которого стал производитель.

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

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

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

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

Ответственность государства: покупатель, координатор и владелец непрерывности

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

До SolarWinds управление рисками федеральной цепочки поставок уже было неполным. В майских показаниях 2021 года GAO отметило, что ни одно из 23 рассмотренных гражданских ведомств полностью не внедрило отдельные базовые практики управления цепочкой поставок ИКТ. Время имеет значение: правительство не может разумно возложить всё бремя на вендора, не проведя инвентаризацию, оценку и непрерывное управление критически важным ПО, от которого зависят ведомства.

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

Правительство также обладало агрегированными преимуществами, недоступными отдельному заказчику. CISA, ФБР, АНБ, ODNI и отраслевые партнёры могли объединять засекреченную и незасекреченную информацию, сопоставлять отчёты, публиковать индикаторы и координировать выселение. GAO обнаружило, что Единая координационная группа по кибербезопасности помогла организовать реакцию, но также выявила проблемы с обменом информацией и доступом частного сектора. Задержка координации имеет публичную цену, когда каждая затронутая организация отдельно пытается определить, опасен ли один и тот же подписанный файл.

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

Последующая политическая документация двигалась в этом направлении. Структура NIST по безопасной разработке ПО (Secure Software Development Framework) включает практики защиты сред разработки, сохранения происхождения, проверки релизов, реагирования на уязвимости и предотвращения повторения. Рекомендации NIST по кибербезопасности цепочки поставок помещают риск поставщика внутрь корпоративного управления, а не оставляют его анкетному опросу закупок. Меморандум OMB M-22-18 требовал от федеральных ведомств получать от производителей ПО заверения, привязанные к практикам безопасной разработки NIST, для охватываемого ПО.

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

Правовой архив не даёт простого вердикта

Операционная ответственность и юридическая ответственность после инцидента резко разошлись.

В октябре 2023 года SEC предъявила SolarWinds Corporation и директору по информационной безопасности Тимоти Брауну обвинения в мошенничестве и нарушениях контроля. В релизе SEC утверждалось, что публичные заявления преувеличивали практики безопасности и преуменьшали известные риски до SUNBURST. Эти утверждения были значимыми, но жалоба — это позиция истца, а не установленный факт.

В июле 2024 года Окружной суд Южного округа Нью-Йорка отклонил большую часть требований SEC. Суд позволил продолжиться требованиям о мошенничестве с ценными бумагами, основанным на Заявлении о безопасности на сайте компании до SUNBURST, сочтя, что изменённая жалоба надлежащим образом излагает вводящие в заблуждение утверждения о контролях доступа и практике паролей. Суд отклонил требования, основанные на раскрытии рисков, формах 8-K за декабрь 2020 года, заявлениях после инцидента, внутреннем бухгалтерском контроле и контроле раскрытий. Решение применяло процессуальные стандарты и стандарты законодательства о ценных бумагах.

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

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

Эта последовательность поддерживает четыре дисциплинированных вывода.

Первый: первоначальную теорию SEC не следует повторять как установленный факт. Многие требования были отклонены, и ни одно не дошло до судебного вердикта.

Второй: прекращение правоприменительного дела не следует подавать как техническое доказательство того, что контроль сборки SolarWinds соответствовал адекватному стандарту в 2019 и 2020 годах. Дело касалось конкретных заявлений, элементов, статутов и правил о форме исковых заявлений. Суд может отклонить требование о ценных бумагах, тогда как задокументированным остаётся инженерный отказ контроля.

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

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

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

Исправление должно изменить доказательства, а не только диаграмму архитектуры

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

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

Заслуживающий доверия пакет гарантий должен ответить как минимум на следующие вопросы:

  1. Можно ли каждый выпущенный бинарный файл проследить до неизменной одобренной ревизии исходного кода, набора зависимостей, компилятора и политики сборки?
  2. Эфемерны ли сборочные узлы или восстанавливаются из проверенного состояния, и изолированы ли их плоскости управления от обычной корпоративной идентичности?
  3. Может ли одно учётное данное изменить сборку, подавить телеметрию и запросить производственную подпись?
  4. Действительно ли независимы раздельные сборки или у них общая скрытая зависимость, способная произвести идентичную компрометацию?
  5. Проверяет ли сервис подписания происхождение и политику или подпишет любой артефакт, представленный авторизованной учётной записью?
  6. Записываются ли журналы сборки и подписания в отдельно администрируемое, защищённое от вмешательства хранилище и сохраняются ли в течение времени пребывания, ожидаемого от государственного атакующего?
  7. Используются ли тестовые канарейки или контролируемые инъекции сбоев, чтобы доказать, что несанкционированное изменение сборки останавливает выпуск?
  8. Может ли вендор отозвать релиз, уведомить заказчиков по классам подверженности и предоставить чистые артефакты восстановления, не уничтожая криминалистические доказательства?
  9. Получают ли заказчики проверяемое происхождение или только подпись и маркетинговую гарантию?
  10. Видимы ли исключения для руководства и заказчиков, чей риск меняется из-за них?

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

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

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

Практическое распределение ответственности

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

Российская СВР, согласно атрибуции США и союзников, планировала и провела шпионскую кампанию. Она выбрала компрометацию поставщика, спроектировала SUNSPOT и SUNBURST, отобрала нижестоящие цели и использовала украденный доступ. Её вина первична и умышленна.

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

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

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

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

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

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

Устойчивый урок: подписям нужна цепочка производственной истины

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

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

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

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

Стандарт ответственности должен следовать из этой реальности. Атакующий отвечает за вторжение. Вендор отвечает за то, чтобы путь выпуска был устойчивым, наблюдаемым и честно описанным. Заказчик отвечает за сдерживание продукта и сохранение независимых доказательств. Государство отвечает за закупки с учётом этих зависимостей и за поддержание публичных миссий, когда доверие рушится. Кампания Orion 2020 года пересекла все четыре домена. Устойчивое исправление должно сделать то же самое.