Опасность и проблематика атак на цепочку поставок при разработке программного обеспечения стала одной из наиболее актуальных тем. Одновременно с ней был поднят вопрос о доверии к партнерам — поставщикам подсистем, подрядчикам — разработчикам компонент (кода) и т.п. Атаки на цепочку поставок рассматриваются как одна из наиболее актуальных угроз в сфере ИБ, ведь при успехе они создают уязвимости в системах ИБ организаций — пользователей этого программного продукта, которые используют злоумышленники. Такие атаки часто становятся успешными потому, что нацелены не против разработчика систем, который часто является крупной компанией с сильной системой ИБ, а против её партнеров (поставщиков), которые часто представляют собой небольшие компании, где основное внимание уделяется разработке и не тратится время на обеспечение защиты информации.

Что необходимо сделать для профилактики кибератак на цепочку поставок.

Кейс №1. Разбор атаки на цепочку поставок на примере разработчика автоматизированных банковских систем

(на основании отчёта ЦБР/ФинЦерт)

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

В результате анализа инцидента установлено, что первичный доступ в сеть компании был получен путем эксплуатации одной из уязвимостей в системе Confluence. После получения первичного доступа к этой системе была скомпрометирована учетная запись работника компании, затем последовала компрометация домена контроллера RDS. После этого произошла компрометация системы управления виртуализацией EXSI. Закрепившись в сети компании, злоумышленник начал атаку на организацию-заказчик из финансовой сферы. Используя скомпрометированную учетную запись сотрудника компании, атакующие установили ПО для туннелирования на компьютер сотрудника организации финансовой сферы. Затем через этот туннель на компьютер работника был установлен специальный Shell3, позволяющий получить удаленный доступ к компьютеру извне и дистанционно выполнять произвольные команды. Таким образом, атакующие получили прямой доступ в ИТ-инфраструктуру организации. На следующем этапе атакующие провели эскалацию внутри домена, что позволило получить доступ к компьютеру одного из сотрудников организации. Используя полученный доступ, атакующие сделали ряд снимков экрана в качестве доказательства успеха своей атаки. Снимки были опубликованы в телеграм-канале атакующих. Однако в ходе анализа инцидента факт утечки данных, несмотря на имеющийся доступ к компьютеру сотрудника организации, зафиксирован не был. Схема инцидента:

Апрель 2025 года. Весна, природа просыпается от зимней стагнации. В воздухе чувствуется скорее приближение теплого времени года. Все чаще слышу от коллег и партнеров опасения в отношении регулярно освещаемых СМИ кейсов и инцидентов с атаками на «цепочки поставок». Сценарии кибератак различаются по методам, подходам, инструментам и даже по времени и месту реализации, но, к сожалению, даже в самых простых и понятных кейсах фигурирует реальный ущерб. 
По коротким ссылкам ниже и в примерах, представленных во врезках в начале и в конце данного материала, можно ознакомиться с описанием актуальных кейсов с атаками на цепочки поставок:

1. Огрехи из-за прорехи: как и почему растут кибератаки на цепочки поставок;
2. Угон персональных данных: Hertz попал в киберДТП;
3. Хактивизм и атаки на цепочки поставок.

Можно (и нужно) ли компаниям в зоне риска превентивно составить план организационно-технических мероприятий и/или сформировать набор необходимых шагов (в плане информационной безопасности), последовательная реализация которых позволила бы избежать атаки на цепочку поставок и/или минимизировать для компании и ее партнеров негативный эффект от реализации подобных атак? Этот вопрос, сложный по формулировке и комплексный по своей сути не выходил долгое время у меня из головы. И на этот вопрос я попытаюсь дать свой экспертный ответ в данном материале. Преступим!..

Атака на цепочку поставок (supply chain attack)

Это сравнительно новый тип кибератаки, в процессе реализации которой злоумышленник предварительно изучает со стороны доступные ему процессы у потенциальной жертвы (чаще всего это связано с внешними коммуникациями и публично размещенной в Интернете информацией), выявляет всех участников и роли в этих процессах (поставщики, потребители, контрагенты, партнеры и пр.), выстраивает у себя логические цепочки, примерно понимая уровни доверия, зависимости и приоритеты для жертвы, находит в этих цепочках уязвимые компоненты и атакует именно эти компоненты. Тем самым злоумышленник нарушает целостность, доступность или конфиденциальность объекта защиты во всей цепочке/в процессе. Нарушение стабильности и непрерывности процесса взаимодействия с доверенными поставщиками услуг, в случае с атакой на цепочку поставок, наносит потенциальной жертве самый существенный ущерб: материальный, репутационный, стратегический, но чаще — комплексный. Таким слабым звеном в выбранном для атаки процессе может выступать поставщик программных компонентов или лицензий программного обеспечения, держатель доверенного внешнего депозитария исходного кода или библиотек, учетная запись работника для доступа в его личный кабинет, или уязвимость в настройках межсетевого экрана на периметре сети — для реализации атаки на цепочку поставок может использовать любой уязвимый компонент процесса (слабое звено в цепочке поставок). Есть примеры, когда используя скомпрометированную учетную запись или проэкплуатировав уязвимость в настройках, злоумышленники оказывались внутри защищаемого периметра, далее продвигались «горизонтально»/«вбок», получая тем самым доступ к более важным системам и данным, размещенным в том же сегменте сети.

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

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

