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

Vulnerability management (управление уязвимостями) — это непрерывный циклический процесс, направленный на выявление и устранение слабых мест в ИТ-инфраструктуре до того, как до них доберутся злоумышленники.

Как показывает статистика, количество опубликованных уязвимостей растёт из года в год — в 2024 году количество CVE возросло на 38% по сравнению с годом ранее. Это отражает не только рост цифровой среды, но и усложнение технологических стеков, где всё труднее контролировать поверхность атаки.

Чтобы показать, насколько критичными могут быть такие уязвимости, приведу несколько реальных примеров, с которыми мы сталкивались в процессе работы:

• CVE-2025-49844 — удалённое выполнение кода на сервере Redis;

• CVE-2025-20333, CVE-2025-20362 — позволяют атакующему обойти аутентификацию и выполнить произвольный код на Cisco ASA/FTD, подменяя параметры VPN-запросов;

• CVE-2025-53770, CVE-2025-53771 — позволяют выполнить произвольный код и получить доступ к защищённым путям на сервере SharePoint, обходя проверки через десериализацию и подделку заголовков.

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

Далее в статье будут затронуты эти и другие этапы жизненного цикла управления уязвимостями.

Инвентаризация активов

Инвентаризация активов — это первый шаг, с которого начинается процесс управления уязвимостями. Инвентарная база — это не просто список устройств, это фундамент для оценки, приоритизации и устранения уязвимостей. Старая поговорка верно гласит: «Нельзя защитить то, чего не видишь».

На данном этапе важным является качество и точность собранной информации — от этого будет зависеть эффективность процесса управления уязвимостями (VM) в дальнейшем. Если не следить за актуальностью базы активов, это может привести к появлению Shadow IT в вашей инфраструктуре — и зачастую злоумышленники могут скомпрометировать именно такие системы, поскольку они не учтены в процессах управления уязвимостями и других процессах ИБ и, соответственно, такие системы могут быть подвержены различным критичным уязвимостям или иметь небезопасную конфигурацию.

Shadow IT (теневое ИТ) — это приложения, сервисы, оборудование или технологии, которые используются сотрудниками в рамках рабочих процессов без контроля и согласования со стороны ИТ-отделов или руководства компании.

Для чего нужны системы инвентаризации ИТ-активов с точки зрения управления уязвимостями?

1. Точное определение поверхности атаки.

2. Приоритизация уязвимостей.

3. Улучшение процессов обновления и устранения уязвимостей.

В качестве source-of-truth мы используем три системы:

1. Netbox — источник информации о железных серверах и виртуальных машинах, расположенных в ЦОД, офисах или на операционных объектах;

2. Fleet&osquery — источник информации о корпоративных устройствах сотрудников;

3. ITCrowd — собственная система, предназначенная для учёта всех разрабатываемых сервисов, ресурсов внутренней облачной инфраструктуры и платформенных решений (PaaS).

Мы регулярно проводим автоматизированную верификацию данных об активах с альтернативными системами инвентаризации, включая EDR, MDM и другие источники.

Сканирование и обнаружение уязвимостей

Источник 1. Внутренний сканер уязвимостей

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

Первым делом мы подготовили регламенты для ИТ-подразделений и согласовали процедуру регулярного сканирования на уязвимости.

Затем мы начали постепенно проводить первые сканирования с аутентификацией и расширять покрытие внутренней инфраструктуры регулярными сканами.

Сканирование с аутентификацией — это вид сетевого сканирования, при котором сканер уязвимостей получает доступ к целевой системе с использованием учётных данных (логин/пароль, SSH-ключи, сертификаты, токены). Такой подход значительно повышает точность результатов, снижает количество ложных срабатываний и позволяет выявлять риски, связанные с устаревшим ПО, неправильной конфигурацией и отсутствием обновлений безопасности.

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

Для более гибкой настройки сканирования активы были сгруппированы по двум критериям:

• команда, администрирующая сервер — информация из Netbox о том, кто отвечает за администрирование;

• операционная платформа — информация из Netbox: Windows, Linux, etc.

На основе этих групп сформированы отдельные задания на сканерах. Каждое задание охватывает все хосты с одной платформой, принадлежащие конкретной команде. Примеры:

• [os:windows][team:1st_team] auth scan

• [os:linux][team:2nd_team] auth scan

• [os:windows][team:2nd_team] auth scan

Для каждой платформы мы создали отдельную политику с соответствующими настройками.

Мы используем network-based-сканирование, которое, в отличие от agent-based-подхода, может создавать дополнительную нагрузку как на сканируемые сервера, так и на сеть. Поэтому для сервисной учётной записи на всех сканируемых серверах Linux, которая используется нашим сканером для аутентифицированного сканирования, мы установили следующие ограничения с помощью systemd.slice:

• лимит для CPU устанавливается в 20% (100% = 1 CPU);

• лимит для Memory (RAM) устанавливается в 5% от общего количества памяти;

• лимит для IO устанавливается в 20M.

Пример конфигурационного файла user-1010.slice по ограничению вычислительных ресурсов для сервисного пользователя srv_user:

[Unit]
Description=Limit cpu/ram/io for user srv_user with UID 1010
Documentation=man:systemd.special(7)
Before=slices.target
 
[Slice]
MemoryAccounting=True
MemoryHigh=396M
CPUAccounting=True
CPUQuota=20%
IOAccounting=True
IOReadBandwidthMax=/ 20M
IOWriteBandwidthMax=/ 20M
 
[Install]
WantedBy=multi-user.target

Поскольку сканирование Windows-серверов не оказывало существенного влияния на их производительность, ограничение по ресурсам для сервисного пользователя на этих серверах не внедрялось.

Источник 2. Агрегатор известных уязвимостей

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

На рынке доступны как бесплатные решения (например, база данных уязвимостей NVD, открытая база vulnerability-db), так и коммерческие платформы от вендоров, предлагающие расширенное обогащение и более высокую скорость обновлений. Выбор подходящего инструмента зависит от ваших требований: насколько критична скорость получения данных, необходима ли глубина обогащения данных или достаточно базового уровня осведомлённости.

Мы отслеживаем новые уязвимости, которые потенциально применимы к технологическому стеку Ozon и в течение двух часов после публикации CVE создаём внутренний VULN-тикет для дальнейшей обработки и принятия решения о применимости к нашей инфраструктуре.

Мы разработали плейбук по обработке поступающих уязвимостей, где подробно описали последовательность действий при получении VULN-тикета, зоны ответственности всех участников процесса и SLA для каждого шага.

В рамках этого плейбука был сформирован полноценный процесс оперативного реагирования и устранения уязвимостей, охватывающий не только нашу команду, но и ключевые подразделения всего департамента информационной безопасности. Процесс включает в себя взаимодействие между первой линией SOC, которая осуществляет круглосуточный мониторинг 24/7, и механизм эскалации на профильные команды в случае выявления критичных уязвимостей или признаков их эксплуатации. Это позволяет обеспечить своевременное реагирование и повысить прозрачность обработки уязвимостей на всех этапах.

Источник 3. Внешний сканер периметра

Аналогично внутреннему сканированию на уязвимости, мы сканируем внешний периметр на предмет открытых портов и наличия уязвимостей, в том числе мисконфигураций. Опять же, источником правды для сканеров является информация из Netbox: внешние IP-адреса, ASN, принадлежащие Ozon, и список доменных имён для публично доступных сервисов Ozon.

Приоритизация устранения

Согласно серии исследований Prioritization to Prediction (P2P), проведённых Cyentia Institute, среднестатистическая организация независимо от количества активов в её инфраструктуре устраняет лишь 10% уязвимостей от общего числа всех уязвимостей выявленных за календарный месяц. Cyentia рекомендует приоритизировать все уязвимости на основе информации о доступности публичных эксплойтов и в своих статьях приводит аргументы о том, что самая эффективная стратегия — в первую очередь устранять уязвимости с доступным кодом эксплойта.

Грамотная приоритизация и фокусирование на уязвимостях с доступным кодом эксплойта позволяют значительно снизить количество критичных уязвимостей в организации.

Перед тем как завести задачу на устранение, мы проводим анализ и приоритизацию уязвимостей. Мы опираемся на такие критерии как:

1. Критичность.

   Ориентируемся на системы оценки уязвимостей CVSS, Tenable VPR, Vulners AI Score в связке с критичностью сервиса, для которого та или иная уязвимость является применимой.

2. Вероятность эксплуатации и/или наличие публичного эксплойта.

   Анализируем источники информации, такие как CISA KEV, PoC-in-GitHub, Exploit-DB, Metasploit и другие ресурсы, где публикуются публичные эксплойты. Также ориентируемся на метрику EPSS.

3. Программное обеспечение End-of-Life/ End-of-Support.

   Производитель зачастую не предоставляет патчи с исправлениями для устаревшего ПО или делает это на платных условиях, как в случае с Ubuntu Pro.

4. Тип доступности затронутого актива.

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

5. Поверхность атаки.

   Определяем точное количество затронутых активов. Если уязвимость затрагивает 3 сервера — это одно, если 300 — совсем другое. Масштаб напрямую влияет на срочность реагирования и объём нагрузки на ИТ-команды.

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

Устранение уязвимостей

Существует несколько способов устранения уязвимостей. Наиболее предпочтительными способами устранения уязвимостей являются:

1. Установка обновлений (патчей). Патчи представляют собой исправления, выпущенные производителями программного обеспечения, чтобы устранить известные уязвимости.

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

