Атаки на цепочку поставок: 9 примеров и способы защиты

Title тег: Примеры атак на цепочку поставок: Полное руководство (2013–2024) Мета-описание: Узнайте, что такое атаки на цепочку поставок, и рассмотрите 9 основных примеров от SolarWinds до XZ Utils, с механизмами атак, данными о финансовом ущербе и стратегиями защиты.

Что такое шок предложения и что это означает для кибербезопасности

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

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

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

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

Что такое атака на цепочку поставок?

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

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

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

Утечка данных — это результат, а не метод атаки. Атаки на цепочку поставок могут привести к утечкам данных, но не все утечки данных связаны с компрометацией цепочки поставок. Не все атаки на цепочку поставок также приводят к краже данных: NotPetya вызвала разрушение, а не эксфильтрацию данных.

Как работают атаки на цепочку поставок

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

Жизненный цикл атаки: шаг за шагом

1. Злоумышленник определяет доверенного поставщика или программный компонент, используемый целью
2. Злоумышленник получает доступ к системе сборки, репозиторию кода или серверу обновлений поставщика
3. Вредоносный код внедряется в легитимное программное или аппаратное обеспечение перед распространением
4. Поставщик распространяет скомпрометированный продукт через свои обычные доверенные каналы
5. Целевая организация устанавливает обновление или развертывает компонент, тем самым внося угрозу
6. Злоумышленник использует созданный плацдарм для горизонтального перемещения, шпионажа или доставки деструктивной полезной нагрузки

Таксономия векторов атак

Троянизированные обновления ПО

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

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

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

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

Атаки на реестры пакетов с открытым исходным кодом

Публичные реестры пакетов являются одними из самых активных поверхностей атак в цепочке поставок программного обеспечения. Сюда входят npm для JavaScript, PyPI для Python, RubyGems для Ruby, NuGet для .NET и Maven для Java. Один только реестр npm содержит более двух миллионов пакетов. Один скомпрометированный популярный пакет может распространить вредоносный код в миллионы приложений.

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

Конфузия зависимостей была впервые публично продемонстрирована в масштабе в 2021 году исследователем безопасности Алексом Бирсаном, который успешно добился выполнения кода в конвейерах сборки Apple, Microsoft, PayPal и 35 других крупных компаний, используя эту технику. Атака сработала не из-за ошибки (бага), а из-за того, как менеджеры пакетов разрешают конфликты имен между общедоступными и частными реестрами.

О Log4Shell: Log4Shell (CVE-2021-44228), критическую уязвимость, обнаруженную в декабре 2021 года в библиотеке логирования Java Apache Log4j, часто описывают как атаку на цепочку поставок. Это не так. Log4Shell была непреднамеренной программной уязвимостью. Ни один злоумышленник не внедрял её в кодовую базу Log4j. Путаница возникает из-за того, что наличие Log4j в качестве зависимости в тысячах программных продуктов сделало идентификацию всех затронутых систем похожей на задачу аудита цепочки поставок. Модель угроз здесь иная: атаки на цепочку поставок подразумевают намеренное внедрение вредоносного кода злоумышленником, в то время как Log4Shell была случайной ошибкой, которую злоумышленники использовали позже.

Компрометация MSP и боковое перемещение

Управляемые поставщики услуг (MSP) — это компании, которые удаленно управляют ИТ-инфраструктурой, безопасностью и системами организации-клиента. MSP часто используют компании малого и среднего бизнеса, у которых отсутствует штатная ИТ-команда. Компрометация MSP предоставляет злоумышленникам одновременный административный доступ ко всем клиентам этого MSP, делая MSP векторами атак с мультипликатором силы и непропорционально широким охватом. Рекомендация CISA AA22-131A) особенно предостерегает MSP о том, что они являются приоритетными целями.

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

Крупные примеры атак на цепочку поставок

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

Утечка данных Target (2013)

