Юлия Бузыкова: «Незакрытые критические уязвимости — это прежде всего проблема процессов и ответственности»

Вчера в 17:37

По данным исследования CICADA8, за первое полугодие критические уязвимости, выявленные в начале года, полностью устранили только 14,6% компаний. У 53,5% организаций состав таких уязвимостей не изменился. Для банков, ритейла и цифровых сервисов проблема выходит за рамки технического аудита: незакрытая уязвимость во внешнем контуре может стать точкой входа в инфраструктуру, привести к компрометации клиентских данных и остановке сервисов. 

О том, почему критические находки месяцами остаются без исправления и как выстроить управляемый процесс, журналу RUБЕЖ рассказала Юлия Бузыкова, доцент кафедры информационных технологий факультета информационных технологий и анализа больших данных Финансового университета при Правительстве РФ.

— Какие внешние активы чаще всего выпадают из мониторинга?

Юлия Бузыкова: Обычно это «теневые» и забытые ресурсы. Например, тестовые и staging-контуры, которые временно вывели в интернет, а затем не отключили. Нередко остаются старые поддомены промо-кампаний. Особенно это характерно для ритейла: лендинги запускают быстро, а после завершения акции о них забывают.

В одной из проверок у крупной торговой сети обнаружился поддомен трехлетней давности на неподдерживаемой версии CMS. Формально ресурс относился к зоне ответственности маркетинга, но фактически оставался открытой точкой входа во внешний периметр.

Вне мониторинга также часто оказываются API мобильных приложений, кабинеты партнеров и франчайзи, VPN-шлюзы, почтовые серверы, панели хостинга и сервисы мониторинга. У банков это могут быть сервисы дочерних структур и аутсорсинговых процессинговых центров, у ритейлеров — региональные площадки с кассовыми и складскими веб-интерфейсами. Общая причина — отсутствие актуального реестра внешних активов. Компании контролируют то, о чём помнят, а не то, что действительно доступно из интернета.

— Какие уязвимости наиболее опасны для интернет-банка, интернет-магазина и программы лояльности?

Юлия Бузыкова: Для интернет-банка в первую очередь критичны ошибки в API: недостаточная проверка прав доступа к объектам, нарушения в аутентификации, возможности обхода второго фактора. Отдельный риск — уязвимости удаленного выполнения кода в пограничных системах: VPN, шлюзах, веб-серверах. Они могут дать злоумышленнику первичный доступ, а дальнейший масштаб инцидента зависит от сегментации инфраструктуры.

Для интернет-магазина наиболее чувствительны уязвимости платёжных интеграций и корзины, компрометация скриптов на странице оплаты, ошибки в бизнес-логике API. SQL-инъекции также сохраняют актуальность, но чаще встречаются в устаревших модулях каталогов и самописных фильтрах.

Программы лояльности часто недооценивают. Баллы фактически стали цифровым активом, который можно монетизировать. Здесь распространены credential stuffing — перебор паролей из утечек, ошибки контроля доступа в API мобильных приложений и слабая защита операций списания. В последние годы атаки всё чаще строятся не вокруг одной «дыры в CMS», а вокруг логики API и цепочек доверия между сервисами.

— Почему критические уязвимости могут оставаться незакрытыми месяцами?

Юлия Бузыкова: В большинстве случаев причины организационные, а не технические. Бизнес не всегда готов выделить окно на обновление высоконагруженного сервиса, особенно в период распродаж или в конце квартала. Есть страх нарушить работу сильно кастомизированной или устаревшей системы: тестовый контур не всегда воспроизводит боевую среду.

Еще одна причина — размытая ответственность. Уязвимость может переходить между ИБ-подразделением, ИТ-командой и поставщиком, но конкретного владельца решения нет. Ситуацию усугубляет формальная приоритизация только по CVSS: если в очереди сотни критических находок, действительно опасные могут затеряться.

