Патчить или подождать? 🩹

Продолжаем про риски. И сегодня — про процесс, который кажется простым ровно до первого реальной остановки бизнеса.

В продуктовом контуре выявлена критическая уязвимость. Что делать ИБэшнику ?

❌ Накатить патч немедленно — и рискнуть положить боевую систему в разгар операционного дня?
vs
❌ Подождать, протестировать, согласовать — и оставить открытым окно, в которое уже ломятся?

Дилемма управления уязвимостями. И она сложнее, чем кажется, потому что риск возникает с обеих сторон:

⏳ Патчим слишком медленно - может реализоваться риск ИБ:
🔹 окно для эксплуатации уязвимости остаётся открытым;
🔹 происходит успешная эксплуатация злоумышленником;
🔹утечки, финансовые потери и пр.

⚡️ Патчим слишком быстро, без тестирования - может реализоваться риск операционной надёжности:
🔹 патч ломает приложение;
🔹 делаем откат в момент пиковой нагрузки;
🔹 останавливаем бизнес и теряем репутацию, клиентов, деньги и т.д.

Между этими крайностями стоит задача — найти баланс.

Каркас этого процесса:

Выявить, приоритизировать, классифицировать, устранить и проконтролировать полноту и своевременность устранения.

Чтобы не свалиться ни в одну из крайностей — несколько принципов:

✅ Дифференцировать сроки по критичности
✅ Не тащить непроверенный патч в прод. Тестовая среда дешевле любого отката.
✅ Держать план отката наготове (если всё-таки что-то сломали).
✅ Применять компенсирующие меры для того, что нельзя пропатчить.
✅ Измерять процесс устранения уязвимостей, т.е. иметь понятные метрики и анализировать их.

💡 И тогда «патчить или подождать?» перестаёт быть слепым выбором и становится управляемым решением: быстро — там, где горит, и аккуратно — там, где можно сломать.

P.S.: И главное не говорить «потом разберёмся». Потому что «потом» обычно приходит вместе с инцидентом.

#ТриадаИБ #СистемныйПодход #ИБ_без_слез
Присоединяйтесь → t.me/osipov_sec