Target (2013) — криминальная группа получила доступ к сети точек продаж Target, сначала скомпрометировав Fazio Mechanical Services, стороннего подрядчика по системам ОВК и холодильному оборудованию, который имел сетевые учетные данные для удаленного доступа к системам Target.

Утечка данных в Target является самым ранним и широко изученным примером атаки на цепочку поставок. Злоумышленники не взламывали периметр защиты Target напрямую. Они получили учетные данные небольшого поставщика систем отопления, вентиляции и кондиционирования (HVAC), использовали их для доступа к сети Target через легитимный канал и затем переместились горизонтально к POS-системам, обрабатывающим данные платежных карт.

В результате произошла кража данных платежных карт приблизительно у 40 миллионов клиентов и личных данных приблизительно у 110 миллионов. Общие расходы Target в результате утечки превысили оценочную сумму в 200 миллионов долларов на урегулирование претензий, судебные издержки и меры по устранению последствий. Атака установила шаблон, который позже был усовершенствован другими атаками: компрометация доверенного поставщика, имеющего доступ к реальной цели, с последующим использованием этого доступа в качестве точки входа. Расследования Секретной службы США и Министерства юстиции подтвердили путь через стороннего поставщика в качестве вектора проникновения.

Атака на цепочку поставок SolarWinds (2020)

SolarWinds (2020) — APT29 (Cozy Bear), приписываемая Службе внешней разведки (СВР) России, скомпрометировала процесс сборки платформы ИТ-мониторинга Orion, внедрив бэкдор SUNBURST в обычное обновление программного обеспечения, которое скачали примерно 18 000 клиентов SolarWinds.

SolarWinds широко считается самой значимой кибератакой на цепочку поставок в задокументированной истории. Orion была широко распространенной платформой для ИТ-мониторинга, которая использовалась в государственных ведомствах США и крупных корпорациях. Злоумышленники внедрили бэкдор SUNBURST в конвейер сборки программного обеспечения, что означало, что вредоносный код был скомпилирован непосредственно в легитимный пакет обновления Orion, подписан действительными сертификатами SolarWinds и распространялся через официальные каналы обновления.

Среди примерно 18 000 организаций, загрузивших обновление с внедренным трояном, злоумышленники выбрали наиболее значимые цели для проведения вторичных атак. В их число вошли министерства финансов, торговли и внутренней безопасности США, Государственный департамент, а также Microsoft, FireEye и другие крупные технологические компании. Вторжение оставалось незамеченным в течение примерно девяти месяцев, пока компания FireEye не обнаружила его в ходе расследования аномалии в своих собственных системах.

APT29 использовала SUNBURST для первоначального доступа, затем осуществляла боковое перемещение по скомпрометированным сетям для достижения почтовых систем и конфиденциальных коммуникаций. Операцию расценили как шпионскую кампанию, а не как разрушительную атаку. Ответные действия правительства США, координируемые через Рекомендацию CISA AA20-352A,), включали экстренные директивы, затрагивающие все федеральные гражданские агентства.

NotPetya (2017)

NotPetya (2017) — Группировка Sandworm, приписываемая ГРУ ГШ ВС РФ (в/ч 74455), внедрила вредоносный код в обновление программного обеспечения M.E.Doc — украинского бухгалтерского приложения, используемого значительной частью компаний, работающих в Украине.

NotPetya не был программой-вымогателем. Он отображал сообщение с требованием выкупа, но это было лишь уловкой. Код перезаписывал главную загрузочную запись (MBR) зараженных систем, делая их восстановление навсегда невозможным. Это был деструктивный вайпер, созданный для нанесения максимального ущерба и не имевший реального механизма оплаты. Сходство с вымогателем было призвано скрыть источник атаки во время первоначального реагирования.

