Управление киберрисками в цепочке поставок требует комплексного подхода. Для браузера это означает использование безопасного доступа, обеспечивающего криптографическую защиту при подключении к системам поставщиков. Атаки через цепочку поставок (Supply Chain Attack) уже не редкость, а устойчивый тренд. Злоумышленники все чаще выбирают подрядчиков и партнеров как слабое звено — проще взломать их и получить доступ к крупным заказчикам. В условиях 2025 года бизнесу приходится не только защищать свою инфраструктуру, но и управлять рисками за ее пределами: в ИТ-среде подрядчиков, интеграторов и SaaS-провайдеров. Cyber Media разбирает, как это делать эффективно, особенно если партнер — небольшая компания без зрелой ИБ-функции.
За последние пару лет Supply Chain Attack перестали быть экзотикой — они стали рутиной. В 2023–2025 годах взломы через цепочку поставок регулярно попадали в заголовки: от компрометации облачных сервисов до атак на логистические компании, через которые хакеры получали доступ к крупным корпорациям.
Классическая модель «защищаем только свой периметр» здесь бессильна. Можно построить идеальную ИБ-стену внутри компании, но если подрядчик с доступом к вашим системам держит «систему с кодом 0000» — вы уже в зоне риска.
Под прицелом — не только разработчики ПО. Часто это ИТ-аутсорсеры, перевозчики, облачные провайдеры и даже компании, отвечающие за техподдержку. Атака через слабое звено в цепочке поставок позволяет обойти все ваши внутренние барьеры — быстро, тихо и с минимальными шансами быть замеченной.
Задача ИБ-специалиста теперь не только держать оборону у себя, но и следить, чтобы весь «караван» двигался с одинаковым уровнем защиты. Иначе один незащищенный «вагон» может потопить весь поезд.
Когда атаки через цепочки поставок становятся нормой, подход «запросили анкету, получили галочки, выдохнули» перестает работать. Чек-листы и Excel-файлы хорошо подходят для первичной сортировки, но в 2025-м они скорее создают иллюзию контроля, чем реальную защиту.
Раньше проверка подрядчика сводилась к паре звонков и копии сертификата ИБ. Сегодня этого недостаточно: злоумышленники могут атаковать через самого «чистого на бумаге» партнера. Современный due diligence — это смесь юридической, технической и операционной разведки: от анализа финансовой устойчивости компании до поиска утечек их данных в даркнете. Цель — понять не только «что написано в политике ИБ», но и «как это работает в реальности».
Ярослав Яцкевич
Аналитик информационной безопасности SkyDNS
В 2025 году подход к оценке ИБ-рисков поставщиков стал глубже и точнее. Сейчас уже недостаточно просто заполнить чек-лист или опросник, сейчас применяются методы, основанные на реальных данных или Evidence-based C-SCRM, что означает управление рисками в цепочке поставок. Каждый поставщик оценивается по важности его продукта, текущим угрозам и уровню зрелости его защиты: как организованы процессы, какие технологии применяются, и насколько стабильна система управления ИБ.
Чтобы картина была объективной, используют внешние рейтинги безопасности, проверяют список компонентов программного обеспечения (SBOM), проводят тесты безопасности процессов разработки (CI/CD). Все чаще заказчики интересуются, как подрядчик защищает код, обновляет зависимости и насколько быстро может заблокировать учетку при компрометации.
Регуляторы тоже ужесточили правила: директива NIS2 и регламент DORA обязывают учитывать цепочку поставок в общей стратегии безопасности. Это означает, что оценка подрядчиков больше не разовая формальность, а непрерывный процесс управления рисками.
Например, в 2024 году была зафиксирована масштабная утечка данных клиентов Burger King в России через подрядчика — компанию Mindbox, которая обрабатывала данные программы лояльности. В результате злоумышленники получили доступ к персональной информации тысяч пользователей.
Николай Гончаров
Директор Департамента мониторинга кибербезопасности Security Vision
В современных условиях правильнее использовать не точечную оценку, а проводить непрерывный мониторинг возможных рисков поставщиков. Для этого хорошо подходит гибридный подход, сочетающий оценку не только технических рисков, но и организационную зрелость самого поставщика в части безопасности, управления инцидентами и способности к восстановлению, а также оценку потенциального возможного вреда и денежного, операционного, репутационного ущерба при возникновении недопустимых событий. При проведении due diligence подрядчиков компании необходимо должное внимание уделять оценке возникновения потенциальных киберрисков, недопустимых событий и последствий от их реализации.
Сегодня важно не просто «собрать галочки», а понять, насколько подрядчик реально способен противостоять угрозам. Для этого используют:
В результате риск-оценка перестает быть «раз в год», а превращается в живой процесс, где изменения у подрядчика видны почти сразу.
Иногда подрядчик оказывается не готов к вашим полным требованиям по безопасности. Не из-за отсутствия желания, а потому что ресурсов мало: один человек отвечает за все IT, бюджет минимальный, процессы почти не расписаны. Если в такой ситуации загрузить на партнера весь комплект из ISO или NIST, результат будет обратный — вместо повышения защищенности вы получите сопротивление и формальное выполнение.
Никита Леокумович
Руководитель управление цифровой криминалистики и киберразведки Angara Security
Самой действенной мерой является подключение инфраструктуры подрядчика к собственному мониторингу. Это позволяет снизить риски, оперативно противостоять атакам и совместно решать возникающие проблемы. Если такое невозможно, необходимо применять принцип минимального необходимого доступа («Least Privilege») и ограничивать права сотрудников подрядчика исключительно необходимыми данными и системами. Полезно периодически проводить аудит инфраструктуры подрядчика.
Вместо этого эффективнее следовать принципу «контроль без перегибов»: выделить критичные меры, договориться о понятных шагах и зафиксировать, что делать в перспективе. Не перегружать документацией, а описывать требования так, чтобы их можно было внедрить без дополнительного штата и миллионных закупок.
Артем Назаретян
Руководитель BI.ZONE PAM
Что касается соответствия международным стандартам, таким как ISO или NIST CSF, то их прямое применение к подрядчикам с низкой зрелостью может быть затруднено. Однако реалистично требовать выполнения базовых требований, особенно если они уже закреплены в российском законодательстве. Например, в контексте работы с ИСПДн, ГИС или объектами КИИ подрядчики обязаны соблюдать меры: разграничение прав доступа, идентификацию и аутентификацию пользователей, в том числе с применением MFA, а также контроль действий привилегированных пользователей. Эти требования напрямую перекликаются с функциональностью PAM и могут быть реализованы даже при ограниченных ресурсах.
Часто достаточно базового набора: антивирус и обновления, резервное копирование с проверкой восстановления, ограничение доступа к данным, многофакторная аутентификация, обучение сотрудников основам кибергигиены. Это не заменит сложные стандарты, но позволит снизить ключевые риски и выстроить отношения, в которых партнер действительно сможет выполнять договоренности.
Когда у подрядчика случается ИБ-инцидент, первым делом встает вопрос: где заканчивается их зона ответственности и начинается ваша. Формально это можно прописать в договоре, но на практике граница всегда сложнее — особенно если подрядчик обрабатывает ваши данные или имеет доступ к вашей инфраструктуре. Здесь важно заранее договориться, кто что делает при инциденте: кто фиксирует, кто уведомляет, кто расследует и в какие сроки.
Константин Крючков
Директор продукта AppSec.Track, AppSec Solutions
Безусловно, нужен алгоритм совместных действий в том случае, если на инфраструктуре поставщика произошел инцидент. Исключить такой сценарий невозможно, потому что сегодня злоумышленники, нацеленные на крупные мишени, целенаправленно работают по цепочке поставок. Достаточно вспомнить кейс SolarWinds, но есть и множество других примеров. Вот это нужно обсуждать с поставщиком. Всегда есть SLA по поддержке, но обычно забывают туда включить SLA по выявлению и устранению уязвимостей. А это решается на уровне договора, тем более, если вы технологически более зрелая компания и можете предложить партнеру помощь в сложной ситуации. В целом, можно отдать часть процессов на аутсорс, но мы, конечно, за то, чтобы проблемы решались не по мере их появления, а заблаговременно, в рамках подходов DevSecOps.
Мониторинг в таких случаях строится по принципу «минимум, который позволит вовремя заметить проблему». Это может быть отдельный канал для оповещений о подозрительной активности, доступ к определенным логам, совместные проверки уязвимостей. Главное — не дожидаться, пока партнер сам решит, что вам пора рассказать о происшествии.
Вячеслав Чернышев
Генеральный директор Sinfores Group
Прежде, чем думать о мониторинге, сконцентрируйтесь на реагировании. Допустим, вы увидите инцидент у подрядчика почти сразу, успеете ли вы нажать на «красную» кнопку с нужной скоростью, чтобы не зацепило вас? Если вы нажмете на «красную» кнопку, то как быстро вы сможете заменить, например, подрядчика, который обеспечивает вам жизненно важные бизнес-процессы? Без такой подготовки мониторинг теряет смысл, а реакция будет хаотичной.
Исходя из своих возможностей по реагированию и критичности подрядчиков, уже можно размышлять о том, какой мониторинг вас устроит — свой SOC, SOC подрядчика или просто мониторинг косвенных индикаторов: новостей и даркнета.
Что касается допустимости технического контроля, то думаю, что компании стоит сконцентрироваться на пропаганде пользы данного процесса для самого подрядчика — ему не придется тратить ресурсы для выявления своих проблем.
Есть и тонкая грань между разумным контролем и вмешательством во внутренние дела подрядчика. Любые меры, которые предполагают доступ к их системам или данным, должны быть согласованы юридически. Иначе легко попасть в ситуацию, где ваши благие намерения будут трактоваться как нарушение конфиденциальности или даже требований регуляторов. В итоге ключ к работе с чужими инцидентами — это не только техника и процессы, но и четкие, прозрачные договоренности, закрепленные на бумаге.
Долгосрочная работа с подрядчиками в ИБ редко выигрывает от тотального контроля. Намного важнее, чтобы они сами понимали, зачем нужны меры защиты и как их применять. Когда партнер разделяет принципы безопасности, он будет закрывать уязвимости не потому, что «так написано в договоре», а потому что понимает ценность для бизнеса.
Отношения и культура безопасности формируются не только договорами. Совместные тренировки, разбор реальных инцидентов, обмен знаниями и материалами дают больший эффект, чем редкие формальные проверки. Вместо того чтобы заставлять подрядчика внедрять все пункты ISO или NIST, можно предложить «облегченный» набор стандартов — адаптированный под его размер и возможности, но совместимый с вашей моделью защиты.
Чтобы принципы работали на практике, полезно:
Прозрачность требований и готовность помочь партнеру с их выполнением — это инвестиция. Она окупается, когда в критический момент он реагирует быстро и по делу, а не ищет формулировки, чтобы снять с себя ответственность. Устойчивая модель взаимодействия строится на доверии, поддержке и общих целях, а не на гонке за выполнением всех пунктов чек-листа.
В условиях роста атак через цепочку поставок важно не просто требовать выполнения стандартов, а строить доверительные отношения с подрядчиками и учитывать их возможности. Гибкий подход, четкие договоренности и совместная ответственность помогают эффективно снижать риски. Инвестиции в обучение и поддержку партнеров окупаются быстрым и слаженным реагированием при инцидентах. Начните с малого — упростите требования, разговаривайте на понятном языке и сделайте безопасность общей задачей.
Термин Malware объединяет любые программы или код, созданные с целью нанесения ущерба устройству, данным или пользователю.
В 2026 году информационная безопасность перестала быть «страховкой от неприятностей» и превратилась в критический фактор выживания бизнеса.
Сегодня для начала хакерской атаки не нужны деньги – достаточно интернета.
Российский рынок сетевой безопасности в 2026 году перешел из фазы «экстренного импортозамещения» в стадию прагматичного выстраивания долгосрочных ИТ-стратегий.
Онлайн-игры переросли забаву — для детей это полноценная социальная среда, где формируются доверие, авторитет и цифровая идентичность.
Центры мониторинга ИБ все активнее внедряют AI/ML-модели, UEBA и LLM-ассистентов: автоматический триаж алертов, корреляция событий, приоритизация инцидентов и первичный анализ уже частично выполняются без участия человека.
Атаки на цепочку поставок стали одной из самых устойчивых и трудноуправляемых киберугроз для бизнеса.
Когда падает система уровня Sonata, становится очевидно: проблема не в ошибках пользователей и не в слабых паролях, а в самой архитектуре корпоративных мессенджеров.
С 1 марта 2026 года вступает в силу приказ ФСТЭК России № 117, который существенно меняет требования к защите информации в государственных информационных системах и смежных сегментах.
Еще несколько лет назад звонок от руководителя считался надежным подтверждением любого решения.
