Около 325 млн попыток атак пришлось на англоязычные страны Карибского региона в 2025 году, а критические уязвимости там начинают атаковать через 24–48 часов после раскрытия. Эти риски кибербезопасности не заканчиваются на островах: общие суды, банки, аутсорсеры и гостиничные сети связывают регион с компаниями в Северной Америке и Европе. Для российских IT-команд это знакомый сюжет: скорость эксплуатации давно обогнала годовой ритм аудитов поставщиков.
Повод разобрал автор колонки Dark Reading Марлон Купер, CEO Symptai Consulting и руководитель направления managed security services в Digicel Business. Его тезис простой и неприятный: небольшая организация может быть частью критической инфраструктуры крупного партнёра, но проверяют её контроли так, словно за год вокруг неё ничего не меняется.
Пример уже был. 24 июля 2025 года налоговая и таможенная администрация Кюрасао обнаружила в своей сети вымогательское ПО. Стойки обслуживания, кол-центр и внутренние процессы не работали больше недели; для восстановления пришлось привлекать специалистов из Нидерландов. За день до этого перестал работать Объединённый суд, обслуживающий Кюрасао, Арубу, Синт-Мартен, Бонэйр, Сабу и Синт-Эстатиус. Одна скомпрометированная платформа ударила сразу по шести юрисдикциям.
В этом и состоит проблема региона: техническая и организационная связность выше, чем кажется по размеру отдельных стран. Общая ИТ-система, поставщик услуг или федерация учётных записей превращают локальный инцидент в межгосударственный. А когда такой узел связан с внешними страховщиками, банковскими корреспондентами, программами лояльности или BPO-провайдерами, последствия уходят далеко за пределы Карибского моря.
Эксплойт уже в пути, анкета ещё на согласовании
По приведённым в колонке данным Fortinet, время до начала атак на критические уязвимости сократилось с почти пяти дней до 24–48 часов. Одновременно IBM в отчёте Cost of a Data Breach 2026 оценила среднее время обнаружения и сдерживания утечки в 247 дней — на 2,5% больше, чем годом ранее. Сравнивать эти величины напрямую нельзя: одна описывает активность атакующих после раскрытия уязвимости, другая — полный жизненный цикл инцидента. Но направление разрыва очевидно: атакующий работает в часах, защитник и контрольные процедуры — в месяцах.
Партнёрская проверка при этом нередко выглядит как ежегодная анкета или аттестация при продлении договора. Страховщик оценивает обработчика страховых случаев раз в год, сеть отелей — франчайзи при очередном пересмотре условий, банк получает документ от контрагента и кладёт его в архив. Подписанная в марте анкета уже в апреле может описывать другую инфраструктуру: появился новый внешний сервис, изменились права доступа, вышла критическая уязвимость, истёк срок поддержки компонента.
Призыв «просто ставьте патчи быстрее» здесь слишком удобен. В небольшой организации за безопасность могут отвечать два-три человека. Критичную систему нельзя остановить без резервной площадки, поддержка поставщика находится в другом часовом поясе, а для общей платформы шести ведомств никто в одиночку не вправе назначить окно работ. Это не оправдание дыр, а описание ограничений, которые должны учитывать заказчики и аудиторы.
Что проверять вместо формального соответствия
Для разработчиков и ИБ-команд вывод практический: оценивать нужно не только наличие процесса управления патчами, но и его реальную скорость. Полезнее видеть распределение времени устранения критических уязвимостей и долю исключений, чем довольствоваться средней цифрой MTTR. Среднее значение легко маскирует несколько систем, которые остаются открытыми недели; именно они обычно интересуют злоумышленника.
Второй вывод — собирать непрерывные подтверждения состояния защиты, а не полагаться на разовую декларацию. Это не обязательно означает бесконечный аудит каждого подрядчика. Речь о понятных сигналах: актуальности внешних активов, сроках устранения критических находок, включённой многофакторной аутентификации, событиях привилегированного доступа и просроченных исключениях. Для поставщиков, обслуживающих несколько клиентов на одной платформе, логичнее оценивать саму общую платформу: шесть одинаковых анкет не уменьшают один и тот же риск шесть раз.
Наконец, надо исходить из того, что часть уязвимостей нельзя закрыть в отведённые 48 часов. Тогда нужны сегментация, ограничение привилегий, компенсирующие меры и зафиксированное решение владельца риска с датой пересмотра. Особенно важны федеративные маршруты доступа: украденная учётная запись в облачной среде быстро перестаёт быть внутренней проблемой одного подрядчика и становится точкой входа в системы партнёра.
Карибский кейс не экзотика, а наглядная модель для любой распределённой цепочки поставок. Риски кибербезопасности возникают не там, где компания формально провела аудит, а в промежутке между появлением новой уязвимости и реальным изменением защиты. Вопрос для бизнеса теперь не в том, есть ли у поставщика заполненная анкета, а в том, что изменилось в его инфраструктуре после её подписания.