Первоначальным вектором заражения стало обновление M.E.Doc, однако NotPetya быстро распространился за пределы Украины через эксплойт EternalBlue и сетевое распространение, превратившись за считанные часы в глобальную катастрофу. Общий ущерб оценивается примерно в 10 миллиардов долларов по всему миру, что делает его самой разрушительной кибератакой в истории по финансовым последствиям. Среди названных жертв — гигант морских перевозок Maersk (примерно 300 миллионов долларов ущерба; компании пришлось заново устанавливать 45 000 ПК и 4 000 серверов с нуля), фармацевтический производитель Merck, FedEx/TNT Express и Mondelez International. Многие из этих организаций не имели прямого отношения к Украине и стали косвенными жертвами, которых достигли через глобальную сетевую инфраструктуру.

Атака подробно описана в ретроспективном расследовании Wired и приписывается группировке Sandworm со стороны США, Великобритании и Австралии. Sandworm отличается от APT29/Cozy Bear: они действуют под эгидой различных российских спецслужб (ГРУ против СВР) с разными оперативными полномочиями.

Атака на Kaseya VSA (2021)

Kaseya VSA (2021) — REvil, группа киберпреступников, работающая по модели «шифровальщик как услуга» (RaaS) и не имеющая связей с государством, использовала уязвимость нулевого дня в Kaseya VSA для одновременной рассылки вредоносных обновлений клиентам MSP.

Kaseya VSA — это платформа удаленного мониторинга и управления, широко используемая Управляемыми поставщиками услуг. REvil, финансово мотивированная преступная группа, выявила поверхность атаки MSP и использовала ее в больших масштабах. Скомпрометировав платформу VSA, REvil могла распространять вредоносные обновления, которые выглядели исходящими от доверенного MSP, одновременно всем нижестоящим организациям-клиентам.

Результат: около 60 MSP были скомпрометированы, и через них около 1500 нижестоящих предприятий подверглись атаке программ-вымогателей (вредоносного ПО, которое шифрует данные жертвы и требует оплаты за ключ дешифрования). REvil потребовала 70 миллионов долларов в биткоинах за универсальный дешифратор. Атака с особой ясностью продемонстрировала логику «множителя силы» при выборе MSP в качестве цели: одна скомпрометированная платформа охватила сотни организаций в ходе одной операции. CISA Advisory AA21-200B) содержит полный технический анализ.

Атака на цепочку поставок Codecov (2021)

Codecov (2021) — неизвестный злоумышленник скомпрометировал скрипт Codecov Bash Uploader, инструмент для отчетности по покрытию кода, встроенный в CI/CD-конвейеры тысяч организаций, и использовал его для кражи переменных окружения, включая учетные данные и токены API.

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

Компрометация оставалась незамеченной примерно в течение двух месяцев до того, как Codecov обнаружил ее в апреле 2021 года. Среди затронутых организаций были Twilio, HashiCorp и Confluent, которые сообщили, что их учетные данные были скомпрометированы. Атака продемонстрировала вектор атаки на цепочку поставок, специфичный для CI/CD: вместо того, чтобы компрометировать конечный программный продукт, злоумышленники нацелились на инструменты, которые организации используют для создания и тестирования программного обеспечения. Эта атака находится на пересечении компрометации конвейера сборки и кражи учетных данных, представляя собой отличный от используемых в SolarWinds и CCleaner векторов распространения обновлений паттерн.

Атака на цепочку поставок CCleaner (2017)

CCleaner (2017) — группировка AXIOM, деятельность которой связывают с поддерживаемыми государством китайскими хакерами, скомпрометировала среду сборки компании Piriform (разработчика CCleaner) и внедрила вредоносное ПО Floxif в легитимный установщик CCleaner, распространяемый через официальные каналы.

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

Атака имела вторую стадию: целевой вредоносный модуль (payload) был предварительно сконфигурирован для активации только на системах, принадлежащих примерно 40 высокотехнологичным компаниям, включая Cisco, Intel, Samsung и Sony. Для подавляющего большинства затронутых пользователей вредоносное ПО собирало данные пассивно. Для целевых технологических компаний это представляло собой серьезное вторжение в конфиденциальные сети. Анализ Cisco Talos) инфраструктуры командных и управляющих серверов CCleaner предоставил первое полное техническое описание атаки.