За 2024 г. ФинЦЕРТ ЦБ РФ выявил 17 подтвержденных инцидентов ИБ у организаций, предоставляющих ИТ-услуги для более чем 70 компаний финансовой сферы, включая системно значимые кредитные организации. ФинЦЕРТ направил более 80 уведомлений финансовым организациям с информацией о компрометации инфраструктуры подрядчиков с целью принятия мер реагирования. Несмотря на информирование, в ряде случаев ФинЦЕРТ зафиксировал длительные по времени, распределенные и достаточно масштабные по последствия целевые атаки с инфраструктур подрядных организаций на инфраструктуру сторонних финансовых компаний.

Атаки на цепочки поставок считаются у злоумышленников максимально эффективными, поскольку эксплуатируют выстроенное ранее доверие в коммуникации между поставщиком и потребителем услуг. Например, многие ИТ-администраторы верят, что установка на периметре сети межсетевого экрана позволит защитить внутреннюю сеть организации от всех видов современных кибератак из Интернета. Часто такое доверие выстраивается не только в технической плоскости, но имеет юридические основания (подписанный сторонами договор, или публичное соглашение об использовании/предоставлении онлайн-сервисов, соглашение об уровне качества сервиса и т.д.). В обязательном порядке такое доверие предполагает использование принятого сторонами минимального уровня защиты информации. Но, к сожалению, как показывает практика ИТ-рынка — минимального уровня защиты часто недостаточно, чтобы избежать атак на цепочки поставок.

Кейс с GitHub демонстрирует, что даже техно-гиганты RnD-отрасли не застрахованы от ошибок и сбоев. Согласно опубликованным результатам расследования причин киберинцидента, в кейсе с GitHub злоумышленники скомпрометировали секреты CI/CD, внедрив вредоносный код в программные конвейеры. Результатом атаки на цепочку поставок стал «эффект водопада», который скомпрометировал бесчисленное множество нижестоящих приложений и служб потребителей сервисов GetHub по всему Миру, в т.ч. в РФ.

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

Масштаб и область применения

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

Стратегический долгосрочный ущерб

Если в графе/дереве поставщиков больше одного уровня (к примеру, распространение сервиса крупного поставщика происходит через сеть мелких ресейлеров, промежуточные репозитории или развитую дистрибьютерскую сеть), компрометация базового поставщика в основания графа (как в случае с GetHub), влечет за собой последовательную компрометацию всех промежуточных репозиториев и промежуточной сети дистрибьюции. Таким образом, даже при минимальных сроках устранения последствий инцидента на стороне источника в основании графа, потребуется время, чтобы провести аналогичные действия по устранению последствий атаки на всех элементах в сети дестрибьютеров сервиса или услуги. Именно поэтому, даже после исправления ситуации у базового источника компрометации последствия атаки могут и еще долго по времени и гарантированно (с точки зрения выстроенного сервиса) долетают до самых отдаленных от основания потребителей услуги в цепочке поставок. И потенциальный ущерб (например, если по сети поставок распространяется программный код с заложенным внутрь бэкдором) для отдельных потребителей услуги может наступить позже, чем для других потенциальных жертв, если своевременно не принять меры по минимизации угрозы атаки на цепочку поставок.

Сложность работ по минимизации ИБ-рисков (как превентивно, так и постфактум).

Обнаружение возможных признаков реализации атаки на цепочки поставок (к примеру, путем непрерывного мониторинга событий с признаками ИБ-инцидентов от всех систем-источников на стороне доверенных подрядчиков), а также смягчение/минимизация всех возможных вариантов последствий реализации подобных атак — объективно сложная задача со звездочкой, не имеющая однозначного решения с учетом ее распределенности и ограниченности ресурсов у информационной безопасности. 

Совершенно неприемлемо и непонятно, каким образом информационная безопасность в Вашей компании должна не только защищать свои собственные ИТ-активы, но и организационно или технически гарантировать, что каждый доверенный поставщик и партнер будет придерживается (как в моменте, так и на перспективу) строгих стандартов по защите информации в процессе непрерывного взаимодействия с Вашей организацией. Тут вполне уместно задаться вопросом, есть ли успешные примеры такого безопасного взаимодействия на отечественном рынке в 2025 году?!

Дополнительно математическая сложность подобной задачи усугубляется тем фактом, что многие российские компании не умеют/не хотят заниматься «дополнительным» управлением или мониторингом своих процессов взаимодействия с доверенными поставщиками, отдавая этот процесс на откуп юридическому отделу и/или бухгалтерии. Как следствие, руководители организации, ответственные за непрерывность бизнес-процессов и за безопасность ИТ-активов в компании не имеют представления об актуальном состоянии процессов и инструментов в собственных цепочках взаимодействия с поставщиками услуг. Отсюда и возникает высокий (в моменте, с точки зрения финансового ущерба и эмоционального воздействия на менеджмент) деструктивный эффект современных атак на цепочки поставщиков.

Если рассматривать не только статистику ЦБ РФ, но и обратить внимание на Мировые практики противодействия supply chain атакам, выделяются следующие типы организаций, которые в 2024 году чаще других подвергались подобным атакам.

Этот тренд сохраняется в 2025 году.

Кто в зоне риска?

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

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