F5 ADSP | 13 августа 2026 года
В июле я написал о нашем переходе к ежемесячным hardened-релизам и ежемесячным уведомлениям о безопасности. Тогда я сказал, что этот график подходит для нашего текущего положения и что та же дисциплина, которая позволила нам отказаться от квартальных релизов, позволит нам сделать это снова, когда того потребует ситуация.
Прошёл один цикл релизов, и мы многое узнали. Мы учились у клиентов, у партнёров и наблюдали, как ежемесячный график работает в производственных средах. Некоторые из того, что мы узнали, меняют наш подход.
Начиная с HR2 2 сентября hardened-релизы будут выходить с шестинедельным циклом, а не ежемесячно. И мы приостанавливаем регулярные уведомления о безопасности, которые мы планировали публиковать вместе с ними.
Я хочу объяснить, как мы пришли к этому, потому что логика важнее дат.
Что нам рассказали клиенты
Мы выпустили HR1 15 июля, а затем сделали то, что обещали: мы слушали.
То, что мы услышали, было последовательным, и это было не совсем связано с F5. Организации, использующие наши продукты в своих наиболее критических процессах, рассказали нам, что ежемесячный график не давал им достаточно времени для тестирования, подготовки и развертывания — не обязательно потому, что наши релизы было трудно усвоить в изоляции, а потому, что они поступали одновременно со всеми остальными. Каждый серьёзный поставщик реагирует на те же изменения, и совокупное бремя ложится на ту же ограниченную команду внутри каждого предприятия.
Шесть недель — это признание того, что исправление, которое никто не может развернуть, не является исправлением. Скорость, с которой клиенты могут усвоить изменение, теперь является частью уравнения безопасности, и график, который опережает усвоение, создаёт риск, а не снижает его.
«Организации ставят F5 между своими пользователями и своими приложениями, своими агентами и своими API. Именно это положение объясняет, почему мы находим и исправляем проблемы с той скоростью, с которой мы это делаем, почему мы тестируем так, как тестируем, и почему мы приняли то решение, которое приняли, относительно раскрытия информации.»
Другое, что мы узнали, указывает в противоположном направлении. Клиенты, которые инвестировали в управление парком и автоматизацию, наблюдают значительные улучшения в скорости, с которой они могут обновляться. Глобальный клиент с большим парком F5 BIG-IP сократил время обновления с более чем шести месяцев до примерно двух недель.
Почему мы приостанавливаем уведомления о безопасности
Второе изменение более сложное, и я хочу быть прямым относительно логики.
Когда мы объявили о ежемесячных уведомлениях о безопасности, мы предполагали, что примерно 30-дневная задержка между hardened-релизом и раскрытием информации даст клиентам возможность обновиться до того, как детали станут публичными. Это предположение отражало наше лучшее суждение на тот момент.
Теперь это уже не так. Разговоры с клиентами и с другими представителями отрасли за последние несколько недель изменили нашу оценку того, сколько информации на самом деле требуется для создания работоспособного эксплойта. Модели-первопроходцы продолжают совершенствоваться в выводах на основе ограниченных сигналов — разницы, частичного описания, диапазона версий — до функционирующей цепочки атаки. Окно, которое, как мы думали, мы создаём для защитников, на практике является окном и для атакующих, и оно сужается.
Поэтому мы приостанавливаем регулярные уведомления, пока мы коллективно работаем над тем, как выглядит ответственное раскрытие информации в этой среде. Будут исключения. Когда уязвимость активно эксплуатируется, когда мы координируем действия с исследователями или государственными агентствами, или когда это требуют нормативные или договорные обязательства, мы будем обрабатывать раскрытие информации по-другому. Это не постоянная позиция в отношении прозрачности. Это решение, принятое при условии, что защита клиентов важнее всего, и мы будем продолжать его оценивать.
Я понимаю, что это неудобно. Это неудобно для меня как бывшего CISO. Нормы раскрытия информации существуют по веским причинам, и сообщество безопасности построило их за десятилетия тяжёлого опыта. Однако эти нормы были настроены для мира, где разрыв между «опубликованием деталей» и «доступностью эксплойта» измерялся неделями. Этот разрыв исчез, и каждая организация, которая публикует информацию об уязвимостях, должна будет разобраться, что это означает.
Более сложный вопрос: сортировка без оценки серьёзности
Это та часть, с которой, по моему мнению, отрасль ещё не полностью разобралась.
Большинство программ управления уязвимостями построены на оценке серьёзности. Критические исправляются в течение 24 часов, высокие — за три дня, средние — в спринте, низкие — когда есть время. Эта модель предполагает два вещи: что оценки серьёзности значимо предсказывают риск и что у вас есть оценки серьёзности, с которыми можно работать.
Оба предположения разрушаются.
Первое разрушается потому, что атакующие, использующие модели-первопроходцы, не нуждаются в критической уязвимости. Они создают цепочку. Три проблемы низкой серьёзности, которые по отдельности могут находиться в нижней части очереди сортировки, становятся работоспособным путём к компрометации, когда модель может сделать выводы по всем трём одновременно. Когда мы сканируем свой собственный код, мы находим этот класс проблем: проблемы низкой серьёзности, которые могут быть связаны в цепочку. Систематическое устранение их — это то, что делает программное обеспечение более устойчивым. Индивидуальная сортировка их по серьёзности оставляет их на месте.
Второе предположение разрушается потому, что поставщики — в том числе и мы — будут публиковать меньше деталей и позже. Это будет ощущаться как потеря контроля со стороны команд безопасности, и я понимаю, почему.
Итак, что вы делаете вместо этого?
Приоритизируйте по риску, а не по оценке. Доступность, интернет-риск, радиус поражения и критичность для бизнеса — это более устойчивые входные данные, чем оценка CVSS, которую вы можете не получить. Актив, который подвержен риску и не исправлен, является риском независимо от того, что говорит уведомление.
Будьте в курсе как дисциплина. Организации, которые будут хорошо себя чувствовать в этой среде, — это те, которые рассматривают «работу с последним hardened-релизом» как постоянное оперативное обязательство, а не как событие, вызванное оценкой серьёзности. Это культурный сдвиг так же, как и технический, и он требует поддержки руководства, чтобы быть устойчивым.
Инвестируйте в потенциал усвоения сейчас. Автоматизация, видимость парка, повторяемые окна обслуживания и протестированное откатывание — это то, что делает более быстрый график выживаемым. Эти инвестиции сейчас выглядят необязательными. Через год они не будут выглядеть необязательными.
Предполагайте, что разрыв будет существовать, и защищайте его. Ни одна организация не исправляет мгновенно. Защита во время выполнения — поведенческое обнаружение, виртуальное исправление, механизмы контроля, которые не зависят от знания конкретной уязвимости — могут помочь закрыть окно между исправлением, которое существует, и исправлением, которое развернуто. Это окно не исчезнет. Планируйте его, а не вокруг него.
О том, как мы меняем своё мнение
Мы приняли решение в июле на основе лучшей информации, которая у нас была. Мы реализовали его на практике, учились у клиентов и партнёров и корректировали. Альтернатива — придерживаться позиции, потому что мы объявили о ней, — была бы хуже для клиентов и партнёров.
Я сказал в июле, что мы будем продолжать адаптироваться по мере того, как ситуация и ваши потребности будут развиваться. Вот как это выглядит на практике. Честная позиция любого поставщика сейчас заключается в том, что устоявшаяся практика пересматривается в реальном времени по всей отрасли, и любой, кто утверждает, что полностью решил эту проблему, не обращает внимания.
Что не меняется, так это стандарт, к которому мы придерживаемся. Организации размещают F5 между своими пользователями и приложениями, своими агентами и API. Именно эта позиция заставляет нас находить и устранять проблемы с такой скоростью, тестировать именно так и принимать решение о раскрытии. Спасибо за обратную связь, которая сформировала это. Продолжайте присылать её и оставайтесь в курсе.
О авторе
КуНал Ананд возглавляет продуктовую организацию F5 в качестве Главного продуктового директора. Он отвечает за видение продукта, стратегию и исполнение, обеспечивая разработку прорывных решений, которые решают критические задачи и создают исключительный опыт для клиентов. В своей предыдущей роли в качестве Главного технологического и ИИ-офицера КуНал определял технологическую и ИИ-стратегию и видение компании. До F5 КуНал занимал двойную должность Главного технологического директора и Главного информационного безопасности офицера в Imperva. Его путь в Imperva начался в 2018 году с приобретения Prevoty, стартапа по безопасности приложений, который он соучредил в 2013 году. До присоединения к Prevoty он был директором по технологиям в BBC Worldwide. КуНал имеет глубокий опыт инноваций и технической экспертизы, занимал руководящие должности в области безопасности, данных, технологий и инженерии в Gravity, MySpace и NASA Jet Propulsion Lab. У КуНала более 15 лет опыта в области ИИ и машинного обучения, от обучения моделей до применения алгоритмов на основе ИИ для улучшения продуктов, и проектирования и реализации архитектур ИИ. КуНал имеет степень бакалавра наук по компьютерным наукам из Babson College.
