Что происходит, когда злоумышленники действуют быстрее, чем система здравоохранения успевает устанавливать патчи?

Здравоохранение давно сталкивается с серьёзным препятствием при устранении уязвимостей: служба безопасности больницы может за один день обнаружить уязвимость в клинической системе, но безопасной установке исправления обычно мешают реалии напряжённой повседневной работы. Производителю устройства может потребоваться проверить обновление, больнице — протестировать его и запланировать остановку системы, а некоторые изменения могут даже требовать рассмотрения регулятором.

У злоумышленников таких ограничений нет. Инструменты ИИ ускоряют поиск и исследование уязвимостей, а также разработку эксплойтов, усиливая давление на и без того перегруженные процессы устранения уязвимостей в здравоохранении.

Особую остроту проблеме придаёт зависимость от поставщиков, которая часто увеличивает задержки. Например, исправление для системы МРТ может требовать проверки производителем, но после этого его зачастую всё равно должна одобрить больничная служба управления изменениями. И всё это необходимо сделать, не нарушая оказание помощи пациентам.

В докладе Health-ISAC «Передовой ИИ в здравоохранении» задержки с установкой исправлений названы одним из характерных источников риска для отрасли. У больниц остаётся один реалистичный путь: даже если они не могут контролировать каждый этап установки обновления, они могут ограничить возможности злоумышленника на время его внедрения.

Сроки установки исправлений нельзя сокращать бесконечно — и на то есть причины

Многие этапы установки исправлений в больнице могут раздражать специалистов по информационной безопасности, но они существуют ради безопасности пациентов. Непроверенное обновление аппарата ИВЛ или инфузионного насоса, призванное устранить киберугрозу, не оправдано, если оно мешает оказанию помощи. Поэтому следует ускорять те части процесса, которые можно ускорить без ослабления действующих процедур.

Аудиторы и советы директоров склонны считать длительные сроки устранения уязвимостей признаком незрелой программы безопасности или нехватки бюджета, и иногда они правы. Обычно такие сроки указывают на недостатки исполнения, нехватку ресурсов или узкие места, не зависящие от службы безопасности. Дополнительные аналитики могут улучшить обнаружение, разбор и приоритизацию уязвимостей, но не могут сократить сроки работы производителя или перенести допустимые периоды простоя.

На фоне того, что эксплуатация уязвимостей становится самым распространённым способом проникновения в сети, отчёт Verizon Data Breach Investigations Report за 2026 год (DBIR) показывает, насколько мало времени остаётся организациям на установку исправлений. Медианное время полного устранения уязвимости, для которой подтверждена эксплуатация выросло с 32 дней годом ранее до 43 дней в 2026 году, а доля полностью устранённых уязвимостей снизилась с 38% до 26%.

Эти цифры относятся не только к здравоохранению. Они показывают, насколько сложным уже стало устранение уязвимостей — ещё до учёта клинических ограничений и зависимости от поставщиков, с которыми дополнительно сталкиваются больницы.

Пора смотреть шире оценок критичности

Пока сроки устранения уязвимостей увеличиваются, злоумышленники действуют всё быстрее. Согласно DBIR, эксплуатация уязвимостей стала главным способом проникновения в системы: на неё приходится 31% утечек данных. Впервые за 19 лет публикации отчёта она опередила использование похищенных учётных данных.

По данным Verizon, ИИ настолько ускорил обнаружение и эксплуатацию уязвимостей, что задачи, прежде занимавшие месяцы, теперь могут выполняться за часы или дни. Причём это происходило ещё до появления нынешнего поколения передовых моделей: данные DBIR охватывают период лишь до октября 2025 года.

Но сегодня подобной скорости уже все ожидают. Доклад Health-ISAC обращает внимание на более существенную перемену: новые модели ИИ способны объединять находки низкой критичности в критически опасные цепочки атак, выявляя сочетания слабых мест, которые по отдельности кажутся менее важными. Это создаёт ещё одну проблему для программ, ориентирующихся на оценки критичности. Уязвимости низкой критичности, которые часто игнорируют или откладывают, могут внезапно приобрести гораздо большее значение, если влияют на доступ или критически важные системы.