ASUS ShadowHammer (2019)

ASUS ShadowHammer (2019) — группа BARIUM, которую связывают с китайскими государственными хакерами, скомпрометировала утилиту Live Update от ASUS и распространила через официальные серверы обновлений ASUS версию с бэкдором, подписанную легитимными цифровыми сертификатами ASUS.

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

Злоумышленников интересовали не все 500 000 пользователей. Вредоносная нагрузка была предварительно настроена на активацию только в системах с примерно 600 конкретными MAC-адресами, что указывает на наличие предварительных разведданных о конкретных целях. Кампания была обнаружена и задокументирована исследовательской группой «Лаборатории Касперского» (Securelist)) в 2019 году.

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

Атака на цепочку поставок 3CX (2023)

3CX (2023) — группа Lazarus, приписываемая Разведывательному управлению Генерального штаба КНДР (RGB), осуществила первую публично подтвержденную атаку «цепочка поставок в цепочке поставок», получив доступ к среде сборки 3CX через предыдущий компромисс цепочки поставок программного обеспечения Trading Technologies.

Личный компьютер сотрудника 3CX был скомпрометирован через троянизированный установщик Trading Technologies X_TRADER, финансовой торговой платформы. Этот установщик Trading Technologies сам был скомпрометирован посредством цепочки поставок группировкой Lazarus в рамках предыдущей операции. Скомпрометированная машина сотрудника предоставила злоумышленникам доступ к среде сборки 3CX, которую они использовали для внедрения вредоносного ПО в 3CX Desktop App, платформу VoIP-коммуникаций, используемую более чем 600 000 компаний и 12 миллионами ежедневных пользователей по всему миру.

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

Бэкдор XZ Utils (2024)

XZ Utils (2024) — неизвестный субъект, действовавший под вымышленной личностью «Джиа Тан» и, как полагают специалисты по безопасности, в рамках государственной операции, основанной на поведенческих индикаторах (окончательное публичное подтверждение атрибуции отсутствует), в течение примерно двух лет внедрялся в проект с открытым исходным кодом XZ Utils, прежде чем внедрить бэкдор, нацеленный на аутентификацию SSH в системах Linux.

XZ Utils — это библиотека сжатия данных, которая работает как невидимая инфраструктура на миллионах серверов Linux. Это не приложение для конечного пользователя, а скорее базовое программное обеспечение, от которого незаметно зависят другие программы. Злоумышленник, действовавший под псевдонимом «Джиа Тан», начал вносить легитимный, высококачественный код в проект XZ Utils в 2022 году, завоевывая доверие и в конечном итоге получив права на коммит (commit privileges) благодаря продолжительному взаимодействию с сопровождающим проекта.

В начале 2024 года «Цзя Тан» внедрил бэкдор в XZ Utils версий 5.6.0 и 5.6.1. Бэкдор был разработан для компрометации аутентификации SSH в затронутых дистрибутивах Linux, потенциально предоставляя злоумышленнику удаленный доступ к любому серверу, работающему с затронутой версией библиотеки. SSH является основным протоколом удаленного администрирования для серверов Linux по всему миру, что делает потенциальный масштаб воздействия значительным.

Бэкдор был обнаружен до его широкого распространения Андресом Фройндом, инженером Microsoft, который заметил необычное потребление ресурсов процессора и снижение производительности SSH во время плановой работы и выявил его источник. Его открытие, опубликованное в марте 2024 года, предотвратило компрометацию цепочки поставок, которая могла затронуть миллионы серверов. В рекомендации OpenSSF (CVE-2024-3094) приводится полный технический отчет.

Почему атаки на цепочки поставок настолько опасны

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

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

