Управление уязвимостями: выбор Tenable, Qualys, Rapid7

Почему «количество CVE» не помогает управлять риском

Счетчик CVE выглядит убедительно: «у нас найдено 12 000 уязвимостей». Но это почти ничего не говорит о риске. CVE - это идентификатор, а не ответ на вопросы: где именно проблема, насколько она доступна злоумышленнику и что будет, если ее используют.

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

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

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

Руководителей обычно не интересует, сколько CVE вы нашли. Их интересует, что может случиться и что вы делаете в первую очередь. Типичные вопросы:

• Какие 10 систем сейчас под наибольшим риском и почему?
• Есть ли уязвимости, которые уже активно эксплуатируют?
• Что изменится, если мы не исправим это в течение месяца?
• Сколько ресурсов нужно, чтобы снизить риск заметно, а не «чуть-чуть»?
• Кто отвечает за исправления и как мы контролируем сроки?

Если цель - управление уязвимостями, метрика «количество CVE» должна уходить на второй план. На первом месте - приоритеты, понятные бизнесу: какие активы важнее, какие угрозы реальнее и какие действия дадут максимальное снижение риска в ближайшие недели.

С чего начинается зрелый процесс управления уязвимостями

Зрелое управление уязвимостями начинается не со сканера и не с отчета, а с простого ответа на вопрос: что именно вы защищаете и кто за это отвечает. Если этого нет, любые цифры по CVE будут шумом, а команда будет тратить время на «самые громкие» находки вместо реально рискованных.

Определите активы и границы сканирования

Сначала договоритесь, что вы считаете «активом». Для одних это только серверы и сетевое оборудование, для других - еще рабочие места, виртуальные машины, облачные сервисы, приложения и даже «временные» стенды.

Полезно зафиксировать четыре вещи: какие сегменты входят в охват сейчас и какие позже; как актив попадает в учет (закупка, выдача, подключение к сети); какие атрибуты обязательны (владелец, критичность, среда - prod или test); как вы закрываете «слепые зоны» (удаленные ноутбуки, филиалы, отдельные VLAN).

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

Назначьте владельцев и правила риск-исключений

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

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

Согласуйте SLA и разрежьте поток уязвимостей по типам

SLA лучше считать не только по критичности, но и по типу актива и доступности извне. Уязвимость на внешнем периметре и на внутреннем рабочем месте требуют разной скорости реакции.

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

Приоритизация: какие сигналы важнее одного CVSS

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

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

Сигналы, которые обычно важнее «голого» CVSS

Начните с набора, который можно поддерживать постоянно:

• Доказанная эксплуатация. Если есть подтверждения, что уязвимость уже используют, это почти всегда выше любой теории.
• KEV и похожие списки. Попадание в такие перечни должно включать режим «срочно», особенно для периметра и админских интерфейсов.
• EPSS. Используйте как оценку вероятности эксплуатации в ближайшее время, чтобы отделять «громкие» темы от тех, на которые реально охотятся.
• Критичность актива. Важнее всего бизнес-сервис, данные и требования по доступности.
• Контекст сети. Интернет-экспозиция, сегмент, привилегии, возможность бокового перемещения.

Короткий пример

Представьте две находки с CVSS 9.8. Первая - на рабочей станции бухгалтера, без админских прав, в сегменте с жесткими правилами. Вторая - на веб-сервере, доступном из интернета, который обслуживает личный кабинет и связан с базой данных.

Если у второй уязвимости высокий EPSS или она в списке KEV, приоритет очевиден: исправлять ее первой, даже если «по баллам» обе одинаковые. Для первой можно запланировать окно обновлений, убедиться в наличии компенсаций (например, EDR, ограничение прав, сегментация) и закрыть риск без паники.

Полезная привычка - фиксировать правило приоритета письменно. Например: «KEV на интернет-экспонированных узлах - исправить за 72 часа». Тогда приоритизация станет повторяемой, а не спором о цифрах.

Доказательство эксплуатации и реальная проверка угроз

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

Важно различать два похожих сигнала. Exploit available означает, что эксплойт существует (опубликован PoC, модуль для Metasploit и т.д.). Это повышает вероятность атак, но не доказывает, что вас уже пытались взломать. Exploited in the wild означает подтвержденные случаи эксплуатации в реальных атаках (по данным вендоров, CERT, аналитики угроз). Такой сигнал почти всегда поднимает приоритет, даже если уязвимость не «критическая» по CVSS.

