⚠️ Когда CVSS 10 на заводе не требует немедленного патча Сканер уязвимостей безапелляционно ставит 10 баллов промышленному контроллеру, и начальник требует объяснений. В IT можно закрыть тикет за полчаса, но в цеху с непрерывным циклом обновление может стоить дороже самой атаки. По данным helpnetsecurity, ключевой навык OT-безопасника — отделить гипотезу сканера от реально эксплуатируемого вектора. Не потому что лень, а потому что вставший завод — это инцидент с гарантией, а не «возможная атака». Метод из семи шагов начинается не с патча, а с инвентаризации: существует ли устройство по этому IP прямо сейчас, работает ли на нём уязвимый сервис, какая сетевая сегментация перед ним. Часто PLC меняют подсеть без уведомления, или сканер ориентируется на версию баннера, а не на реальный бинарник. Проверка доступности даёт первый фильтр: если порт 8000 (пример из CVE-2025-27495) закрыт корпоративным фаерволом для всего, кроме управляющего сервера, и атакующий не может доставить полезную нагрузку без предварительного компромиса промежуточного сервера — CVSS превращается в управляемый риск. Следующий рубеж — учёт уже действующих защит: списки контроля доступа, принудительная многофакторная аутентификация на промежуточном хосте, ограничение исходящих соединений. В правильно выстроенной DMZ между IT и OT даже неаутентифицированная критическая уязвимость не даёт прямого контроля. Последним шагом становится формальное принятие риска, фиксирующее компенсирующие меры, ответственного и дату пересмотра. Без этой бумаги вы либо патчите вслепую, рискуя остановкой, либо тянете до аварии. Сканер уязвимостей в промышленности — не приговор, а тест-кейс. Настоящий профессионализм — доказать, что конкретный CVSS 10 в вашей архитектуре нефункционален, и задокументировать это до того, как аудитор потребует «немедленно устранить». Сколько у вас таких находок, от которых вы отбились не патчем, а архитектурой? #OTsecurity #ICS #VulnerabilityManagement #CVSS