Еще в 2023 году компания Cybersecurity Ventures прогнозировала, что в 2025 году мировые потери от хакерских атак на цепочку поставок превысят 60 миллионов долларов. Злоумышленники взламывают крупные компании через их сервис-провайдеров. Это приводит к финансовым и репутационным потерям, а также к штрафам со стороны регуляторов. Главная мишень преступников — средний бизнес, который поставляет продукты и услуги крупным организациям и не имеет надежной системы безопасности.
В статье разберем, как выстроить управление безопасностью поставщиков и что делать компаниям с ограниченным бюджетом на кибербезопасность.
Что такое атака на цепочку поставок
Крупные компании обычно содержат собственные службы информационной безопасности. Их специалисты обеспечивают высокий уровень защиты информационных систем от взлома. Поэтому злоумышленники ищут легкие пути компрометации и атакуют поставщиков. Возникает парадокс: компания выстраивает сложную систему безопасности с высоким уровнем защиты, но при этом не имеет достаточного влияния на защищенность подрядчиков и поставщиков. В результате злоумышленники попадают в нее через уязвимости стороннего сервиса.
Популярная тактика атаки на цепочку поставок — внедрение уязвимости в программное обеспечение. Например, в бухгалтерское ПО, софт для видеоконференций, электронного документооборота и других задач бизнеса. Если у вендора слабая защита, хакеры компрометируют его среду разработки и внедряют несанкционированные зловредные изменения в код.
Такой вид киберугрозы получил название «Software Supply Chain Attacks», что в переводе и значит «атака на цепочку поставок программного обеспечения».
Сегодня компании часто используют открытое программное обеспечение, которое, как показывает пример, также подвержено атакам. Коммерческие решения могут содержать компоненты с открытым исходным кодом, которые могут быть небезопасными.
Второй успешный вид атак на цепочку поставщиков — компрометация их ИТ-инфраструктуры, кража учетных данных и паролей взаимодействия с клиентами сервис-провайдера, а также получение несанкционированного доступа к системам самих клиентов.
На третье место можно поставить атаки на аппаратное обеспечение и физические цепочки поставок. Это когда несанкционированное изменение в прошивке или компоненте вносится на этапе производства или транспортировки оборудования.
Какие проблемы приносят небезопасные поставщики
Конечная цель атаки на поставщика — компрометация инфраструктуры клиентов его продуктов или сервисов, нарушение их бизнес-процессов и кража чувствительных данных. Риски для бизнеса очевидны:
- Финансовые потери. Например, штрафы регуляторам, расходы на расследование инцидента и восстановление системы, выплаты компенсаций клиентам.
- Юридические проблемы. Дополнительные проверки регуляторов, судебные иски от клиентов и партнеров, возможная административная ответственность руководства за недостаточную защиту данных.
- Репутационные потери. Даже если компания быстро справилась с инцидентом, новость остается в публичном поле. Клиенты могут перейти к конкурентам, а партнеры — пересмотреть условия сотрудничества.
Таких последствий проще избегать, чем ликвидировать их, — как именно, разберем ниже.
Как безопасно взаимодействовать с поставщиками
Чтобы снизить вероятность взлома через поставщика, компании нужно настроить процесс по его выбору, контролю и проверке. Вот какие этапы стоит в него включить.
1. Планирование
Компания решает, какие функции или функциональность готова отдать поставщикам, а какие оставить внутри. Критичные бизнес-процессы — например, работу с платежными данными, лучше контролировать самостоятельно, чтобы их защищала внутренняя система безопасности. Если речь про софт, нужно определиться между опенсорс-решениями, коммерческими вариантами и самостоятельной разработкой.
2. Выбор поставщика
Компания оценивает потенциальных кандидатов. Служба безопасности должна изучить, кто является владельцем компании-поставщика или вендора, насколько подрядчик стабилен и финансово устойчив на рынке, есть ли у него ресурсы для развития, поддержки и защиты продукта или услуги. Проверка дополнительно страхует от ситуации, при которой через полгода поставщик исчезнет и оставит клиентов без поддержки.
При выборе вендора полезно провести мини-аудит процессов безопасной разработки программного обеспечения. В качестве критериев оценки можно выбрать ГОСТ 56939-2024. Это хороший стандарт, который можно использовать как источник правильных вопросов. Например, узнать, как компания разрабатывает и тестирует код, как управляет уязвимостями, как реагирует на инциденты.
Важно провести SBOM-анализ — узнать, какие библиотеки, фреймворки и компоненты поставщик использовал при разработке, нет ли среди них уязвимых решений. Кроме того, если продукт построен на старых технологиях, при обнаружении уязвимости поставщик, скорее всего, не сможет быстро выпустить новую исправленную версию. Также на этом этапе необходимо проверить, как быстро поставщик выпускает обновления безопасности и насколько эффективно реагирует на инциденты.
При выборе поставщика услуг полезно понять, каким образом у него выстроена система обеспечения информационной безопасности, какие процессы и средства защиты внедрены. Важно обратить внимание на защиту системных компонентов, которые обеспечивают взаимодействие с вашей инфраструктурой.
3. Тестирование и передача в эксплуатацию
И для ПО, и для сервисов необходимо безопасно настроить системное и сетевое окружение для взаимодействия с поставщиком на уровне межсетевых экранов, маршрутизаторов, систем виртуализации и контейнеризации, ОС, СУБД, сервисов обновления и технической поддержки. Если у компании нет экспертизы для настройки, стоит привлечь интегратора. Кстати, интегратор — это тоже поставщик, и его также нужно проверить.
Все взаимодействия со сторонними ИС — например, интеграция с LLM-моделью, и пользователями — например, для техподдержки, необходимо идентифицировать, аутентифицировать и строго ограничивать по принципу минимальных привилегий для выполнения необходимых задач. Двухфакторная аутентификация, регулярная смена паролей, аудит системных и пользовательских учетных записей, логирование всех действий всех объектов доступа защищают от взлома через поставщика услуг.
До внедрения ПО в продуктивный контур компания должна провести его проверки безопасности в тестовой среде. Особенное внимание нужно уделить свободно распространяемому ПО (open source) и самостоятельно провести статическое сканирование кода. При необходимости — динамические тесты и фаззинг. Для коммерческого ПО глубина проверок определяется на этапе выбора поставщика. Если компания не уверена в безопасности его разработки, но выбирает его решение для эксплуатации внутри организации, полезно стремиться к объему тестов, который сравним с open source.
4. Эксплуатация
В период взаимодействия с поставщиком услуг важно:
- отслеживать его действия в информационных системах;
- контролировать минимально необходимые права доступа;
- периодически проверять безопасность подрядчика — не только информационную, но и экономическую. Например, при смене учредителей новое руководство может изменить внутренние процессы безопасности вендора и повлиять на продукт или сервис.
В части ПО важно помнить, что обновления — основной канал, через который в него доставляются уязвимости. Поэтому новые версии также должны быть покрыты тестами безопасности.
5. Завершение работы
Когда компания прекращает взаимодействие с подрядчиком, она должна заблокировать все учетные записи и закрыть доступы на сетевом уровне. Нужно убедиться, что теперь бывший поставщик не сможет попасть в ваш ИТ-периметр или негативно на него повлиять.
Смена или отказ от ПО — обычно более сложный процесс. Он должен сопровождаться процедурами планирования, оценки зависимостей с другим ПО или ИС, миграции, резервирования, архивирования и, при необходимости, удаления данных. С точки зрения безопасности нужно урегулировать лицензионные вопросы, а также гарантированно прекратить сетевое и информационное взаимодействие с внешними ресурсами и сотрудниками вендора.
Как среднему бизнесу контролировать кибербезопасность поставщиков
У среднего бизнеса обычно нет ресурсов, чтобы содержать отдел информационной безопасности или ездить к подрядчикам с аудитом. При этом такие компании тоже являются целями злоумышленников, потому что через них взламывают крупных клиентов. Есть несколько советов, которые помогут снизить риски.
Выбирать облачные решения
У крупных провайдеров облачных сервисов достаточно ресурсов для защиты инфраструктуры. Они быстро реагируют на инциденты и следят за резервным копированием данных. Если происходит сбой, такие компании восстанавливают работу быстрее, чем средняя организация самостоятельно. Крупного поставщика облачного сервиса тоже нужно проверить — это должен быть надежный провайдер с хорошей репутацией.
Больше про облачные решения и их безопасность читайте в статье о том, что такое SaaS-продукты и зачем они нужны бизнесу.
Разрабатывать план восстановления
Даже если компания сделала все, чтобы снизить риски, она должна быть всегда готова к инциденту. Например, можно заранее:
- настроить резервное копирование важной информации;
- распределить приоритеты при исправлении проблемы;
- прописать действия для сотрудников и контакты ответственных лиц.
Помимо этого, компания должна понимать, сколько времени может работать без скомпрометированного цифрового сервиса. Исходя из этого времени, ей нужно планировать скорость восстановления процессов и данных, которые затронет инцидент.
Разделять ответственность
Заключите с поставщиком SLA — соглашение об уровне обслуживания. Четко пропишите в нем метрики оказания услуги и/или параметры сопровождения ПО.
Для вендора это могут быть:
- Классификация обращений в техническую поддержку. Например, сбой функционала уровня А — высокая критичность, сбой функционала уровня Б — средняя критичность.
- Гарантированное время реакции на обращение в зависимости от его критичности и время решения обращения.
- Условия предоставления доступа к обновлениям и обязательство выпускать обновления безопасности в установленные сроки. Например, закрывать критичные уязвимости за 24 часа.
- Сроки поддержки предыдущих версий ПО.
- Гарантии совместимости ПО с другими платформами и софтом, обязательства по обеспечению совместимости при выпуске новых версий ПО.
- Условия предоставления доступа к коду, к проектной и эксплуатационной документации.
Для сервисов важно обратить внимание на гарантированное время их доступности, время устранения инцидентов в зависимости от их критичности, возможности взаимодействия со смежными сервисами — например, доступ к API-серверам, внешним LLM и решениям облачных провайдеров.
Чем понятнее разграничены зоны ответственности, тем меньше недопониманий будет при сбое или инциденте.
Частые вопросы
Полностью исключить риски невозможно. Инциденты происходят даже в крупных компаниях с отточенными процессами безопасности. Зато можно снизить вероятность атаки и заранее подготовиться к возможному инциденту, быть готовым к раннему обнаружению, быстрому реагированию и восстановлению.
Контролировать поставщиков нужно на протяжении всего сотрудничества. Провайдеров критичных для бизнеса сервисов и разработчиков ПО для важных информационных систем стоит проверять ежегодно методом удаленного аудита. Для менее важных систем достаточно отслеживать новости об инцидентах, связанных с компанией, и контролировать общедоступную информацию из официальных источников.
Это тревожный звоночек. Открытый диалог — показатель зрелых процессов и честного сотрудничества. Компания, которая что-то скрывает, при инциденте вряд ли предоставит полные данные со своей стороны. Поэтому лучше выбрать другого подрядчика.
Да, если хотите запросить детальную информацию о процессах разработки, архитектуре системы или известных уязвимостях. Договор нужен для спокойствия поставщика — с ним он сможет открыто рассказать о своих подходах, не опасаясь, что информация утечет к конкурентам.
Поставщики облачных бизнес-сервисов берут на себя их полное обслуживание и предоставляют пользователю прикладной функционал без необходимости заботиться о его инфраструктурном обеспечении. Помимо шагов, описанных выше, при проверке обратите внимание на ЦОДы, в которых размещен сервис, узнайте об их мерах безопасности. Запросите у поставщика подробности работы сервиса, как и что устроено «под капотом». Не забудьте изучить условия SLA — соглашения об уровне обслуживания и узнать, как быстро восстанавливается сервис при сбоях.
Подробнее о кибербезопасности для бизнеса читайте в этой статье.
Принцип нулевого доверия означает, что по умолчанию компания не доверяет внешним подрядчикам. Если для работы поставщику нужен доступ к внутренней системе компании, она ограничивает его права ровно теми, которые нужны для выполнения задач. А еще регулярно проверяет его действия и контролирует уровень доступа. Этот принцип в работе с поставщиками дополнительно защищает компанию от злоумышленников.
Что в итоге
- Компания должна контролировать безопасность поставщиков не только в начале сотрудничества, но и во время него.
- Крупный бизнес может позволить себе выездные аудиты поставщиков и содержание отдела информационной безопасности. Среднему бизнесу лучше выбирать облачные решения от крупных и надежных провайдеров и подготовить стратегию по восстановлению после инцидентов.
- Главное правило компании для безопасной работы с поставщиками — самостоятельно оценивать риски и выстраивать защиту, исходя из критичности бизнес-процессов.
- Битрикс24 выстраивает защиту данных на всех уровнях — от разработки до эксплуатации. Подробнее о безопасности в Битрикс24 рассказывали в статье.
