Допустимо ли нарушить critical patch SLA, если обновление само способно остановить производство?

Я считаю, что да.

Более того, иногда немедленная установка patch в OT может быть менее зрелым решением, чем контролируемая отсрочка.

Проблема начинается, когда vulnerability management пытаются строить по простой формуле: CVSS → severity → SLA → patch.

Для серверов и рабочих станций такая логика часто работает.

Для промышленной системы в уравнении появляется ещё один риск — риск самого изменения.

После patching оборудование может потерять совместимость. Может измениться поведение промышленного протокола. Может перестать поддерживаться сертифицированная конфигурация. А downtime может означать уже не несколько недоступных сервисов, а остановленный физический процесс. Но из этого нельзя делать противоположный вывод: «OT особенная, поэтому обновлять ничего не будем».

Фраза «производство не разрешает» не является стратегией управления уязвимостью.

Зрелое решение временно сохранить vulnerable configuration должно отвечать минимум на следующие вопросы: — Есть ли реальный exploit path? — Насколько система достижима из менее доверенных зон? — Какие privileges нужны атакующему? — Каковы physical consequences эксплуатации? — Каков риск неудачного изменения? — Какие compensating controls реально разрывают цепочку атаки? — Когда состоится maintenance window? — Кто принимает residual risk? — При каких событиях решение будет пересмотрено досрочно?

Именно последний пункт часто недооценивают.

Exception, согласованный сегодня, может устареть завтра.

Появился рабочий exploit. Изменился remote access. Подрядчик подключил новый канал. Ослабла сегментация. Vendor выпустил проверенное исправление.

Значит, старое решение больше нельзя считать актуальным.

Поэтому я бы разделял два совершенно разных состояния:

«Patch не установлен» — технический факт.

«Риск контролируемо принят до конкретного окна обновления» — управленческое решение.

Первое само по себе ничего не говорит о зрелости безопасности.

Второе требует хорошей архитектуры, понимания производства, threat analysis, change management и готовности отвечать за residual risk.

На мой взгляд, именно здесь проходит одна из важных границ между IT-style compliance и настоящим OT risk management.

Иногда правильное решение — не обновлять сегодня. Но правильное решение никогда не заключается в том, чтобы просто ждать.

Какой фактор в вашей OT-среде чаще всего делает patching более рискованным, чем временное сохранение уязвимости?