За последнее десятилетие атаки на цепочки поставок стали более частыми и изощренными. В отчетах ENISA «Threat Landscape» отмечается устойчивая тенденция к росту, при этом атаки на цепочки поставок классифицируются как угроза высшего уровня для секторов критической инфраструктуры. Эскалация видна в хронологии событий: компрометация CCleaner в 2017 году затронула 2,27 миллиона обычных пользователей; операция SolarWinds в 2020 году скомпрометировала более 100 правительственных учреждений США; инцидент с XZ Utils в 2024 году, который удалось предотвратить в последний момент, был нацелен на основную инфраструктуру Linux, используемую миллионами серверов по всему миру. Амбиции злоумышленников существенно росли с каждым новым циклом.

Финансовые последствия соответствуют такому масштабу. NotPetya вызвал оценочный ущерб в размере 10 миллиардов долларов по всему миру, при этом только Maersk сообщила об убытках примерно в 300 миллионов долларов. Атака Kaseya сгенерировала требование выкупа в размере 70 миллионов долларов для 1500 пострадавших компаний. Реакция правительства США на инцидент с SolarWinds обошлась в сотни миллионов на устранение последствий и инвестиции в повышение безопасности. Правительственные и государственные организации (SolarWinds), финансовые учреждения (3CX), технологические компании (вторичные цели CCleaner) и операторы критически важной инфраструктуры из приоритетных секторов, определенных CISA, — все они стали целями. Ни одна отрасль, зависящая от стороннего программного обеспечения или управляемых услуг, не осталась вне зоны досягаемости.

Кто осуществляет атаки на цепочку поставок

Атаки на цепочку поставок проводятся двумя различными категориями злоумышленников: государственными группами продвинутых постоянных угроз (APT) и финансово мотивированными преступными организациями.

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

К документированным атакам на цепочку поставок относятся следующие государственные группы: APT29 (Cozy Bear), связанная со Службой внешней разведки (СВР) России, которая провела операцию SolarWinds; Sandworm, связанная с Главным разведывательным управлением (ГРУ) России, которая провела NotPetya через M.E.Doc; Lazarus Group, связанная с Разведывательным бюро Северной Кореи, которая провела атаку 3CX; группа BARIUM, связанная с китайскими государственными операциями, которая провела ASUS ShadowHammer; и группа AXIOM, также связанная с китайскими государственными операциями, которая провела атаку CCleaner. BARIUM и AXIOM — это отдельные группы, несмотря на то, что обе имеют китайскую атрибуцию.

Не все атаки на цепочки поставок являются операциями государственного уровня. Атака на Kaseya VSA была осуществлена REvil — русскоязычной киберпреступной организацией, работающей по модели «вымогатель как услуга» (ransomware-as-a-service) и не имеющей государственной аффилиации. Финансово мотивированные преступные группы переняли методы атак на цепочки поставок, поскольку компрометация одного MSP-провайдера позволяет доставить программы-вымогатели сотням клиентских организаций за одну операцию, что значительно увеличивает доходность по сравнению с атаками на отдельные цели.

Как защититься от атак на цепочку поставок

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

Контрольный список мер защиты для предприятий и организаций

• Внедрите политику спецификации программного обеспечения (SBOM) для всего программного обеспечения, которое ваша организация закупает или разрабатывает, чтобы вы могли идентифицировать затронутые компоненты при раскрытии компрометации цепочки поставок.
• Проверяйте практики безопасности сторонних поставщиков перед закупкой и ежегодно, используя стандартизированные опросники, соответствующие NIST SP 800-161r1.
• Требуйте от поставщиков предоставления актуальных SBOM для всех программных продуктов, поступающих в вашу среду, в рамках вашего процесса закупки и заключения контрактов.
• Применяйте принципы архитектуры нулевого доверия: обеспечьте соблюдение принципа наименьших привилегий для всего программного обеспечения и служб, внедрите микросегментацию сети для ограничения горизонтального перемещения и постоянно проверяйте, а не полагайтесь на сетевое расположение.
• Отслеживайте аномальное поведение в программном обеспечении от доверенных поставщиков, поскольку отклонения в поведении от известных базовых показателей могут указывать на скомпрометированное обновление, даже если подписи действительны.
• Проверяйте сертификаты безопасности поставщиков (SOC 2 Type II, ISO 27001) и включайте явные требования безопасности и обязательства по уведомлению об утечках в контракты с поставщиками.
• Следуйте руководству CISA по безопасности цепочек поставок)** и внедрите фреймворк NIST SP 800-161r1 (C-SCRM), чтобы распространить ваше управление рисками на сторонних поставщиков.
• Поддерживайте план реагирования на инциденты, который явно охватывает компрометации стороннего программного обеспечения, включая процедуры экстренной изоляции затронутого программного обеспечения в вашей среде.

