К обсуждениям

CVE-2026-20294 в SD-WAN Manager: проверка чувствительных данных в логах

Редакция VOne Технологии

Как проверить версии, тип развёртывания и контур журналирования Cisco Catalyst SD-WAN Manager, не раскрывая содержимое логов и не считая очистку заменой обновлению.

Разделите экспозицию и поиск следов

Cisco описывает недостаточный контроль доступа для отдельных типов шаблонов, не включённых в encryption allowlist: низкопривилегированный пользователь может увидеть чувствительные данные в локальных или удалённых журналах. Это означает две разные очереди работ. Первая — определить затронутую версию и обновить Manager. Вторая — понять, где уже хранились логи и кто имел к ним доступ. Не открывайте журналы широкой группе и не вставляйте строки в тикет. Для инвентаризации достаточно типа развёртывания, версии, назначения logging и владельца хранилища.

Сверьте ветку исправления

Advisory перечисляет fixed releases по веткам: например, 20.9.10, 20.12.8, 20.15.6, 20.18.4, 26.1.2 и 26.2.1, а часть промежуточных выпусков требует миграции. Не выбирайте ближайший номер по памяти: точное соответствие зависит от текущей ветки и статуса поддержки. Cisco указывает отсутствие workaround, поэтому фильтр в SIEM или удаление старого файла не заменяют обновление. Если ветка достигла конца сопровождения, зафиксируйте миграцию как отдельное изменение с проверкой совместимости, а не как обычный патч.

Проверьте контур журналирования

Составьте таблицу из четырёх колонок: источник логов, место хранения, группы доступа и срок хранения. Для локального контура отметьте, кто может читать журналы на Manager; для удалённого — какой сервер принимает их и какие роли имеют доступ. Не выполняйте поиск по реальным паролям и не выгружайте весь архив. Review должен проводиться уполномоченной командой по индикаторам, определённым внутренней процедурой, с маскированием найденных значений. Если подтверждено наличие действующих учётных данных, это отдельный секретный инцидент с ротацией, а не приложение к обычному change ticket.

Обновите через canary и контроль ролей

Перед окном сохраните поддерживаемую резервную копию, проверенный путь восстановления и список интеграций. На canary подтвердите точную версию, вход штатных ролей, создание обычного диагностического события и доставку журнала без просмотра его чувствительного содержимого. После обновления повторите проверку доступа: низкопривилегированная роль не должна получать лишние данные, но валидировать это нужно утверждённым тестом производителя или внутренней QA-процедурой, а не попыткой извлечь секрет. Стоп-критерий — неизвестная ветка исправления, сбой синхронизации или потеря доступа к управлению.

Зафиксируйте две даты закрытия

У записи об уязвимости должна быть дата подтверждённого обновления, а у review журналов — собственная дата и владелец. Эти задачи могут завершиться не одновременно. Cisco PSIRT не знала о публичных объявлениях или вредоносном использовании на момент выхода advisory; формулировка не доказывает, что конкретные логи никто не читал. В итоговом пакете оставьте версию, тип развёртывания, контуры хранения, результат проверки ролей и статус ротации секретов без самих секретов. Закрывайте риск только после завершения обеих веток либо документированного принятия остаточного риска.

Материал подготовлен редакцией VOne с применением ИИ для структуры; типы развёртывания, fixed releases, влияние на логи и отсутствие workaround вручную сверены по первичному advisory Cisco.

Источники и проверка

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

Ответы

0 опубликовано
Ответов пока нет. Вы можете начать обсуждение.

Ваш ответ

Добавьте свой опыт или уточнение по теме.

Вы публикуете как Аноним Аватар отличает разговоры, но не раскрывает личные данные.

Ответ появится сразу. Не публикуйте личные данные, ключи и приватные ссылки.