Атаки на цепочки поставок в финтехе: масштаб ущерба в цифрах

По итогам 2024 года Банк России зафиксировал структурный сдвиг в картине кибератак на финансовый сектор: компрометация подрядных организаций вышла на первое место среди способов первичного проникновения в инфраструктуру кредитных организаций и платёжных систем. Глобальная статистика указывает на тот же тренд: около 60% компаний финансового сектора сталкивались с атакой через цепочку поставок программного обеспечения.

Фокус сместился с защищённого периметра банка на его менее заметные цифровые связи: IT-подрядчиков, разработчиков open-source-зависимостей и операторов критических сервисов. По данным IBM Cost of a Data Breach Report 2025, средняя стоимость утечки данных в финансовом секторе достигла $5,56 млн. Это второй показатель среди отраслей после здравоохранения. Если начальным вектором стала компрометация подрядчика, средний ущерб составляет $4,96 млн, а средний жизненный цикл инцидента достигает 258 дней.

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

Эволюция вектора атаки: от прямого взлома к компрометации подрядчиков

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

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

Механика обычно начинается с выбора подрядчика, у которого есть легитимный канал доставки обновлений или данных в банк. Это может быть разработчик мобильного приложения, поставщик антифрод-скоринга, оператор процессинга карт, провайдер KYC-проверки, интегратор CRM или разработчик модуля интернет-банка. Доступ к инфраструктуре подрядчика могут получить через фишинг, эксплуатацию уязвимости в публичном сервисе или учётные данные, ранее попавшие в утёкшие базы. Следующий шаг, внедрение вредоносного кода в артефакт, который банк получит обычным рабочим путём: обновление SDK, контейнерный образ, конфигурацию CI/CD-процесса или файл прошивки терминала.

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

Open-source-компоненты добавляют масштаб. Если скомпрометированная библиотека попадает в публичный реестр пакетов и её подключают потребители, вредоносное изменение может разойтись по множеству продуктов при обновлении зависимости. Цепочки второго и третьего порядка усложняют контроль: проект A зависит от B, B от C, C от D. Разработчик может не иметь полной картины того, чей код в итоге исполняется в банковской среде.

Масштаб финансовых потерь: что говорят цифры

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

Средний прямой ущерб в 3,6 млн ₽ в российской практике не равен полной цене инцидента. В указанную оценку не входят репутационные потери и штрафы регулятора; в ней также не следует автоматически предполагать учёт всех возможных последствий для клиентов или бизнеса. Показатель IBM в $4,96 млн относится к средней оценке ущерба в сценарии, где начальным вектором стала компрометация третьей стороны. Это отдельный показатель, его нельзя подменять средней стоимостью утечки данных в финансовом секторе в целом.

В российской статистике УЦСБ SOC и RED Security отмечен трёхкратный рост числа инцидентов через подрядчиков за последний год. Такая динамика говорит о том, что риск уже нельзя рассматривать как редкую техническую аномалию. При этом любой показатель зависит от состава выборки, способа классификации инцидентов и периода наблюдения. Статистика помогает увидеть направление, но сама по себе не показывает, насколько защищена конкретная интеграция.

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

Почему цепочки поставок стали «ахиллесовой пятой» банковского IT

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

Первая причина — архитектурная сложность. Финтех-система может интегрироваться с внешними сервисами для KYC, платёжных операций, антифрод-скоринга, CRM, BI, облачного хранения, SMS и push-уведомлений, аутентификации, биометрии и процессинга карт. Каждый такой узел расширяет цифровой периметр. Вопрос не только в том, насколько безопасен сам сервис, но и в том, какие данные и полномочия доступны ему через интеграцию.

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

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

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

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

Жизненный цикл инцидента: почему он занимает в среднем 258 дней

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

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

Условно этот процесс можно разделить на восемь этапов:

1. Разведка. Выбор подрядчика с техническим каналом доставки данных или кода в банк, сбор сведений о его сотрудниках, технологиях и публичных сервисах.

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

3. Закрепление у поставщика. Попытка внедрить вредоносное изменение в артефакт, который будет передан заказчику: например, обновление SDK, контейнерный образ, конфигурацию CI/CD или пакет прошивки.

4. Доставка в инфраструктуру банка. Вредоносный компонент попадает в банковскую среду через предусмотренный канал обновления, API-интеграцию, VPN или репозиторий.

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

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

7. Локализация. Банк ограничивает доступ, отзывает сертификаты и ключи подрядчика, проверяет связанные системы и при необходимости откатывает обновления.

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

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

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

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

Стратегии минимизации рисков при работе с внешними вендорами

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

Инвентаризация зависимостей и SBOM. Software Bill of Materials описывает компоненты программного продукта, включая транзитивные зависимости. Такой перечень помогает установить, какие версии библиотек используются в рабочей среде, и быстрее определить, касается ли организация уязвимости или компрометации конкретного компонента. Форматы CycloneDX и SPDX можно использовать для передачи этой информации между разработчиком и заказчиком.

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

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

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

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

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

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

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

Позиция

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

Определить риск по одному показателю невозможно. Средняя стоимость ущерба в $4,96 млн и средний жизненный цикл в 258 дней описывают результаты исследования IBM для соответствующего сценария, а не гарантированный исход следующего инцидента. Но эти значения напоминают о цене слепых зон: если банк не видит состав зависимостей, не ограничивает права подрядчиков и не может быстро обменяться с ними технической информацией, расследование осложняется ещё до того, как началась атака.

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