Что такое спецификация программного обеспечения (SBOM)?

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

SBOM важен для безопасности цепочки поставок, поскольку он дает ответ на вопрос, на который организациям сложно ответить во время инцидента: «Затронуты ли мы?» Когда стало известно об атаке на SolarWinds, организациям без реестра программного обеспечения пришлось вручную проверять каждую систему, чтобы выяснить, используется ли в них Orion. Организации с актуальными SBOM-файлами могли напрямую выполнить запрос к своему реестру. Та же логика была применима и в ситуации с XZ Utils, когда инцидента едва удалось избежать: знание того, на каких серверах установлена конкретная версия библиотеки, определило разницу между несколькими часами реагирования и неделями неопределенности.

Указ Президента 14028 «Об улучшении кибербезопасности страны» (подписанный в мае 2021 года в качестве прямого ответа на атаку SolarWinds) обязал поставщиков программного обеспечения, поставляющих продукцию федеральному правительству США, предоставлять спецификации ПО (SBOM). CISA опубликовала руководство по внедрению SBOM как для производителей, так и для потребителей. Инструменты, включая SPDX, CycloneDX и Syft, могут автоматически генерировать SBOM из большинства баз исходного кода и образов контейнеров.

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

Архитектура нулевого доверия (Zero trust) снижает ущерб, который может нанести атака на цепочку поставок, применяя принцип «никогда не доверяй, всегда проверяй» к каждому запросу доступа, включая запросы от программного обеспечения, которое якобы исходит от доверенных поставщиков. Атаки на цепочку поставок успешны именно за счет использования неявного доверия. Нулевое доверие исключает это неявное доверие из уравнения.

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

Нулевое доверие — это философия безопасности и модель архитектуры, а не программный продукт, который можно приобрести. Основными авторитетными источниками являются Модель зрелости нулевого доверия CISA и NIST SP 800-207.

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

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

• Фиксируйте и блокируйте версии зависимостей во всех манифестах пакетов (package-lock.json, requirements.txt, Gemfile.lock), чтобы новая опубликованная вредоносная версия не могла быть автоматически загружена при следующей сборке
• Настройте систему сборки так, чтобы отдавать приоритет частным реестрам перед публичными, и зарезервируйте все внутренние пространства имен пакетов в публичных реестрах для предотвращения атак типа «путаница зависимостей» (dependency confusion)
• Запускайте автоматическое сканирование зависимостей при каждой сборке с помощью таких инструментов, как Dependabot, OWASP Dependency-Check или Snyk, чтобы выявлять известные уязвимые или подозрительные пакеты до того, как они попадут в продакшн
• Генерируйте SBOM для каждого релиза с помощью CycloneDX или Syft и храните его вместе с артефактами сборки, чтобы иметь поддающийся аудиту реестр компонентов для каждой развернутой версии
• Требуйте подписанные коммиты и применяйте правила защиты веток в основном конвейере сборки, чтобы предотвратить попадание несанкционированного кода в процесс сборки
• Проводите аудит сторонних пакетов перед их добавлением: проверяйте историю публикаций мейнтейнера, количество скачиваний, активность в репозитории и тот факт, не передавался ли пакет недавно новому владельцу

Безопасность цепочки поставок: Нормативные требования и требования соответствия

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

Нормативно-правовая база США

