Содержание
Атака на цепочку поставок, или supply chain attack, — это кибератака через доверенного посредника. Им может быть разработчик ПО, подрядчик, облачный сервис или поставщик оборудования.
Вместо прямой атаки на инфраструктуру организации злоумышленник сначала компрометирует другое звено цепочки, а затем использует его доступ, продукт или инфраструктуру для проникновения к клиентам.
Что такое атака на цепочку поставок
В информационной безопасности цепочка поставок — это не только поставка оборудования. Понятие охватывает организации, сервисы и технологии, от которых зависит работа инфраструктуры.
Сюда входят разработчики программного обеспечения, поставщики облачных услуг, подрядчики, партнеры и производители устройств. К цепочке также относятся библиотеки, пакеты, системы обновления и инструменты разработки.
Ключевая особенность таких атак — использование уже существующего доверия. Например, организация разрешает приложению автоматически получать обновления, разработчики используют пакет из публичного репозитория, а администратор предоставляет подрядчику удаленный доступ.
Злоумышленник пытается встроиться именно в одну из таких доверенных связей.
При прямой атаке целью становится инфраструктура конечной организации. При supply chain attack сначала компрометируют промежуточное звено, после чего вредоносный компонент или несанкционированный доступ попадает к жертве через привычный канал.
Упрощенная схема выглядит так:
Злоумышленник → поставщик или разработчик → скомпрометированный продукт или сервис → компания-жертва.
Поэтому даже организация с развитой системой защиты может пострадать из-за слабого места у доверенного участника цепочки.
Как работают атаки на цепочки поставок
Сценарии различаются, но их общая логика часто похожа. Сначала злоумышленники выбирают организацию или сервис, которые имеют доступ к другим компаниям.
Это может быть разработчик распространенной программы или поставщик IT-услуг. Особенно привлекательны компании, продукты и сервисы которых используют многие клиенты.
Затем атакующие получают доступ к инфраструктуре поставщика. Для этого могут использовать фишинг, кражу учетных данных, эксплуатацию уязвимостей или компрометацию учетной записи разработчика.
Следующий этап — изменение доверенного объекта либо использование полученного доступа. Злоумышленники могут внедрить код в программу, библиотеку или обновление либо получить контроль над системой удаленного администрирования.
После этого измененный компонент попадает к клиентам штатным способом. Пользователь при этом может не совершать никаких подозрительных действий: например, обновление устанавливается автоматически средствами самой программы.
Далее вредоносный код может связываться с инфраструктурой атакующих, передавать данные, запускать команды или создавать дополнительный канал доступа.
Первоначальная компрометация нередко становится только точкой входа. После проникновения злоумышленники могут развивать атаку уже внутри инфраструктуры организации.
Типовая последовательность атаки
Выбирается поставщик или компонент, через который можно получить доступ к клиентам.
Компрометируется инфраструктура, программный компонент или учетная запись.
Изменяется программа, обновление, библиотека или другой доверенный объект либо используется штатный доступ поставщика.
Скомпрометированный компонент или доступ достигает конечной организации через легитимный канал.
Злоумышленники получают первичный доступ к инфраструктуре.
Начинаются дальнейшие действия: разведка, закрепление, кража данных или распространение внутри сети.
Какие элементы цепочки поставок могут быть атакованы
Цепочка поставок современной компании состоит из множества взаимосвязанных элементов, поэтому единой точки риска здесь нет.
Поставщики программного обеспечения
Злоумышленники могут атаковать исходный код, репозитории или инфраструктуру разработчика. Отдельной целью становятся серверы сборки и системы публикации обновлений.
Особенно опасна компрометация процесса выпуска новой версии. В этом случае вредоносный код может попасть в легитимный установочный пакет.
Для клиента такое обновление может выглядеть штатным: оно поступает через привычный канал распространения и устанавливается стандартными средствами продукта.
Сторонние библиотеки и зависимости
Современные приложения активно используют готовые пакеты, фреймворки и библиотеки.
Один проект может зависеть от большого количества внешних компонентов, часть которых, в свою очередь, имеет собственные зависимости.
Риск возникает при компрометации учетной записи автора, репозитория или механизма публикации пакета. Другой сценарий — распространение вредоносного пакета под похожим именем.
Отдельного контроля требуют SDK — Software Development Kit, плагины и модули, поскольку в зависимости от реализации они могут получать значительные права внутри приложения.
Облачные и IT-сервисы
Поставщик IT-услуг может управлять инфраструктурой нескольких клиентов. Его компрометация создает для злоумышленника возможность атаковать сразу несколько организаций.
К таким поставщикам относятся, например, MSP — Managed Service Provider, то есть поставщики управляемых IT-услуг. Риски также связаны с SaaS — Software as a Service, облачными панелями администрирования и средствами удаленного управления.
Чем больше систем доступно из одной учетной записи или административной панели, тем выше потенциальные последствия ее компрометации.
Подрядчики и партнеры
Внешние специалисты нередко подключаются к внутренним системам заказчика. Им могут выдавать VPN-доступ, учетные записи и административные права.
Риск возрастает, если такой доступ считается доверенным по умолчанию и не ограничивается по времени, системам и привилегиям. В этом случае компрометация подрядчика может привести к атаке на инфраструктуру заказчика.
Аппаратное обеспечение
Вмешательство в цепочку поставок возможно и до установки устройства в инфраструктуре организации. Объектами компрометации могут стать прошивка, контроллер или другой компонент оборудования.
Такие сценарии требуют отдельного контроля происхождения и целостности оборудования и встроенного ПО.
Рис. 1 Как доверенный компонент становится каналом атаки
Основные виды атак на цепочки поставок
Термин supply chain attack объединяет несколько техник, которые различаются точкой компрометации и способом доставки вредоносного компонента.
Компрометация обновлений ПО происходит на этапе выпуска или доставки новых версий. В результате пользователь получает измененный компонент как обычное обновление.
Заражение исходного кода происходит раньше: вредоносные изменения вносятся непосредственно в код проекта, а после сборки оказываются в готовом продукте.
Отдельной целью может стать CI/CD — Continuous Integration / Continuous Delivery — процессы автоматической сборки, проверки и выпуска программного обеспечения.
Получив доступ к инфраструктуре CI/CD, атакующий потенциально может влиять на процесс сборки и выпуска продуктов, а также получать доступ к секретам, используемым в соответствующих процессах.
Dependency confusion использует особенности разрешения программных зависимостей. Например, при некорректной конфигурации система может загрузить публичный пакет вместо внутреннего компонента с таким же именем.
Typosquatting основан на похожих названиях. Атакующий публикует пакет, имя которого похоже на название легитимной библиотеки и рассчитано на ошибку пользователя или разработчика.
Еще один сценарий — компрометация учетных данных поставщика. В таком случае злоумышленнику не требуется изменять программное обеспечение: он использует штатный доступ от имени доверенной организации.
Почему атаки на цепочки поставок особенно опасны
Основная проблема — доверие к источнику. Средства защиты могут видеть подписанную программу, разрешенный административный инструмент или подключение от известного поставщика.
Такая активность может выглядеть менее подозрительно, чем запуск неизвестного исполняемого файла или соединение с ранее неиспользуемого узла.
Вторая проблема — масштаб. Компрометация одного поставщика потенциально может затронуть множество его клиентов.
Дополнительный риск создают продукты с автоматическими обновлениями: измененный компонент может распространяться через штатный механизм установки.
Третья проблема связана с уровнем доступа. Корпоративное приложение может обрабатывать важные данные или работать с повышенными привилегиями. При его компрометации злоумышленник может попытаться использовать доступ, которым располагает само приложение.
Еще один фактор — сложность обнаружения. Если вредоносный компонент действует осторожно и использует легитимные процессы, его активность может долго не выделяться среди штатных событий.
Таким образом, безопасность организации зависит не только от собственной инфраструктуры, но и от внешних участников и компонентов, которым она доверяет.
Полностью исключить такие зависимости обычно невозможно. Поэтому задача состоит в том, чтобы ограничивать доверие, контролировать доступ и проверять поведение доверенных компонентов.
Известные примеры атак на цепочки поставок
Реальные инциденты показывают одну из основных особенностей подобных атак: злоумышленники используют привычный для организации канал доставки.
SolarWinds
Один из наиболее известных случаев связан с SolarWinds Orion. Вредоносный компонент был внедрен в процесс поставки обновлений программного обеспечения.
Клиенты получали скомпрометированную версию через штатную инфраструктуру распространения. Поэтому первоначальная установка выглядела как обычное обновление продукта.
Этот пример показывает важное ограничение цифровой подписи: она подтверждает происхождение и целостность подписанного объекта относительно момента подписания, но не гарантирует отсутствие вредоносных изменений, если был скомпрометирован сам процесс разработки или выпуска.
NotPetya и M.E.Doc
Другой известный пример связан с украинским бухгалтерским ПО M.E.Doc, механизм обновления которого использовался при распространении NotPetya.
Для организаций первоначальная доставка вредоносного компонента могла выглядеть как штатное обновление программы.
Последствия при этом не ограничивались одним приложением: дальнейшая вредоносная активность затрагивала инфраструктуру организаций.
Этот случай показывает, как компрометация поставщика программного обеспечения может стать начальной точкой более масштабного инцидента.
Вредоносные библиотеки и пакеты
Open-source-экосистемы также могут использоваться как канал атаки. Одна библиотека или пакет может входить в большое количество проектов.
Поэтому злоумышленнику необязательно атаковать каждый проект отдельно. Целью может стать зависимость, репозиторий или учетная запись разработчика.
Другой вариант — публикация вредоносного пакета. Его название может имитировать внутренний модуль либо отличаться от названия известной библиотеки несколькими символами.
Риск возрастает при автоматической установке зависимостей без контроля их происхождения и версий.
Как злоумышленники выбирают поставщика
Организация может вкладывать значительные ресурсы в информационную безопасность, но при этом зависеть от множества внешних партнеров с другим уровнем защиты.
Поэтому злоумышленник оценивает не только конечную цель, но и связанные с ней организации, сервисы и программные компоненты.
Небольшой подрядчик может оказаться привлекательной целью, если его специалисты обладают административным доступом к инфраструктуре крупного заказчика.
Потенциальную ценность поставщика для злоумышленника повышают:
большое количество клиентов;
удаленный доступ к их системам;
возможность распространять автоматические обновления;
доступ к конфиденциальным данным;
использование сертификатов и ключей подписи;
возможность управлять облачной инфраструктурой;
недостаточная защита собственной инфраструктуры.
Таким образом, компрометация одного поставщика потенциально может открыть путь к нескольким организациям.
Поэтому риски необходимо оценивать не только внутри собственного сетевого периметра.
Как обнаружить атаку на цепочку поставок
Такие атаки сложно выявлять, поскольку они могут использовать доверенные программы и учетные записи.
Поэтому особое внимание стоит уделять аномальному поведению разрешенного программного обеспечения и внешних пользователей.
Например, бухгалтерская программа может неожиданно запустить системный интерпретатор команд, а средство обновления — установить соединение с ранее неиспользуемыми узлами.
Проверки требуют и новые службы или задания, появившиеся после установки обновления, а также неожиданные изменения системных файлов.
Для учетных записей подрядчиков важно отслеживать время, источник и характер подключений. Вход с нового устройства или в нетипичное время сам по себе не доказывает компрометацию, но может требовать дополнительной проверки.
К возможным признакам относятся:
необычные сетевые соединения доверенных приложений;
новые процессы, службы и задания;
неожиданные изменения файлов после обновления;
неизвестные дочерние процессы легитимных программ;
изменение цифровой подписи или контрольной суммы;
появление новых зависимостей в программном проекте;
нетипичная активность учетной записи подрядчика;
неожиданные действия через средства удаленного управления.
События полезно анализировать в совокупности. Отдельный сетевой запрос или новый процесс редко позволяет однозначно определить атаку.
Однако сочетание нескольких аномалий может стать основанием для расследования.
Рис.2 Признаки возможной компрометации
Как защититься от атак на цепочки поставок
Единственного средства защиты от supply chain attack нет. Проблема затрагивает закупки, управление доступом, разработку и эксплуатацию.
Защиту следует выстраивать в несколько уровней, чтобы компрометация одного элемента не давала злоумышленнику неограниченный доступ к инфраструктуре.
Контролировать поставщиков
Оценку поставщика стоит проводить до выдачи доступа к системам и данным. Важно понимать, какие ресурсы он обслуживает и какие данные может обрабатывать.
Следует оценивать, как поставщик защищает административные учетные записи, организует обновления и реагирует на инциденты.
Глубина проверки зависит от уровня риска: требования к поставщику некритичных товаров и оператору значимого IT-сервиса будут различаться.
Требования к информационной безопасности можно закреплять в договоре. Например, определить порядок уведомления об инцидентах и правила предоставления удаленного доступа.
Ограничивать доверенный доступ
Даже проверенному подрядчику следует предоставлять только те права, которые необходимы для выполнения его задач.
Для этого используют принцип наименьших привилегий и ограничивают доступ нужными сегментами, системами и операциями.
Если инфраструктура позволяет, постоянный административный доступ можно заменить управляемым временным.
Сегментация сети дополнительно ограничивает последствия компрометации одной учетной записи или системы.
Контролировать программные зависимости
Команда разработки должна знать, какие сторонние компоненты входят в ее продукты. Учитывать нужно не только прямые, но и транзитивные зависимости — пакеты, которые устанавливаются как зависимости других компонентов.
Важно фиксировать используемые версии и контролировать происхождение пакетов. Автоматический переход на любую последнюю опубликованную версию может увеличивать риск неконтролируемого изменения состава приложения.
Для дополнительного контроля могут применяться внутренние репозитории с заранее определенным набором разрешенных компонентов.
Использовать SBOM
SBOM — Software Bill of Materials — перечень компонентов, входящих в программный продукт.
Он позволяет определить, какие библиотеки, пакеты и версии используются в приложении.
SBOM особенно полезен после появления информации об уязвимости или компрометации компонента: по перечню можно быстрее определить затронутые продукты и системы.
При этом сам SBOM не предотвращает атаку. Он приносит пользу в связке с процессами управления уязвимостями, зависимостями и обновлениями.
Защищать CI/CD
Системы разработки, сборки и выпуска программного обеспечения имеют высокий уровень доверия, поэтому доступ к ним следует строго контролировать.
Учетные записи разработчиков и администраторов необходимо защищать многофакторной аутентификацией. Секреты не следует хранить непосредственно в исходном коде.
Права на изменение кода и выпуск продукта целесообразно разделять. Для критичных операций можно использовать дополнительное подтверждение.
Также необходимо контролировать изменения сценариев и конфигураций сборки, поскольку их компрометация может повлиять на выпускаемый продукт.
Проверять обновления
Цифровая подпись помогает проверить источник и целостность файла, но не исключает компрометацию самого процесса выпуска.
Если злоумышленник получил контроль над инфраструктурой разработки или ключами подписи, вредоносный компонент может распространяться через легитимный канал.
Поэтому необходимо защищать всю цепочку выпуска: репозитории, сборочные системы, ключи подписи и инфраструктуру распространения.
Для критичных систем обновления целесообразно сначала проверять в тестовой среде и только затем устанавливать массово.
Многофакторная аутентификация и контроль учетных записей
MFA — Multi-Factor Authentication, или многофакторная аутентификация, особенно важна для внешнего и административного доступа.
Ее следует использовать для учетных записей администраторов, подрядчиков и сотрудников поставщиков, которым доступна инфраструктура заказчика.
При этом MFA не должна быть единственным средством защиты. Компрометация активной сессии, токена или избыточные права также могут привести к несанкционированному доступу.
Необходимо регулярно пересматривать учетные записи партнеров и отключать их после завершения работ или договора.
Отдельного контроля требуют API-токены, ключи доступа и сервисные учетные записи, которые могут работать без непосредственного участия пользователя.
Завершение договора с подрядчиком должно сопровождаться отзывом связанных учетных данных и прав доступа.
Мониторинг доверенных приложений и сервисов
Простого разделения программ и учетных записей на разрешенные и запрещенные для защиты от supply chain attack недостаточно.
Разрешенное приложение также может быть скомпрометировано, поэтому важно контролировать его фактическое поведение.
Следует отслеживать запускаемые процессы, сетевые соединения и изменения файлов, а также анализировать взаимосвязь между событиями.
На конечных устройствах для этого могут применяться EDR — Endpoint Detection and Response. Такие решения помогают фиксировать и анализировать действия процессов на рабочих станциях и серверах.
Для централизованного сбора и корреляции событий используют SIEM — Security Information and Event Management.
Однако сами инструменты не определяют, какое поведение является нормальным или подозрительным. Для эффективного обнаружения необходимо заранее формировать соответствующие сценарии мониторинга и правила анализа.
Рис.3 Многоуровневая защита цепочки поставок
Что делать при обнаружении компрометации поставщика
Информация о компрометации поставщика не означает автоматически, что инфраструктура заказчика также скомпрометирована. Однако такой инцидент требует проверки.
Сначала нужно определить, какие продукты, версии, сервисы и учетные записи этого поставщика используются в инфраструктуре.
Затем следует оценить связанные каналы доступа. При необходимости часть подключений можно временно ограничить до завершения проверки.
Практический порядок действий:
Найдите все связанные продукты, версии, сервисы и учетные записи.
При необходимости ограничьте удаленный доступ и другие потенциально опасные подключения.
Получите доступные индикаторы компрометации и рекомендации поставщика или профильных центров реагирования.
Проверьте журналы, процессы, файлы и сетевую активность.
Замените затронутые пароли, токены, ключи и другие учетные данные.
Установите исправленную или признанную безопасной версию продукта, если она доступна.
Проверьте инфраструктуру на признаки дальнейшего развития атаки.
Важно не ограничиваться удалением первоначального вредоносного компонента.
Если злоумышленники уже получили доступ к инфраструктуре, они могли создать дополнительные учетные записи, изменить конфигурацию или использовать другие механизмы закрепления.
Поэтому расследование должно охватывать не только исходную точку компрометации, но и последующую активность в инфраструктуре.
Чем атака на цепочку поставок отличается от других атак
Основное различие заключается в точке входа.
Фишинг направлен на пользователя: злоумышленник пытается заставить его открыть файл, перейти по ссылке или передать учетные данные.
Эксплуатация уязвимости предполагает использование ошибки в конкретном приложении или сервисе для прямой атаки на систему.
Атака на цепочку поставок использует организацию, продукт или сервис, которым компания уже доверяет. Это может быть поставщик программного обеспечения, подрядчик, библиотека или облачный сервис.
Поэтому набор защитных мер отличается. Например, обучение пользователей против фишинга не предотвращает установку скомпрометированного обновления через штатный механизм.
Установка исправлений также не решает проблему полностью, поскольку канал обновлений сам может оказаться объектом компрометации.
Для защиты цепочки поставок необходимо контролировать доверенные связи: понимать, кому и каким компонентам предоставлен доступ, какие действия им разрешены и как этот доступ контролируется.
Атаки на цепочки поставок и Zero Trust
Модель Zero Trust предполагает, что доступ не предоставляется только на основании местоположения пользователя или системы в доверенной сети.
Для защиты цепочки поставок этот принцип особенно полезен.
Если подрядчик работает с компанией много лет, его учетная запись все равно остается внешним каналом доступа и требует контроля.
Если программа выпущена известным разработчиком, это само по себе не означает, что ей необходим неограниченный доступ ко всем внутренним ресурсам.
Если обновление имеет корректную цифровую подпись, его поведение после установки также может контролироваться средствами защиты.
Zero Trust не означает автоматическое недоверие ко всем поставщикам. Практический смысл подхода — предоставлять доступ по необходимости, ограничивать его объем и контролировать действия.
Это помогает уменьшить последствия компрометации.
Например, захваченная учетная запись подрядчика при корректной сегментации и разграничении прав не должна автоматически предоставлять доступ ко всем сегментам инфраструктуры.
Как выстроить управление рисками цепочки поставок
Для системного управления рисками недостаточно один раз провести проверку поставщиков. Состав цепочки поставок меняется: появляются новые сервисы, партнеры и программные зависимости, обновляются продукты и права доступа.
Начать стоит с инвентаризации. Определите внешние организации, продукты и сервисы, которые влияют на критичные процессы.
Затем их можно классифицировать по уровню риска. Чем выше потенциальные последствия компрометации поставщика, тем строже должны быть требования к контролю.
Для значимых поставщиков важно понимать:
к каким системам они имеют доступ;
какие данные обрабатывают;
как обновляется используемый продукт или сервис;
какими средствами ограничиваются права доступа.
Параллельно необходимо учитывать программные компоненты, особенно при собственной разработке.
Следующий этап — связать сведения о поставщиках с процессами мониторинга. Тогда служба безопасности сможет оценивать не только факт внешнего подключения, но и его контекст.
Например, вход подрядчика в заранее согласованное время и в предназначенную для него систему может быть штатным. Аналогичный доступ к критичному сегменту вне утвержденного сценария требует проверки.
Так управление рисками становится постоянным процессом, а не разовой формальной проверкой поставщиков.
Рис.4 Жизненный цикл управления риском поставщика
Главное об атаках на цепочки поставок
Атака на цепочку поставок может начинаться за пределами инфраструктуры компании. Точкой входа становится организация, продукт или технология, которым она доверяет.
Компрометация одного поставщика потенциально может затронуть множество клиентов. Особого внимания требуют механизмы обновления, системы сборки, программные зависимости и административный доступ третьих сторон.
Полностью отказаться от внешних компонентов невозможно, поэтому основная задача бизнеса — контролировать доверенные связи и ограничивать последствия их компрометации.
Ключевые меры защиты — инвентаризация поставщиков, сегментация, принцип наименьших привилегий и MFA. Для процессов разработки важны контроль зависимостей, SBOM и защита CI/CD.
Отдельное внимание необходимо уделять мониторингу легитимных приложений и учетных записей. Доверенное происхождение само по себе не гарантирует безопасное поведение.
Чем точнее организация понимает состав своей цепочки поставок, тем быстрее она может определить, затрагивает ли ее новый инцидент у поставщика или в программном компоненте.
Атаки через поставщиков, подрядчиков, программные зависимости и доверенные сервисы необходимо учитывать при оценке угроз для информационной системы.
Специалисты «Комрунет» проводят моделирование угроз безопасности информации: выявляют возможные сценарии реализации угроз, анализируют потенциальные последствия и оценивают риски для информационной системы.
Результаты моделирования помогают определить актуальные угрозы и подобрать организационные и технические меры защиты с учетом архитектуры системы, используемого ПО и внешних связей.
FAQ
Что называется атакой на цепочку поставок?
Это атака через доверенного посредника или компонент. Им может быть поставщик ПО, подрядчик, библиотека, облачный сервис или устройство.
Злоумышленник сначала компрометирует такое звено, а затем использует существующую доверенную связь для атаки на конечную организацию.
Какие бывают атаки на цепочки поставок?
К таким сценариям относятся компрометация обновлений, исходного кода и инфраструктуры CI/CD.
Также возможны атаки через вредоносные библиотеки, dependency confusion, typosquatting и компрометацию учетных данных поставщика.
Почему supply chain attacks сложно обнаружить?
Вредоносный компонент может поступать через легитимный канал, запускаться внутри разрешенной программы или использовать доверенную учетную запись.
Поэтому недостаточно делить объекты только на разрешенные и запрещенные. Необходимо анализировать их фактическое поведение.
Может ли open-source-библиотека стать источником атаки?
Да. Риск возникает при компрометации проекта, учетной записи разработчика или механизма публикации пакета.
Дополнительную опасность представляют вредоносные пакеты с похожими именами. Поэтому программные зависимости необходимо учитывать и контролировать.
Что такое SBOM и как он помогает защититься?
SBOM — перечень компонентов и версий, входящих в программный продукт. Он помогает определить, где используется уязвимый или скомпрометированный компонент.
Сам по себе SBOM не предотвращает атаку. Его следует использовать вместе с процессами управления уязвимостями, зависимостями и обновлениями.
Как компании проверить безопасность своих поставщиков?
Сначала необходимо определить, к каким системам и данным имеет доступ поставщик. Затем следует оценить требования к аутентификации, управлению доступом, обновлениям и реагированию на инциденты.
Глубина проверки должна зависеть от риска и потенциальных последствий компрометации поставщика.
