Закрытие CVE - это бизнес-решение, а не просто задача ИТ
Почему установка патчей продолжает откладываться, что реально стоит это промедление и как сформулировать вопрос так, чтобы он получал приоритет.
2015 год выдался громким по части уязвимостей. GHOST, FREAK, VENOM, Stagefright и длинный список других - каждая с рекомендациями вендоров, патчами и волной статей о том, действительно ли компании их устанавливают. Большинство - нет, или недостаточно быстро.
Я вижу одну и ту же динамику почти в каждой организации, с которой работаю: команда безопасности знает о CVE, ИТ-команда имеет патч, а развёртывание занимает недели или месяцы. Бутылочное горлышко редко бывает техническим. Оно организационное.
Почему патчи откладываются
Реальный блокировщик почти всегда один из трёх:
Окна изменений. Многие организации запускают изменения в продакшне по фиксированному расписанию - еженедельно или ежемесячно. Критический патч приходит в среду. Следующее окно через три недели. Формальный ответ: «войдёт в следующий цикл». Ответ злоумышленника другой.
Риск регрессии. Патчи ломают вещи. Обновление ОС, меняющее поведение библиотек, может затронуть совместимость приложений. Обновление прошивки на сетевом устройстве может изменить поведение маршрутизации. Команда знает это из опыта, и «сначала протестируй» превращается в «тестируй вечно».
Неясное владение. Уязвимость затрагивает несколько систем. Кто отвечает за установку патча на базовую библиотеку в сервере приложений - команда инфраструктуры, команда приложения или вендор? Когда владение неясно, тикеты оседают в очередях.
Цена промедления не теоретическая
Стоимость незакрытой уязвимости незаметна - до тех пор, пока не становится очевидной. После взлома форензик-хронология обычно показывает, что эксплойт был доступен, а патч существовал за недели до инцидента. Ответить на вопрос «почему это не было закрыто?» перед аудитором, регулятором или клиентом тогда очень сложно.
Для критической инфраструктуры - энергетика, вода, финансы, транспорт - это регуляторный вопрос, а не только репутационный. Но даже за пределами регулируемых отраслей совокупная стоимость взлома через известную, закрываемую патчем уязвимость почти всегда выше, чем операционные расходы на цикл установки патчей.
Как представить это бизнесу
Самая распространённая ошибка - представлять установку патчей как расходы на обслуживание: что-то, что ИТ обязано делать, центр затрат, помеха «настоящей» работе. С такой формулировкой проигрываешь каждый бой за приоритизацию новым фичам, клиентским поставкам и проектам, связанным с выручкой.
Правильная формулировка - риск. Известная, незакрытая CVE с публичным эксплойтом - это открытая экспозиция с просчитываемым радиусом поражения. Бизнес-решение не в том, «стоит ли закрыть это», а в том: «как долго мы готовы нести эту экспозицию и какой у нас план реагирования, если её используют до установки патча?»
Когда вопрос сформулирован так, большинство руководителей принимают другое решение, чем «поставить в следующее месячное окно изменений».
Практический минимум
Три вещи, которые реально ускоряют циклы установки патчей на практике:
- Разделить экстренный трек и плановый. Критические CVE (CVSS 9.0+, публичный эксплойт, открытая поверхность атаки) идут по ускоренному процессу. Всё остальное - через обычное окно изменений. Смешивание означает, что всё медленно.
- Предварительно авторизовать экстренный трек. Ускоренный процесс не должен требовать тех же согласований, что и плановые изменения. Определите предварительно согласованные рамки и процедуру заранее, а не в 23:00, когда патч уже нужен.
- Отслеживать среднее время до установки патча по степени критичности. Сделайте это метрикой, докладывайте о ней, владейте ею. Что измеряется - тем управляют.
Установка патчей - не эффектная работа. Но незакрытая известная уязвимость - это риск, который бизнес активно выбирает нести. Сделать этот выбор видимым - первый шаг к тому, чтобы он стал рациональным.