Бывают и другие, реже используемые способы:

1. Сетевая изоляция. Ограничение входящего и/или исходящего сетевого трафика только теми портами и протоколами, которые нужны для работы сервиса.

2. Отключение уязвимого компонента. Например, если уязвимость обнаружена в веб-интерфейсе сервиса, но есть альтернативный способ взаимодействия с системой, допустим, через командную строку, то можно рассмотреть вариант с отключением веб-интерфейса как службы.

3. Виртуальный патчинг. Предотвращение попыток эксплуатации уязвимостей с помощью WAF или IPS.

4. Применение workaround. Все вышеперечисленные способы можно обобщить и назвать workaround — основная цель данного способа снизить риск эксплуатации путём применения временного решения до окончательного устранения уязвимости.

5. Принятие риска. Данный способ предполагает документированное согласие руководства компании на продолжение использования уязвимых сервисов с принятием всех рисков.

На данном этапе важную роль играет процесс Patch Management — это отдельный процесс, который является частью Vulnerability Management. Данный процесс помогает устранять уязвимости путём регулярной установки обновлений безопасности со стороны ИТ-подразделений на своих серверах.

Patch Management (управление обновлениями) — это организованный процесс установки обновлений для программ и операционных систем с целью устранения уязвимостей, исправления ошибок и повышения стабильности работы.

В настоящее время в Ozon внедрён и регулярно совершенствуется процесс Patch Management для Windows и Linux-серверов. В случае с Windows полный цикл установки обновлений составляет 30 календарных дней, а для Linux один цикл занимает 90 календарных дней. Сроки установки обновлений выбраны исходя из особенностей эксплуатации соответствующих систем:

• Windows-серверы чаще используются для пользовательских сервисов и интегрированы с AD, Exchange и другими компонентами, где уязвимости активно эксплуатируются. Кроме того, Microsoft публикует обновления каждый второй вторник месяца (Patch Tuesday), что упрощает планирование. Поэтому цикл обновлений ограничен 30 календарными днями, чтобы минимизировать окно риска;

• Linux-серверы, как правило, обслуживают инфраструктурные или бэкенд-сервисы, где обновления требуют более тщательной проверки на совместимость, чтобы избежать сбоев в работе продуктовых сервисов. Также производители Linux-дистрибутивов публикуют обновления безопасности нерегулярно, что усложняет централизованное планирование. Поэтому цикл обновлений составляет 90 дней, что позволяет сбалансировать безопасность и стабильность.

ИТ-команды отвечают за тестирование и установку обновлений на всех своих серверах. Команда ИБ контролирует процесс установки обновлений ИТ-подразделениями. На те команды, которые нарушают установленные сроки согласно утверждённым регламентам по регулярной установке обновлений на серверах, мы автоматически заводим RISK-тикеты на основе результатов сканирования и выявленных уязвимостей.

Мы в Ozon используем проект RISK как основной инструмент взаимодействия между командами ИБ и ИТ-подразделениями. Проект RISK предоставляет широкий набор полезных механизмов как для исполнителя, так и для ответственного за риск со стороны ИБ. Рассмотрим основные преимущества такого подхода.

• Структурированная подача информации. Каждый риск-тикет создаётся по шаблону: краткое описание уязвимости, список затронутых активов, пути эксплуатации, рекомендации по исправлению. Это позволяет быстрее ориентироваться в тикете;

• Механизм напоминаний работает в обе стороны. Об открытом риск-тикете приходят напоминания исполнителю, и в то же время напоминания об истекающих сроках приходят сопровождающему инженеру со стороны ИБ;

• Механизм эскалаций. Если исполнитель игнорирует тикет, то такой тикет будет автоматически эскалироваться до руководителя группы, затем до руководителя отдела и так вплоть до СТО;

• Система рейтинга сервисов. Если у команды есть открытые риск-тикеты, то для этой команды будут заблокированы все релизы до тех пор, пока она не устранит все открытые риск-тикеты. И наоборот — если у сервисов, которые разрабатывает команда, нет открытых риск-тикетов, то внутренний рейтинг таких сервисов будет выше;

• Прозрачные сроки на устранение и понятные ожидания для всех сторон. Конкретные SLA задокументированы для каждого уровня критичности RISK-тикета и согласованы между исполнителем и сопровождающим со стороны ИБ, что обеспечивает единое понимание сроков.

Контроль устранения уязвимостей

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

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

Если вы не доверяете результатам сканера, то можно прибегнуть к иным способам проверки, таким как: nmap с его nse-скриптами для работы с уязвимостями, burp suite для ручной обработки, редактирования http-запросов и анализа ответов веб-приложений, тестирование доступных эксплойтов для конкретной уязвимости. Стоит отметить, что перед применением любого PoC/exploit нужно убедиться, что в исходном коде эксплойта не заложены логические бомбы или другие деструктивные действия.
Не рекомендуется применить PoC/exploit на «боевом» экземпляре системы, лучше проверять на STG с версией, которая идентична версии на PROD.