В Соединенных Штатах основным регуляторным триггером стал Исполнительный указ № 14028 «Об улучшении кибербезопасности страны», подписанный президентом Байденом 12 мая 2021 года непосредственно в ответ на атаку на SolarWinds и инцидент с Kaseya VSA. Указ № 14028 предписал поставщикам программного обеспечения, продающим свои продукты федеральному правительству США, предоставлять спецификацию программного обеспечения (SBOM) для своих продуктов. Он поручил NIST разработать руководство по безопасности цепочки поставок, а CISA — внедрить стандарты SBOM. Это требование распространяется на поставщиков федерального правительства. Оно не требует напрямую наличия SBOM от всех организаций частного сектора, хотя разработанные в его рамках стандарты получили широкое распространение в качестве требований к закупкам в корпоративном секторе.

Основным справочным техническим стандартом является NIST SP 800-161r1 («Практики управления рисками в цепочке поставок кибербезопасности для систем и организаций»), который расширяет стандартные системы управления рисками кибербезопасности, чтобы в явном виде охватить сторонних поставщиков, производителей и программные компоненты. C-SCRM (управление рисками в цепочке поставок кибербезопасности) в соответствии с NIST SP 800-161r1 требует от организаций проведения оценки рисков поставщиков, проверки происхождения программного обеспечения, обязательного предоставления SBOM при закупках и поддержания планов реагирования на инциденты, учитывающих компрометацию сторонних сторон. Публикация CISA «Защита от атак на цепочку поставок программного обеспечения» содержит практические рекомендации по внедрению, соответствующие требованиям EO 14028.

Нормативно-правовая база ЕС

Европейские организации сталкиваются с параллельными требованиями в рамках двух структур. Директива NIS2 (Директива по сетевой и информационной безопасности 2) требует, чтобы организации в критически важных секторах, включая энергетику, транспорт, здравоохранение и цифровую инфраструктуру, учитывали риски безопасности цепочки поставок в рамках своих обязательных обязательств по управлению рисками кибербезопасности. DORA (Закон о цифровой операционной устойчивости) применяется к организациям финансового сектора в ЕС и включает подробные требования по управлению рисками, связанными со сторонними поставщиками услуг ИКТ, непосредственно затрагивая векторы атак на цепочку поставок. ENISA (Агентство Европейского союза по кибербезопасности) является основным авторитетным источником для организаций ЕС, выполняя роль, аналогичную CISA в Соединенных Штатах.

Сводная информация о нормативных требованиях

Частые вопросы о атаках на цепочки поставок

Что такое атака на цепочку поставок?

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

Каковы примеры атак на цепочку поставок?

Самые значимые примеры атак на цепочку поставок с 2013 по 2024 год:

• SolarWinds (2020): бэкдор SUNBURST внедрен в обновления платформы Orion; затронул примерно 18 000 клиентов, включая более 100 правительственных учреждений США
• NotPetya (2017): разрушительный вирус-вайпер, распространенный через обновления бухгалтерского ПО M.E.Doc; нанес глобальный ущерб, оцениваемый в 10 миллиардов долларов
• Kaseya VSA (2021): REvil использовала уязвимость нулевого дня в VSA для доставки программ-вымогателей более чем 1 500 предприятиям через скомпрометированных поставщиков ИТ-услуг (MSP)
• XZ Utils (2024): двухлетняя кампания социальной инженерии едва не привела к внедрению SSH-бэкдора в инфраструктуру Linux по всему миру
• CCleaner (2017): вредоносное ПО Floxif затронуло 2,27 миллиона пользователей; вторая стадия атаки была нацелена на 40 крупных технологических компаний
• ASUS ShadowHammer (2019): обновление прошивки с бэкдором, подписанное действительными сертификатами ASUS, затронуло 500 000 пользователей
• 3CX (2023): первая подтвержденная атака типа «цепочка поставок на цепочку поставок»; затронула более 600 000 компаний через Lazarus Group

