Компрометация одного подрядчика или поставщика программного обеспечения способна открыть злоумышленникам доступ к десяткам и сотням организаций. Такие атаки, как SolarWinds, Kaseya и 3CX, показали, что даже безупречная внутренняя защита не спасает, если уязвимость находится в цепочке поставок. Ниже разбираются ключевые риски, связанные с подрядчиками, и практические меры по их минимизации: от первичной оценки до непрерывного мониторинга и внедрения SBOM.
Как устроены атаки через подрядчиков
Атаки на цепочки поставок (supply chain attacks) отличаются от прямых взломов тем, что мишенью становится не конечная организация, а её доверенный партнёр — разработчик ПО, поставщик облачных услуг или подрядчик, обслуживающий IT-инфраструктуру. Злоумышленник компрометирует такого партнёра и через него получает доступ к клиентам.
История знает несколько громких инцидентов, которые стали хрестоматийными примерами. В конце 2020 года вредоносный код был внедрён в легитимное обновление платформы SolarWinds Orion, подписанное действующим сертификатом. В результате более 18 000 организаций, включая правительственные учреждения и крупные технологические компании, оказались скомпрометированы. В 2021 году через уязвимость в Kaseya VSA — инструменте для удалённого управления, которым пользуются MSP-провайдеры, — пострадали около 60 таких провайдеров и более полутора тысяч их клиентов. В 2023 году была атакована платформа корпоративной телефонии 3CX с аудиторией свыше 600 000 организаций: вредоносный код распространялся через официальный сайт компании.
Во всех случаях вредонос распространялся через легитимный канал обновлений или официальный сайт, что делало его практически неотличимым от обычной работы системы. Это ключевая особенность supply chain attacks: доверие к поставщику автоматически переносится на вредоносный код, распространяемый от его имени.
Первичная оценка поставщика
Безопасность цепочки поставок начинается с оценки подрядчика до заключения договора. Необходимо получить ответы на несколько ключевых вопросов: как организовано управление доступом, как часто проводятся тесты на проникновение, есть ли документированный план реагирования на инциденты, какие меры защиты данных применяются. CISA и NIST рекомендуют организациям использовать стороннее программное обеспечение в контексте программы управления рисками, которая должна включать формальный, общеорганизационный подход к управлению рисками кибербезопасности цепочки поставок (C-SCRM).
Для стандартизации этого процесса разработаны специализированные опросники. Один из наиболее авторитетных — Consensus Assessments Initiative Questionnaire (CAIQ) от Cloud Security Alliance. Он содержит набор вопросов, покрывающих 16 областей контроля и позволяющих документировать и оценивать безопасность облачных провайдеров. Для снижения трудозатрат можно использовать облегчённую версию CAIQ-Lite, которая включает около 73 вопросов в тех же областях контроля.
Чем глубже интеграция с подрядчиком, тем выше потенциальный ущерб от компрометации. Поэтому на этапе оценки необходимо чётко определить, какие данные, системы и сетевые сегменты будут ему доступны, и заранее ограничить этот доступ по принципу минимальных привилегий.
Требования в договоре
Результаты оценки должны быть зафиксированы в договоре. Помимо стандартных юридических условий, в него следует включить конкретные требования по безопасности: сроки уведомления об инцидентах, обязательство по проведению регулярных аудитов, право заказчика на проверку безопасности поставщика, а также обязательство по использованию определённых защитных мер. Это не бюрократическая формальность, а рабочий инструмент: при возникновении инцидента наличие таких пунктов упрощает взаимодействие и позволяет оперативно получить информацию, необходимую для расследования и восстановления.
Непрерывный мониторинг
Безопасность подрядчика — не статическая характеристика. Организация, успешно прошедшая аудит при заключении договора, может оказаться уязвимой через полгода. Поэтому оценку рисков необходимо периодически пересматривать, отслеживать новости о связанных с подрядчиком инцидентах, запрашивать актуальные отчёты о тестах на проникновение и аудитах. Доступ подрядчика к системам должен быть временным, с ограниченными привилегиями и с обязательной многофакторной аутентификацией. Регулярный пересмотр и отзыв неиспользуемых доступов — обязательная процедура.
SBOM как инструмент контроля
Одним из ключевых инструментов управления рисками цепочки поставок является Software Bill of Materials (SBOM) — структурированный перечень всех программных компонентов и зависимостей, включённых в продукт. SBOM обеспечивает базовую прозрачность, необходимую для управления рисками программной цепочки поставок. При обнаружении уязвимости в одном из компонентов SBOM позволяет быстро определить, затронута ли используемая версия, и принять меры до того, как уязвимость будет exploited.
С сентября 2026 года вступают в силу требования Cyber Resilience Act (CRA) Евросоюза, обязывающие производителей ПО уведомлять об активно эксплуатируемых уязвимостях и серьёзных инцидентах безопасности. К декабрю 2027 года полное соответствие, включая документацию, контроль жизненного цикла безопасности и SBOM, станет обязательным. Независимо от юрисдикции, внедрение SBOM становится стандартом для зрелых организаций.
Чек-лист для защиты от атак через подрядчиков
- Провести первичную оценку безопасности подрядчика с использованием стандартизированного опросника (например, CAIQ).
- Определить, какие данные и системы будут доступны подрядчику, и ограничить этот доступ по принципу минимальных привилегий.
- Включить в договор требования по безопасности: сроки уведомления об инцидентах, регулярные аудиты, право на проверку.
- Внедрить SBOM для всех критичных программных продуктов, используемых в инфраструктуре.
- Настроить многофакторную аутентификацию для всех учётных записей подрядчиков.
- Обеспечить временный характер доступа: привилегии предоставляются только на время выполнения задачи и автоматически отзываются.
- Проводить регулярный пересмотр доступов и аудит безопасности подрядчиков.
- Мониторить новости о связанных с подрядчиком инцидентах и требовать актуальные отчёты о тестах на проникновение.
Типовой сценарий: аудит подрядчика
Логистическая компания среднего размера перед внедрением новой системы управления складом провела аудит безопасности разработчика. На первом этапе использовали опросник, покрывающий управление доступом, защиту данных, управление уязвимостями и реагирование на инциденты. Разработчик не смог предоставить подтверждения проведения регулярных тестов на проникновение и не имел документированного плана реагирования на инциденты.
Компания выставила требования: в течение трёх месяцев пройти независимый пентест, разработать и согласовать план реагирования, а также внедрить SBOM для всех поставляемых компонентов. После выполнения этих условий был подписан договор с дополнительными оговорками о праве на ежегодный аудит безопасности поставщика. Через год при обнаружении критической уязвимости в одной из open-source библиотек, используемых в системе, наличие SBOM позволило логистической компании в течение нескольких часов определить, что уязвимый компонент в их версии отсутствует, и избежать экстренной приостановки работы склада.
Этот сценарий показывает, что даже при начальном несоответствии поставщика требованиям безопасности диалог и поэтапное внедрение защитных мер способны значительно снизить риски без отказа от нужного бизнесу инструмента.
Материалы канала ориентированы на специалистов по информационной безопасности и IT-руководителей. Подписывайтесь, чтобы получать актуальные методологии и разборы инцидентов.
Вопрос для обсуждения: Приходилось ли проводить аудит безопасности поставщиков или подрядчиков и с какими неожиданными проблемами сталкивались?