Для нас в Ozon важна скорость проверки исправления уязвимостей, поэтому мы стараемся ежедневно сканировать все наши ИТ-активы, чтобы ежедневно получать актуальную информацию по состоянию защищённости активов и соблюдать SLA на проверку исправления уязвимостей в проекте RISK.

Обучение и осведомлённость

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

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

• курс по безопасной разработке. Разработчики ПО — один из главных источников появления уязвимостей. Данный курс учит писать код без типичных уязвимостей (OWASP Top 10 и другие).

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

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

Чек-лист VM’щика: советы специалисту по управлению уязвимостями

1. Инвентаризация активов.

   • Определите ваши источники правды об ИТ-активах;

   • Определите ответственного за поддержание процесса инвентаризации активов. Это может быть команда, которая разворачивает серверы;

   • Следите за актуальностью ваших ИТ-активов, регулярно выполняя кросс-чеки всех доступных систем инвентаризации.

2. Сканирование и обнаружение уязвимостей.

   • Зафиксируйте все источники информации об уязвимостях, используемые в вашей инфраструктуре;

   • Подготовьте сервисные учётные записи для выполнения аутентифицированного сканирования на платформах Windows, Linux и др.;

   • Настройте мониторинг активности сервисных учётных записей, чтобы своевременно выявлять признаки их компрометации;

   • Разработайте отдельные политики сканирования для каждой платформы и при необходимости задайте ограничения сканеру по потреблению вычислительных ресурсов на сканируемых хостах;

   • Настройте расписание сканирования с учётом бизнес-процессов: избегайте сканирования в часы пиковых нагрузок.

3. Приоритизация устранения

   • Определите список критичных активов;

   • Учитывайте тип доступности актива (публичный, внутренний, ограниченный) на этапе приоритизации;

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

4. Устранение уязвимостей

   • Регламентируйте способы и сроки устранения уязвимостей;

   • Обязательно тестируйте обновления на небольших тестовых группах серверов перед доставкой и установкой обновлений на все серверы;

   • Сроки тестирования могут составлять от нескольких часов до нескольких дней. Обычно, если обновления содержит баги, нарушающие стабильность системы, это будет обнаружено в течение нескольких часов после установки.

5. Контроль устранения уязвимостей

   • Настройте контроль за аутентифицированным сканированием, поскольку для принятия решений важно получать полные результаты и видеть всю картину целиком;

   • Внедрите метрики и визуализацию прогресса устранения: отслеживайте статус по командам, платформам, критичности, SLA и другим параметрам.

Дальнейшие планы

Мы наметили следующие направления для развития.

1. Автоматизировать процесс контроля за устранением уязвимостей везде, где это возможно.

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

3. Внедрить процессы Patch Management для всех типов активов в ИТ-инфраструктуре.

4. Использовать информацию об уязвимостях в процессе Device Compliance для принятия решения о допуске устройства пользователя в корпоративную сеть.

5. Реализовать непрерывный процесс поиска неучтённых активов или теневого ИТ.

Заключение

В завершение — немного ключевых результатов и цифр, демонстрирующих, как внедрение процесса управления уязвимостями повлияло на нашу инфраструктуру.

• С момента запуска процесса обработки VULN-тикетов в конце 2023 года мы обработали более 2800 VULN-тикетов, связанных с релевантными уязвимостями. Это позволило ускорить реагирование, повысить качество устранения и улучшить контроль над инвентаризацией активов;

• На данный момент мы достигли 98% покрытия регулярными сканированиями серверной инфраструктуры (Windows и Linux), что стало основой для внедрения Patch Management. Оставшиеся 2% составляют хосты с ограниченным доступом — из-за ошибок аутентификации, проблем сетевой связности или нестандартных конфигураций. Для таких случаев у нас выстроены процессы контроля: ведётся учёт проблемных хостов и предпринимаются меры для восстановления возможности сканирования;

• Благодаря внедрению Patch Management команды начали выводить из эксплуатации неиспользуемые, но активные серверы, что позволило освободить ресурсы для новых серверов;

• Мы также настроили непрерывный контроль за использованием устаревших версий операционных систем, что повысило уровень защищённости.

Благодаря всему вышеперечисленному, мы сократили время реакции, устранили ранее незаметные пробелы в защите и усилили фокус на критичных активах.

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

А если вам интересно заниматься поиском уязвимостей или вы обнаружили проблему безопасности в сервисах Ozon, то приглашаем вас принять участие в нашей программе Bug Bounty.