Как проверить факт эксплуатации в своей среде

Тут помогают не только отчеты сканера, но и телеметрия. Практичный минимум:

• Логи периметра и веб-шлюзов: всплески 4xx/5xx, необычные URI, попытки загрузки файлов, странные User-Agent.
• EDR-события: подозрительные процессы от имени сервисов, child-process от веб-сервера, массовые соединения, попытки дампа учетных данных.
• Сетевые события: исходящие соединения на редкие страны/ASN, DNS к новым доменам, нетипичные порты, признаки C2.
• Логи аутентификации: аномальные входы, рост неуспешных попыток, новые админские сессии.

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

Когда «средняя» уязвимость становится критичной

Атаки часто идут цепочкой. Уязвимость со средним баллом может стать критичной, если она открывает путь к следующему шагу: обход аутентификации -> чтение конфигов -> кража токенов -> доступ к AD или к системе управления.

Чтобы снижать ложные тревоги без потери контроля, используйте простые правила: подтверждайте наличие уязвимого компонента (а не только «похоже по баннеру»), проверяйте доступность с точки зрения атакующего (изнутри сети или снаружи), фиксируйте исключения по сроку и компенсирующим мерам (изоляция, WAF, запрет исходящих, EDR-политики). Это уменьшает шум и удерживает фокус на том, что реально ведет к инциденту.

Интеграции с ITSM: как не утонуть в тикетах

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

Начните со связки с CMDB. Без нее у уязвимости нет контекста: чей это сервер, насколько он важен, когда можно менять, кто согласует простой. В CMDB должны быть хотя бы владелец сервиса, критичность, среда (prod или test) и окно изменений. Тогда одна и та же уязвимость на терминальном сервере бухгалтерии и на тестовом стенде будет вести себя по-разному.

Хорошая интеграция с ITSM начинается с шаблона тикета. В тикете должно быть достаточно данных, чтобы инженер мог действовать без дополнительных «уточнений в чате».

Что стоит закрепить в шаблоне тикета

• Актив и сервис: имя, окружение, владелец, критичность из CMDB.
• Суть проблемы: уязвимость, затронутое ПО, версия, подтверждение наличия на активе.
• Рекомендованное действие: патч, настройка, временная мера, проверка после исправления.
• Приоритет и срок: правило расчета, SLA, дата повторной проверки.
• Доказательства: коротко, почему это важно именно здесь (например, есть внешний доступ или актив в критичном сегменте).

Дальше решает назначение. Лучше, когда исполнитель определяется автоматически по данным CMDB: команда платформы, владелец приложения или подрядчик. Это снижает перекидывание тикетов и помогает контролировать SLA. Если есть отдельная команда изменений, добавьте правило: задачи, которые требуют перезагрузки или остановки сервиса, сразу получают статус, требующий согласования окна.

Не менее важна обратная связь. Закрытие тикета не должно быть финалом, если сканер не увидел исправление. Нужен двусторонний обмен: статус тикета обновляет статус уязвимости, а повторный скан либо подтверждает закрытие, либо переоткрывает задачу с комментарием, что именно осталось.

Как выглядит рабочий цикл на практике

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

Продумайте уведомления и исключения. Временные исключения должны утверждаться конкретной ролью (владелец риска или ИБ), иметь срок и причину. Иначе исключения превращаются в бесконечный список «потом разберемся». Практичное правило: любое исключение автоматически напоминает за 7-14 дней до окончания и требует либо продления, либо плана устранения.

Если вы работаете с системным интегратором вроде GSE.kz, заранее согласуйте, кто владеет CMDB, кто отвечает за правила назначения и кто подписывает исключения. Тогда интеграция с ITSM станет не генератором шума, а управляемым конвейером исправлений.

Отчетность для руководства: что показывать вместо таблиц CVE

Руководству редко важно, сколько найдено CVE. Им важно, какой это дает риск и что вы делаете, чтобы риск снижался по плану. Хороший отчет переводит технические детали в короткие ответы: где больно, что меняется, что просрочено и что мешает закрывать быстрее.

Метрики, которые понятны бизнесу

Вместо перечня уязвимостей покажите 5-6 показателей, которые читаются за минуту:

• Текущий риск и тренд за 30-90 дней (растет или снижается), отдельно по критичным сервисам.
• Выполнение SLA по устранению и доля просрочки.
• Топ-10 рисков: по ключевым сервисам, подразделениям и отдельно по интернет-узлам.
• Прогресс за период: сколько закрыто, сколько открыто снова, главные причины задержек.
• Исключения: сколько активных, на какой срок, кто утвердил и на чем основано решение.

Показывайте не «в среднем по больнице», а разрез, который совпадает с тем, как компания управляет ИТ: филиалы, бизнес-сервисы, типы систем (серверы, рабочие места), периметр.

Как объяснять «почему не закрыли» без оправданий

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

Отдельно показывайте качество данных. Если покрытие сканирования 85%, а 15% активов «неизвестны», риск в отчете занижен. Пример формулировки: «интернет-узлы покрыты на 100%, серверы - 92%, рабочие места - 70%, неизвестные активы - 8%». Руководству проще принять решение: следующий шаг - закрыть слепые зоны и назначить владельцев, а не «найти еще больше CVE».

Tenable, Qualys, Rapid7: критерии сравнения без маркетинга

Когда выбирают платформу для управления уязвимостями, легко застрять в витрине функций и сравнивать «у кого больше найдено». Полезнее оценить, насколько инструмент поможет быстро снижать риск в вашей среде.

Начните с покрытия активов. В одной организации основной риск в рабочих местах и офисной сети, в другой - в серверах, облаке и контейнерах. Проверьте, как платформа видит «неочевидные» активы: сетевые устройства, временные виртуальные машины, тестовые стенды, филиалы. Если у вас смешанный парк (например, рабочие места и серверы, в том числе локально произведенные в Казахстане, плюс часть сервисов в облаке), важно, чтобы модель активов не распадалась на отдельные островки.

Качество обнаружения часто важнее количества находок. Спросите, как устроены аутентифицированные проверки (с учетными данными), как платформа снижает ложные срабатывания и как быстро появляются обновления для новых уязвимостей. В пилоте смотрите не «сколько нашло», а «сколько подтвердилось» и сколько времени заняло исправление.

По приоритизации ключевой вопрос один: как инструмент отвечает на «что исправлять первым». Проверьте, учитывает ли он доказательства эксплуатации и кампании атак, можно ли добавлять бизнес-контекст (критичность сервиса, сегмент, экспозиция в интернет), есть ли понятное объяснение приоритета и поддерживаются ли исключения со сроком и владельцем.

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

И наконец - интеграции и API. Если платформа плохо дружит с ITSM/CMDB, EDR и SIEM, вы утонете в ручной работе.

Проверяйте на реальном сценарии: создание тикета, привязка к активу из CMDB, назначение ответственного, SLA, комментарии, закрытие только после повторного сканирования. Здесь обычно и видно различия между Tenable, Qualys и Rapid7 лучше, чем в рекламных таблицах.

Пошаговый выбор платформы: от требований до пилота

Выбор Tenable, Qualys или Rapid7 лучше начинать не с демо, а с описания вашего контура. Какие активы вы реально сканируете: серверы, рабочие станции, виртуалки, облако, сетевое оборудование, контейнеры. Какие команды будут жить в процессе: ИБ, админы, владелец сервиса, DevOps. Какие отчеты от вас ждут: регуляторные, для аудита, для руководства.

Дальше зафиксируйте must-have, без которых продукт не подойдет даже при отличных рейтингах. Обычно это интеграция с ITSM (создание, обновление и закрытие задач без ручной работы), связь с CMDB или хотя бы внятная инвентаризация активов, SSO и понятная модель ролей, гибкие исключения и согласования, экспорт данных и отчеты под ваши KPI.

Пилот делайте на реальном сегменте, а не на «лаборатории». Оптимальный срок - 2-4 недели: меньше обычно не успевает показать качество данных и нагрузку на команды. Важно заранее описать сценарии и критерии успеха, чтобы сравнение было честным.

На пилоте проверьте не «сколько нашлось», а насколько данным можно доверять. Частые проблемы - дубликаты активов из-за разных источников, пропуски из-за закрытых портов или неверных учетных данных, а также ложные срабатывания, которые съедают время на разбор. Попросите команду исправления оценить, насколько понятны рекомендации и насколько легко доказать, что проблема действительно на этом узле.

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

