В апреле 2026 года баланс между поиском и исправлением программных ошибок нарушился. Передовые модели ИИ, выпущенные Anthropic и OpenAI, теперь способны самостоятельно выявлять эксплуатируемые уязвимости в промышленном программном обеспечении — работа, которая раньше занимала у опытных исследователей около шестидесяти дней, теперь выполняется примерно за четыре часа, как отмечает Мелисса Хэтэуэй в недавнем обзоре Cyber Defense Review. Согласно той же статье, как минимум 40 крупнейших поставщиков программного и аппаратного обеспечения уже имеют доступ к этим моделям, а модель Mythos от Anthropic, по сообщениям, выявила критические ошибки в 99 процентах широко используемых операционных систем и браузеров.
Вывод Хэтэуэй бескомпромиссен: четыре десятилетия технического долга в стиле «выпускай быстро, чини потом» теперь дают о себе знать, и отрасли следует ожидать не десятилетия, а лавину патчей в ближайшие двенадцать-двадцать четыре месяца. Она права — и всё же дискуссия, которую она спровоцировала, ведётся почти полностью в терминах ИТ: сроки раскрытия, частота выпуска патчей, ответственность отстающих поставщиков.
Однако каждый из этих патчей в конечном итоге попадает куда-то физически: на подстанцию, линию розлива, водоочистное сооружение, больничное крыло. Вторжение на ПЛК на водоканалах Миннесоты в июле (статья CSO) стало предвестником того, как это выглядит. И здесь цунами сталкивается со структурой, о которой дискуссия о раскрытии уязвимостей постоянно забывает: окном обслуживания.
Обнаружение на машинной скорости, устранение на заводской скорости
Поиск уязвимости и её исправление никогда не были одним и тем же процессом. ИИ сжал первый этап, оставив второй нетронутым. В корпоративных ИТ принятая Хэтэуэй практика устранения — семь дней для активно эксплуатируемых критических ошибок, тридцать для высокого уровня опасности — амбициозна, но достижима: перезагрузите сервер, откатите, если сломается, и ни перед кем не извиняйтесь.
В операционных технологиях (ОТ) эта практика структурно невозможна. Доступность и безопасность важнее конфиденциальности; непрерывный процесс не останавливается из-за появления CVE; а следующее запланированное окно может быть ежеквартальным перерывом или ежегодной остановкой, запланированной 18 месяцев назад. Разрыв не культурный. Он физический, экономический и контрактный.
Тем временем сторона атакующего получает такое же ускорение, как и сторона защиты. Модели, находящие ошибку, могут разработать рабочую атаку в течение нескольких часов после раскрытия, и эта возможность не ограничена одним блоком: Хэтэуэй отмечает, что агент обнаружения ИИ китайской 360 Digital Security Group уже выявил почти тысячу ранее неизвестных уязвимостей. Нет ни географического, ни отраслевого убежища — и сети ОТ с их долгоживущими и редко патчируемыми активами являются именно тем местом, где накапливается время без патчей. Обнаружение теперь работает на машинной скорости. Устранение в ОТ по-прежнему работает на заводской скорости. Всё, что следует далее, касается управления растущим разрывом между ними.
Почему ОТ не может просто патчить быстрее
Полезно точно понять, почему стандартный совет не работает, потому что ни одна из причин не является халатностью. Патч, который перезагружает контроллер, может вызвать аварию в работающем процессе; на системе, связанной с безопасностью, или рядом с ней неквалифицированное изменение само по себе является опасностью, а не смягчением. Большинство промышленных компонентов можно обновлять только прошивками и патчами, которые OEM-производитель проверил для конкретной линейки продуктов — применение неутверждённого обновления может аннулировать гарантии, контракты на поддержку и сертификаты. Эта проверка занимает от нескольких недель до месяцев, и отсчёт начинается только после того, как поставщик обработал исправление от вышестоящего разработчика. Затем эксплуатационщикам нужно найти окно: многие заводы не могут остановиться вне плановых остановок без потерь в семизначных суммах или реальных рисков для безопасности.
И под всем этим лежит устаревший слой. Хэтэуэй прямо называет производство и здравоохранение секторами, где используются неподдерживаемые продукты, и на заводах, которые я проверяю, картина знакомая: рабочая станция инженера на операционной системе, поддержка которой закончилась годы назад, поколение ПЛК, у которого вообще нет механизма обновления. Для этих активов «патчи быстрее» — не совет. Замена — это капитальная программа с горизонтом в несколько лет — её аналогия с проблемой 2000 года абсолютно точна. В ИТ патч — это исправление. В ОТ патч — это проект.
Триаж как у оператора, а не как у сканера
Первой жертвой грядущего объёма станет список задач, отсортированный по CVSS. Когда раскрытие с помощью ИИ вываливает сотни релевантных уведомлений в установленную базу за квартал, «критические в первую очередь» перестаёт быть ключом сортировки, потому что слишком многое является критическим. Широкая отрасль приходит к тому же выводу: Rapid7 предупредила в августе, что объём раскрытий и скорость эксплуатации сломали традиционный цикл патчей и вынуждают защитников переходить к приоритизации на основе подверженности. Логика триажа, которую я объясняю операторам, строится на трёх вопросах. Есть ли доказательства эксплуатации — запись в KEV, растущий балл EPSS, уведомление OEM об активном злоупотреблении? Подвержен ли актив на самом деле — достижим из ИТ-сети или интернета, или зарыт на три зоны глубже за принудительными каналами? И каковы последствия — что этот компонент делает с процессом и с безопасностью, если он ведёт себя неправильно?
IEC 62443 уже предоставляет словарь для действий на основе этих ответов: зоны и каналы для определения подверженности, а также компенсирующие меры, когда патчинг невозможен в требуемые сроки — сегментация, разрешительные списки, виртуальный патчинг на границе сети, удаление излишней достижимости и усиленный мониторинг попыток эксплуатации конкретной ошибки (TR 62443-2-3 подробно описывает управление патчами в промышленных средах). Официальные доктрины теперь указывают в том же направлении: в конце июля коалиция под руководством ASD совместно с CISA, ФБР, NCSC-UK и CCCS опубликовала CI Fortify — совместное руководство по изоляции критически важных систем ОТ и их работе в отключённом режиме в течение длительных периодов; изоляция переведена из обходного пути в проектируемую возможность. Честная и проверяемая позиция для большой части парка ОТ, следовательно, не «исправлено в рамках SLA». Это: мы не патчим этот актив в эти сроки; мы его изолируем — вот компенсирующая мера, вот мониторинг, и вот дата вывода из эксплуатации. В рамках NIS2, где руководство несёт личную ответственность за меры по управлению рисками, документированное решение об изоляции защищает значительно лучше, чем молчаливо пропущенный SLA по патчам.
Планируйте всплеск как отключение
Хэтэуэй призывает правительства сопоставить объёмы патчей с национальной подверженностью и подготовить резервные мощности. Операторам следует провести то же упражнение на уровень ниже, и четыре шага наиболее важны. Во-первых, спросите своих OEM-производителей и системных интеграторов прямо сейчас: как они обрабатывают результаты, обнаруженные ИИ, какой объём и частоту патчей они ожидают для вашей установленной базы, и каковы их сроки проверки? Совместное руководство CSA, SANS и OWASP, опубликованное в апреле, по созданию «Mythos-ready» программ безопасности — это полезный контрольный список именно для такого разговора. Европа добавляет здесь рычаги: 11 сентября вступает в силу первое жёсткое обязательство Закона о киберустойчивости (CRA) — производители должны сообщать об активно эксплуатируемых уязвимостях через новую Единую платформу отчетности ENISA с ранним предупреждением в течение 24 часов и более полным уведомлением в течение 72 часов, и обязанность распространяется на продукты, уже находящиеся на рынке, а не только на новые. Это означает более ранние восходящие сигналы: спрашивайте своих поставщиков в письменной форме, как эти уведомления и сопутствующие данные SBOM дойдут до вас как до оператора.
Во-вторых, заранее согласуйте аварийные окна с эксплуатацией до того, как они понадобятся, включая письменные критерии, когда уязвимость оправдывает незапланированный простой — структура принятия решений, как и любой другой вызов по безопасности, согласованная при свете дня, а не импровизированная в 2 часа ночи. В-третьих, отработайте сценарий, который на самом деле грядёт: не один инцидент, а неделя, когда несколько уведомлений высокой степени опасности поступают одновременно от разных поставщиков. Хэтэуэй рекомендует такие учения на национальном уровне; они ещё более полезны на уровне завода, где ограничением является конечный пул инженеров-автоматизаторов. В-четвёртых, дайте каждому активу, который нельзя пропатчить, дату вывода из эксплуатации и бюджетную строку. Компенсирующие меры — это мост, а не пункт назначения, и инвентаризация, которая молча накапливает постоянные исключения, — это технический долг в костюме соответствия требованиям.
Политические вопросы — сроки раскрытия, государственные интересы, ответственность поставщиков — будут решаться в Вашингтоне и Брюсселе. Операторам в любом случае придётся жить с результатом. Обнаружение ускорилось навсегда; конвейер раскрытия информации индустриализируется, и сами лаборатории ИИ теперь берут на себя обязательства по фиксированным срокам координированного раскрытия; единственная переменная, всё ещё находящаяся под контролем оператора, — это готовность механизма устранения. В ОТ этот механизм строится на управлении изменениями, а не на скриптах. Промежуток между раскрытием ошибки и её эксплуатацией раньше был чьей-то чужой проблемой — поставщика, исследователя, политика. С этого года это проблема эксплуатации. Относитесь к ней как к таковой.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Sabine Frömling