Даже когда установить патч невозможно, компании иногда не применяют компенсирующие меры — изоляцию системы или виртуальный патчинг на WAF. Для этого также требуется назначенный ответственный и решение со стороны владельца сервиса.

— Что необходимо закрывать немедленно, а что можно перенести?

Юлия Бузыкова: Ориентироваться нужно не только на балл CVSS, а на совокупный риск. Немедленной реакции — в течение часов или нескольких дней — требует сочетание трёх факторов: есть публичный эксплойт либо признаки активной эксплуатации; актив доступен из интернета; за ним находятся персональные или платежные данные.

В такой ситуации необходим патч, изоляция ресурса или виртуальный патчинг на WAF. Откладывать устранение можно, если уязвимость не имеет публичного эксплойта, находится во внутреннем сегменте, защищена компенсирующими мерами и не затрагивает клиентские данные. Но решение должно быть документировано: с конкретным сроком и владельцем. Иначе «отложить» превращается в бездействие.

— Как контролировать риски подрядчиков и внешних сервисов?

Юлия Бузыкова: Требования нужно закреплять до подписания договора. В контракте и SLA должны быть прописаны условия защиты данных, сроки устранения уязвимостей и право на аудит. Для банков важен и регуляторный контур, включая требования к аутсорсингу и информированию Банка России об инцидентах у подрядчиков.

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

Отдельно нужен план выхода: порядок отзыва доступов и работы с данными после прекращения договора. На аудитах регулярно обнаруживаются активные учетные записи бывших сотрудников подрядчиков, которые сохраняются месяцами.

— По каким метрикам руководитель может оценить зрелость процесса управления уязвимостями?

Юлия Бузыкова: Базовые показатели: медианное время устранения критических уязвимостей, доля находок, закрытых в SLA, процент повторного открытия задач, покрытие внешних активов мониторингом, время обнаружения нового опубликованного актива и скорость реакции на уязвимости с публичным эксплойтом.

Признаки формального подхода заметны быстро: показатели не меняются от квартала к кварталу, тикеты массово закрываются в последний день срока, отчёты сканеров растут, а число подтвержденных исправлений — нет.

Руководителю можно провести простой тест: выбрать три критические находки полугодовой давности и проследить их путь — от обнаружения до проверки исправления. Если эту цепочку невозможно восстановить, управляемого процесса нет.

— Что делать в первые 30 дней после обнаружения критической уязвимости?

Юлия Бузыкова: В первую неделю необходимо подтвердить уязвимость и ее фактическую эксплуатируемость, определить затронутые активы и данные, проверить журналы событий на признаки уже состоявшейся атаки. Затем — установить обновление, изолировать ресурс или применить виртуальный патчинг. При риске компрометации нужно сменить затронутые секреты и токены.

Во вторую и третью недели важно провести ретроспективу: как долго существовала проблема, были ли аномалии в доступах и трафике, могли ли пострадать клиентские данные. При признаках утечки персональных данных необходимо учитывать требования к уведомлению Роскомнадзора; банкам также следует действовать с учётом порядка информирования Банка России об инцидентах. Параллельно нужно проверить остальные системы на ту же уязвимость: как правило, она не бывает единичной.

К концу месяца необходимы повторное тестирование, верификация исправления, актуализация реестра активов и разбор причин. У руководства должны быть ответы на три вопроса: устранена ли уязвимость, была ли эксплуатация и какие меры исключат повторение ситуации.

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

Ранее RUБЕЖ писал, что формальная проверка защищённости не гарантирует безопасности системы после её ввода в эксплуатацию. Обновление ПО, подключение внешних сервисов, изменение прав доступа и работа подрядчиков требуют постоянного контроля, понятного распределения ответственности и подтверждения того, что выявленные риски действительно устранены. Подробнее — в материале: «ФСТЭК обновила требования к защите ГИС: почему формальная аттестация не спасает от сбоев и киберрисков».