Атаки через цепочку поставок: чек-лист из 5 мер защиты и противодействия
Компания-разработчик мобильного приложения, онлайн-бухгалтерия и менее очевидные поставщики, например, авторы кода, опубликованного в открытом доступе на GitHub, могут стать «точкой входа» для хакеров. По нашим данным, в 2025 году атаки через цепочку поставок составляли 25-30% от общего числа инцидентов. Руководитель департамента развития и архитектуры Кросстеха Евгений Балк и пентестер Тимофей Катков собрали чек-лист, который поможет снизить риски подобных атак:- □ Проверка поставщиков перед стартом работы и в процессе
- □ Принцип «нулевого доверия» (Zero Trust)
- □ Проверка работоспособности процессов безопасной разработки (DevSecOps) у себя и подрядчика
- □ Прозрачность действий поставщиков
- □ Учёт поставщиков в плане реагирования на инциденты
Подробнее о каждом пункте — ниже.
1. Проверка поставщиков перед стартом работы и в процессе
До начала сотрудничества узнайте о поставщике больше: был ли он вовлечен в инциденты ИБ? Есть ли у него сертификаты соответствия отраслевым стандартам (ISO/IEC 27001)? Запросите информацию о его подходе к кибербезопасности: есть ли свое подразделение ИБ, осуществляется ли передача событий ИБ в SOC, проводятся ли регулярные внутренние и внешние пентесты?
Для программных продуктов и облачных сервисов запросите данные об уязвимостях, результаты пентестов или динамического анализа кода (DAST).
Включите в договоры с поставщиками конкретные требования по ИБ: проведение регулярных аудитов, соблюдение ваших ИБ-требований и протокола уведомления об инцидентах.
2. Внедрение принципа «нулевого доверия» (Zero Trust)
Подход предполагает, что никакие системы, пользователи или программы не могут считаться безопасными по умолчанию. Как только мы даем подрядчику доступ к инфраструктуре, взаимодействие с ним должно происходить по принципу нулевого доверия.
На практике Zero Trust реализуется через:
- Принцип минимальных привилегий: доступ предоставляется только тем пользователям и процессам, которым он действительно необходим.
- Форсирование аутентификации — каждый запрос на доступ к сервису проходит полную проверку личности, местоположения, состояния устройства и контекста.
- Многофакторную аутентификацию (MFA) — добавляет уровни защиты помимо пароля, например TOTP-приложения, SMS, токены или даже биометрию.
- Мониторинг активности в реальном времени для выявления подозрительного поведения.
- Сегментацию (в идеале вплоть до микросегментации) — сеть делится на мелкие сегменты, что ограничивает перемещение хакеров в случае проникновения. Они оказываются «запертыми» внутри взломанного сегмента.
3. Проверка работоспособности процессов безопасной разработки (DevSecOps) у себя и подрядчика
Рекомендации из этого раздела будут полезны тем, кто разрабатывает собственное ПО.
- Внедряйте в CI/CD решения для анализа исходного кода, которые позволяют обнаруживать уязвимости ещё на этапе разработки. В идеале — дополните их ручным аудитом с привлечением эксперта.
- Регулярно сканируйте используемые библиотеки и зависимости, включая open source, на наличие уязвимостей с помощью инструментов для композиционного анализа (SCA/OSA).
- Ведите SBOM (Software Bill of Materials) — полный список всех компонентов программного обеспечения (ПО), регулярно сопоставляйте компоненты с перечнем уязвимостей CVE.
- Фиксируйте версии зависимостей в lock-файлах и используйте только доверенные источники.
- Для критичных систем рассмотрите возможность развёртывания внутреннего реестра пакетов, чтобы контролировать, что попадает в инфраструктуру.
- Проверяйте целостность получаемого ПО или кода (цифровая подпись, хэши) на всём этапе разработки в конвейре CI/CD.
- Анализируйте его на безопасность с помощью SAST, DAST, SCA.
- Не забывайте о RBAC (ролевой модели доступа) в таск-трекерах и базах знаний.
4. Прозрачность действий поставщиков
Обеспечьте видимость всех действий: убедитесь, что в сегменте сети, куда предоставляется доступ подрядчикам, реализованы мониторинг событий ИБ и управление инцидентами с использованием SIEM и SOAR для корреляции событий и выявления угроз.
Доступ подрядчиков предоставляется с использованием PAM в установленное в соответствии с договором время. Если подрядчики используют собственные устройства, то на них необходимо устанавливать свои доверенные клиенты удалённого доступа с возможностью проверки комплаенса устройства.
5. Учёт поставщиков в плане реагирования на инциденты
Самый простой подход — отключение поставщика от систем компании, когда возникает угроза, но он не позволит найти «слепые зоны» вашей безопасности.
Более перспективные сценарии:
- Пентест, в ходе которого можно отработать сценарий атаки на цепочку поставок. Пентестеры проверят доступы, права и разрешения.
- Аутсорс процессов DevSecOps. Поверку кода и компонентов можно передать ИБ-интегратору с профильной экспертизой. Это позволит сэкономить ресурсы вашей команды ИБ и бюджет на наём профильных экспертов.
- Совместные киберучения и привлечение вашей службы ИБ к аудиту процессов ИБ поставщика.
