Журнал "Information Security/ Информационная безопасность" #1, 2026

• 1 www.itsec.ru Бюджет на угрозы Ночь. После релиза новой версии сервис начинает деградировать, и команда SRE, отвечающая за надежность сервисов, откатывает релиз. Утро. SOC сообщает: в старой версии уязвимость, ее уже обсуждают на форумах. Разработчик в растерянности, бизнес теряет деньги, команды раз- дражены друг на друга. Знакомая картина? Причина обычно проста: у SRE и SOC разные метрики успеха. Одни отвечают за доступность и стабильность, другие – за снижение рисков, связанных с уязвимостями и инцидентами. Общего языка для принятия компромиссных решений часто нет. В SRE-практике для баланса между стабильностью и развитием используется бюджет ошибок (Error Budget) – допустимый уровень сбоев, при превышении которого приоритет смещается к ста- билизации. В безопасности похожая логика существует в виде риск-аппетита, но до уровня кон- кретных инженерных решений она обычно не доходит. А если приземлить эту идею? По сути, речь идет о риск-аппетите – допустимом уровне угроз и уязвимостей, который организация готова принять, чтобы не блокировать собственное развитие. Для наглядности такой подход можно рассматривать как своего рода бюджет на угрозы (Threat Budget). Это не устоявшийся термин и не методика, а скорее рабочая аналогия. Она не дает точных расчетов и не заменяет полноценный риск-менеджмент, но позволяет задать общий контур для принятия решений. Тогда вопрос можно поставить так: что обойдется дороже. Один из базовых подходов – оценка ожидаемых потерь: вероятность инцидента, умноженная на его потенциальный ущерб. Эта логика используется во многих методиках управления рисками – от ISO и NIST до более прикладных моделей вроде FAIR. На практике такие оценки неизбежно носят приближенный характер. Но даже грубые ориентиры позволяют обсуждать решения в сопоставимых категориях, а не в терминах "критично/некритично" у каждой из команд. Вернемся к ситуации с откатом релиза. С точки зрения безопасности можно оценить контекст угрозы: есть ли признаки эксплуатации, насколько уязвимость применима к конкретной системе, есть ли компенсирующие меры. Со стороны эксплуатации – во сколько обойдется простой или деградация сервиса здесь и сейчас. Уже этого достаточно, чтобы обсуждение стало предметным. В результате меняется и взаимодействие внутри компании. Для SRE это означает, что устойчивость сервиса рассматривается не только через призму отказов, но и через потенциальные последствия уязвимостей. Для SOC – что приоритизация должна учитывать бизнес-контекст, а не только фор- мальные уровни критичности. Повторим, бюджет на угрозы – это скорее способ договориться, чем отдельная методика. Он поз- воляет свести разные метрики к общему знаменателю – ожидаемым потерям и допустимому уровню риска, чтобы решения принимались в одной системе координат, а не из противоположных позиций SRE и SOC. Амир Хафизов, выпускающий редактор журнала “Информационная безопасность”