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

Уязвимость критическая. Политика требует устранить её за несколько дней. Vendor выпустил исправление. Vulnerability management показывает просроченный SLA.

Казалось бы, решение очевидно: установить patch.

Но система управляет реальным производством. Для обновления нужно остановить технологический процесс. После установки необходимо проверить совместимость. Резервного стенда нет. Текущая конфигурация сертифицирована. А неудачное изменение может повлиять уже не на конфиденциальность данных, а на оборудование, качество продукции или safety-функции.

И тогда перед CISO и владельцем производства возникает гораздо более сложный вопрос:

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

Моя позиция: в OT нельзя автоматически считать просроченный patch провалом безопасности.

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

Одна из распространённых ошибок — переносить IT-логику vulnerability management непосредственно в OT.

Сканер обнаруживает critical vulnerability. CVSS высокий. Запускается SLA: несколько дней на remediation. Через установленный срок объект становится «красным».

Такая модель удобна для отчётности. Но она отвечает только на часть вопроса.

Для промышленной системы необходимо понять:

Уязвимость на изолированном инженерном сегменте и та же уязвимость на системе, доступной через плохо контролируемый remote access, — это два разных риска.

Поэтому severity — важный входной параметр, но плохой заместитель анализа реальной exposure.

NIST SP 800-82 Rev. 3 строит рекомендации по OT именно с учётом специфических требований таких систем к производительности, надёжности и безопасности. В январе 2026 года NIST начал работу над следующей ревизией руководства, отдельно указав на изменения OT threat landscape и необходимость актуализировать практики управления рисками. (NIST Computer Security Resource Center)

В классическом vulnerability management внимание сосредоточено на риске эксплуатации уязвимости.

В OT появляется ещё один объект анализа:

риск самого изменения.

Patch может:

Это не аргумент против обновлений.

Это аргумент против управления OT через единственный показатель «сколько дней прошло после публикации CVE».

Если cyber risk сравнивается с нулём, patch всегда побеждает.

Если cyber risk сравнивается с change-induced operational risk, решение становится намного содержательнее.

Здесь находится другая крайность.

Особенности OT легко превращаются в универсальное объяснение бездействия:

Vendor не разрешает.Производство нельзя остановить.Старое оборудование.Проверим во время следующего shutdown.

А потом проходят два года.

Я считаю такую позицию не risk-based подходом, а отсутствием управления риском.

Если patch сейчас невозможен, организация должна перейти от remediation к активному временному risk response.

И у этого решения должны быть как минимум:

Исключение без даты окончания очень быстро превращается в архитектуру.

Хорошее исключение из patch SLA — это не записка «невозможно обновить из-за производства».

Я бы ожидал увидеть в нём минимум восемь элементов.

1. Asset criticalityКакую функцию выполняет система и каков потенциальный физический или бизнес-impact?

2. ExposureОткуда доступен уязвимый компонент и какие trust boundaries находятся на пути?

3. Exploit maturityНасколько реалистична эксплуатация в текущих условиях?

4. Physical consequenceК чему приведёт компрометация именно этого компонента?

5. Change riskЧто может произойти в результате неудачного patching?

6. Compensating controlsКакие барьеры временно уменьшают вероятность или последствия эксплуатации?

7. Patch windowКогда remediation реально может быть выполнен безопасно?

8. Risk acceptanceКто принимает остаточный риск и на какой период?

Получается простой decision flow:

asset criticality → exposure → exploit maturity → physical consequence → vendor support → change risk → compensating controls → patch window → risk acceptance.

Это уже не «исключение из процесса».

Это управляемое решение.

Я не считаю невыполненный patch автоматически признаком слабой OT security.

Иногда решение временно не обновлять систему действительно является более безопасным.

Но такое решение должно быть сложнее, а не проще, чем обычное patching.

ИБ должна уметь показать:

«Нельзя обновить» — это описание ограничения.«Вот почему мы временно не обновляем, вот как ограничили риск и вот когда пересмотрим решение» — это управление риском.

Если в вашей OT-среде есть просроченные critical vulnerabilities, я бы не начинал с отчёта по SLA.

Я бы выбрал несколько наиболее критичных систем и задал команде пять вопросов:

Если на эти вопросы есть ответы — организация действительно управляет риском.

Если единственный аргумент звучит как «производство не разрешает обновлять», проблема гораздо глубже одной CVE.

В OT безопасность — это не соревнование за минимальный patch latency.

Это способность принимать технически обоснованные решения на границе киберриска, надёжности, safety и непрерывности производства.

И иногда зрелое решение действительно означает не устанавливать patch сегодня.

Но оно никогда не должно означать ничего не делать.