Как работает атака на цепочку поставок?

Атаки на цепочку поставок проходят по повторяющемуся сценарию:

1. Злоумышленник выбирает доверенного поставщика или программную зависимость, от которой зависит цель
2. Злоумышленник получает доступ к среде сборки, репозиторию кода или инфраструктуре обновлений этого поставщика
3. В легитимное программное обеспечение перед его распространением внедряется вредоносный код
4. Поставщик распространяет скомпрометированный продукт через свои обычные доверенные каналы
5. Цель устанавливает обновление, привнося угрозу внутрь своего периметра
6. Злоумышленник активирует плацдарм для шпионажа, кражи данных или доставки разрушительной полезной нагрузки

Какая атака на цепочку поставок является самой известной?

Атака SolarWinds (2020) широко считается самой значительной кибератакой на цепочку поставок в истории. APT29, приписываемая Службе внешней разведки России (СВР), внедрила бэкдор SUNBURST в обновления SolarWinds Orion, затронув примерно 18 000 клиентов, включая более 100 государственных учреждений США. Взлом оставался необнаруженным в течение примерно девяти месяцев и напрямую послужил причиной издания Указа № 14028 «Об улучшении кибербезопасности страны».

Почему атаки на цепочку поставок так опасны?

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

За последнее десятилетие участились и стали более изощренными атаки на цепочки поставок. Ежегодные отчеты ENISA об Обзоре угроз фиксируют атаки на цепочки поставок как устойчивую и растущую категорию угроз, с ежегодным ростом числа атак. Эта тенденция видна на самих инцидентах: от взлома Target в 2013 году, который стал возможен благодаря небольшому подрядчику по системам ОВК, до шпионской кампании SolarWinds в 2020 году, затронувшей правительство США, и почти произошедшего инцидента с XZ Utils в 2024 году, нацеленного на основную инфраструктуру Linux. Финансово мотивированные преступные группы также начали использовать методы атак на цепочки поставок, как показал инцидент с Kaseya: одна скомпрометированная платформа MSP затронула сотни клиентских организаций за несколько часов.

Как организациям защититься от атак на цепочки поставок?

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

• Внедрите политику спецификации программного обеспечения (SBOM) для ведения полного инвентарного списка программных компонентов и выявления затронутых систем в случае раскрытия информации о компрометации
• Требуйте от поставщиков предоставления SBOM и подтверждения наличия действующих сертификатов безопасности (SOC 2, ISO 27001) в качестве условий закупок
• Применяйте принципы архитектуры нулевого доверия: доступ с минимальными привилегиями, микросегментация сети и непрерывный поведенческий мониторинг
• Осуществляйте мониторинг программного обеспечения от доверенных поставщиков на наличие поведенческих аномалий, а не только на основе сигнатурных индикаторов
• Следуйте руководству CISA по безопасности цепочки поставок и приведите процессы оценки рисков поставщиков в соответствие с NIST SP 800-161r1 (C-SCRM)
• Поддерживайте план реагирования на инциденты, который явно охватывает компрометацию стороннего программного обеспечения

Примечания к публикации: (1) Внедрить схему структурированных данных FAQPage в разделе часто задаваемых вопросов и схему Article на полной странице, чтобы максимально повысить шансы на попадание в функции «Люди также спрашивают» и расширенные результаты. (2) Внешние ссылки в этой статье ведут на CISA, NIST, Mandiant, Kaspersky/Securelist, Wired, OpenSSF и Cisco Talos как на авторитетные источники. (3) Команда публикации должна добавить внутренние ссылки на связанный контент по кибербезопасности на этом сайте (руководства по атакам программ-вымогателей, объяснения архитектуры нулевого доверия, ресурсы по внедрению SBOM, руководства по управлению рисками поставщиков, обзоры APT-акторов угроз) перед развертыванием. На момент написания индекс сайта не содержал проиндексированных статей по кибербезопасности, поэтому размещение внутренних ссылок требует ручной проверки редакционной командой.