Если у вас нет выделенных ресурсов, стоит сразу рассматривать помощь интегратора, который сможет поставить пилот, настроить интеграции и подготовить отчеты под руководство. В Казахстане такие задачи часто закрывают через системную интеграцию - например, в проектах GSE.kz.

Типичные ошибки при внедрении и как их избежать

Частая причина провала не в выборе Tenable, Qualys или Rapid7, а в том, что процесс не закреплен в работе ИТ. Инструмент превращается в генератор тревог, а управление уязвимостями - в «спорт по закрытию тикетов» без снижения риска.

Ошибка 1: сканируют все подряд, но никто не отвечает

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

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

Ошибка 2: сканируют без аутентификации и получают шум

Без учетных данных сканер часто видит только «поверхность» и ошибается: пропускает патчи, неверно определяет версии, не замечает опасные настройки. Это приводит к спорам между ИБ и ИТ и потере доверия к отчетам.

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

Еще одна ловушка - смешать в одну очередь уязвимости, конфигурационные проверки и «гигиену» (слабые пароли, лишние сервисы) без приоритета. В итоге все срочно и ничего не сделано. Разведите потоки: что исправляется патчем, что - настройкой, что - компенсирующей мерой.

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

И еще одна частая ошибка - отчеты пишут «для ИБ», с таблицами CVE, но они не отвечают на вопросы ИТ и руководства. ИТ нужно: что сделать и к какому сроку. Руководству нужно: какие риски закрываем и что остается.

Короткий способ снизить риск ошибок:

• Начните с 1-2 критичных сервисов и доведите цикл «нашли -> назначили -> исправили -> проверили» до конца.
• Включите аутентификацию там, где это реально, и зафиксируйте исключения.
• Разделите очереди работ: патчи отдельно, настройки отдельно, долгосрочные проекты отдельно.
• Добавьте внешний контур в регулярный график проверок.
• Настройте два вида отчетов: операционный для ИТ и риск-ориентированный для руководства.

Пример: в госорганизации на рабочих местах и серверах (в том числе локально произведенных) можно начать с доменных контроллеров и почтового сервиса, привязать активы к владельцам в ITSM, а руководству показывать не «сколько CVE», а снижение доли критичных уязвимостей на ключевых системах и долю тех, что подтверждены как реально эксплуатируемые.

Короткий чеклист и следующие шаги

Если у вас уже есть сканер и отчеты, это еще не означает, что управление уязвимостями работает. Ниже короткая проверка на «живость» процесса: что должно быть настроено, чтобы риск снижался, а не просто росло число найденных CVE.

Мини-чеклист зрелости

Пять пунктов, которые быстро показывают слабые места:

• Покрытие: все критичные сервисы и ключевые сегменты сети попадают в сканирование, и вы понимаете, что не сканируется и почему.
• Приоритет: есть простое правило срочности, например «эксплуатируется + интернет» = исправить в первую очередь.
• Процесс: тикеты создаются автоматически, у каждого есть владелец и понятный срок.
• Контроль: раз в неделю проводится короткий обзор просрочек, исключений и спорных случаев.
• Отчетность: руководству показывают динамику по риску (сколько критичных закрыто, сколько просрочено, где узкие места), а не список CVE.

Следующие шаги на 2-4 недели

Дальше важно перейти к короткому пилоту. Он должен ответить на вопрос: «получится ли у нас делать исправления регулярно?»

• Назначьте владельца процесса и резервного ответственного.
• Выберите 1-2 самых важных бизнес-сервиса и прогоните на них полный цикл: сканирование, приоритизация, тикеты, закрытие, повторная проверка.
• Согласуйте SLA по срокам для разных уровней риска и правила исключений (кто утверждает, на какой срок, чем компенсируется).
• Настройте интеграцию с ITSM так, чтобы тикеты создавались по понятным условиям (например, только подтвержденные критичные на публичных узлах), иначе команда утонет в очереди.

Если внутри не хватает времени или опыта, имеет смысл привлечь системного интегратора. Например, GSE.kz может помочь подобрать платформу под ваши требования и настроить интеграции с ITSM и инфраструктурой так, чтобы пилот проверял реальный рабочий процесс, а не «красоту отчетов». Также удобно, когда инфраструктура и поддержка закрываются в одном контуре - от рабочих станций и серверов до сопровождения и 24/7 поддержки через сервисную сеть.