4 декабря 2023 г.
С начала года порядка 60% компаний финансового сектора сталкивались с атаками на цепочки поставок (supply chain attack). Средний ущерб от одного такого инцидента составил 3,6 млн рублей. Данная оценка включает прямые финансовые издержки и не учитывает потенциальные репутационные потери, а также штрафные санкции.
Отличительной особенностью атак на цепочку поставок программного обеспечения является получение доступа злоумышленником к целевой системе не напрямую, а через внедрение в продукт или компонент, который используется организацией. Поэтому проблемы безопасности в цепочке поставок могут возникать на любом этапе жизненного цикла программного обеспечения и вызываться различными причинами, начиная от злоумышленной вставки вредоносного кода сотрудником на этапе разработки, заканчивая компрометацией стороннего поставщика при использовании готовых решений или сервисов.
В большинстве случаев целью данной разновидности кибератак является получение доступа к конфиденциальной информации о клиентах, поэтому финансовый сектор представляет для злоумышленников наибольший интерес. После получения доступа к инфраструктуре банков кредитные и дебетовые карты клиентов становятся уязвимы для разных видов мошенничества с целью кражи денежных средств. Также атаки на цепочку поставок могут привести к нарушению производственного процесса и тем самым нанести ущерб репутации компании, поэтому часто затрагивают такие отрасли как нефтяная промышленность, крупный ритейл и сфера информационных технологий.
Примером наиболее «простой» атаки является намеренная опечатка. Злоумышленник создает репозиторий, повторяющий функционал оригинального, но содержащий включения уязвимого кода. Если разработчик совершит опечатку в названии библиотеки, например, jquery -> jquerry, то система сборки скачает уязвимый компонент.
Более сложным типом атаки является попытка подмены внутренней библиотеки через запутывание системы сборки. Если злоумышленник знает названия внутренних артефактов, то он может создать одноименный артефакт в публичном репозитории, добавив отметку, что это самая свежая версия. В этом случае система сборки может посчитать, что внешний артефакт более новый и использовать его при сборке.
Также стоит учесть возможные подмены артефактов через воровство «звездочек», отражающих репутацию и рейтинг проекта в сообществе разработчиков или полностью репозитория, а также создание дубликата удаленного репозитория, однако сейчас это уже менее актуально.
«Эффективно организовать безопасность цепочки поставок можно с помощью комбинированных средств защиты таких классов, как безопасная разработка, управление доступом и сетевая безопасность. Базовым инструментом такой экосистемы является практика SCA — анализ состава ПО на известные уязвимости, а также SCS — анализ безопасности цепочки поставок ПО, отражающий дополнительную информацию не только по самому артефакту, но и статистику по репозиторию и авторам. В ближайшее время наше решение Solar appScreener будет дополнено модулем SCS. Данные инструменты помогают офицерам ИБ оценить риски использования open source компонент без глубокого анализа кода каждого артефакта», — говорит Антон Прокофьев, эксперт по контролю безопасности ПО Solar appScreener ГК «Солар».
Усилить уровень безопасности цикла DevOps поможет анализ зрелости процессов информационной безопасности партнеров, а также разработка плана реагирования на случай возникновения атаки на цепочку поставок.
Источник: Пресс-служба компании «Солар»