Растущая очередь неустранённых проблем только усугубляет положение. В статье для Nature директор Института Макса Планка Торстен Хольц описал как Mozilla использовала передовую модель для обнаружения и исправления 271 уязвимости в одном выпуске Firefox. Это значительно больше, чем имеющиеся инструменты и проверяющие выявляли за обычный месяц в течение предыдущего года.

Нагрузка при разборе сообщений распространяется и на разработчиков: в мае Линус Торвальдс, сопровождающий ядро Linux, отметил что сообщения об ошибках, созданные ИИ, перегружают сопровождающих проектов.

Если нельзя исправлять быстрее, ограничьте доступность уязвимых систем

К счастью, даже если очередь неустранённых проблем нельзя ликвидировать, ею можно управлять. Если исправление приходится ждать, приоритетом должно стать снижение вероятности того, что злоумышленник получит доступ к уязвимости. Акцент смещается со скорости исправления на доступность систем — а это больницы могут контролировать.

Сегментация может стать действенной компенсирующей мерой. Диагностическое устройство с широкими сетевыми правами может обращаться к контроллеру домена, общему файловому ресурсу и открытому интернету. Но если поместить его в изолированный сегмент, разрешающий связь только с сервером PACS и узлом обновлений производителя, а всё остальное блокирующий по умолчанию, последствия любой его уязвимости можно ограничивать независимо от того, сколько придётся ждать исправления.

Если требования устройства и поставщика это допускают, больницы могут использовать сегментацию, контроль исходящего трафика и запрет по умолчанию, чтобы сузить или полностью закрыть пути доступа до установки исправления.

Чтобы начать сокращать поверхность атаки, больнице не требуется завершать полную инвентаризацию активов. Сначала определите число систем, отвечающих на запросы из интернета, поддерживайте эти сведения в актуальном состоянии по мере дальнейшей инвентаризации и в первую очередь ограничивайте доступ таких систем к внутренней сети.

Опрос Health-ISAC показывает, что отрасль уже начинает двигаться в этом направлении. Около 80% участников Health-ISAC сообщают о планах увеличить бюджеты на средства безопасности с ИИ или оценку возможности эксплуатации уязвимостей. Полезным подходом может стать анализ того, какие цепочки атак работают именно в вашей среде: выявляйте сочетания уязвимостей низкой критичности, которые заслуживают внимания ещё до того, как на них укажет оценка приоритета.

Разговоры с поставщиками также должны выходить за рамки формулировок соглашения об уровне обслуживания. Договоры отражают обязательства, принятые вами и поставщиками много лет назад, тогда как модель угроз радикально изменилась. Поэтому сначала выясните, сколько времени после публичного раскрытия уязвимости может занимать выпуск проверенного исправления, а затем — какие меры снижения риска доступны на время ожидания. Стоит также спросить, проверяет ли поставщик свой продукт на устойчивость к современным атакам с применением ИИ.

Управляйте риском, который пока нельзя устранить

Большинство организаций не могут сказать, сколько времени проходит от публикации эксплойта до запуска проверенного исправления в рабочей среде. Определите этот показатель, чтобы перейти от споров о сроках установки исправлений к выяснению того, какие поставщики и системы дольше всего остаются уязвимыми. Это позволит расставить приоритеты в работе по устранению проблем.

Обмен информацией может значительно сократить цикл принятия решений. Некоторые из самых быстрых решений об устранении уязвимостей, которые я наблюдал, принимались после того, как больница узнавала от коллег об атаке на платформу поставщика ещё до публичного раскрытия уязвимости.

Само окно проверки не станет шире. Больницы продолжат эксплуатировать клинические системы с неустранёнными уязвимостями, поэтому стратегия сегментации для них должна получить больший приоритет, чем график установки исправлений. Каждая больница должна уметь описать для каждой критически важной платформы, что произойдёт в сети, если эту платформу взломают завтра.