Сканирование уязвимостей OpenVAS: расписания и отчеты

Почему сканы не приводят к исправлениям

Регулярные сканы OpenVAS сами по себе редко повышают безопасность. Они дают факты, но изменения появляются только тогда, когда есть понятный путь от находки до закрытия: кому это чинить, в какие сроки и как подтвердить результат.

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

Есть несколько признаков, что сканирование не работает как инструмент исправлений:

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

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

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

OpenVAS/Greenbone особенно полезен для «гигиены» и контроля изменений: он быстро показывает, что появилось нового после обновлений, миграций и ввода новых серверов. В организациях с большим парком рабочих мест и серверов (госсектор, банки, медицина) важна не разовая проверка, а стабильный цикл: нашел - назначил - исправил - подтвердил повторным сканом.

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

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

Кто за что отвечает

Минимальный набор ролей лучше определить сразу, даже если в компании один человек «и за ИБ, и за админов». Обычно нужны: владелец процесса (ИБ или руководитель ИТ), администраторы, владельцы сервисов (почта, 1С, веб-портал) и руководитель, который снимает блокеры (окна работ, бюджеты, приоритеты).

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

Границы и правила сканирования

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

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

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

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

Инвентаризация и группировка активов в Greenbone

Сканирование начинается не с кнопки Start, а с понятного списка целей. Если инвентарь неполный или в одну группу смешаны разные типы систем, проверки будут либо шумными, либо опасными для критичных сервисов.

Хороший инвентарь для Greenbone - это не только IP и хостнеймы, но и контекст: сегмент сети, площадка, назначение, владелец. Тогда результаты можно раздавать адресно, а не «всем сразу».

Минимум, который стоит собрать по каждой цели: IP или диапазон и DNS-имя (если есть), где находится (офис, ЦОД, филиал), зона доступа (внутренняя сеть, DMZ, внешние адреса), владелец, критичность и ограничения (например, «нельзя агрессивные проверки» или «только в ночное окно»).

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

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

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

Такое разбиение делает расписания предсказуемыми, исключения управляемыми, а отчеты - адресными.

Расписания: как поставить сканы на рельсы

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

Обычно достаточно 2-3 типов задач.

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

По частоте удобно начать с простой матрицы и дальше уточнять по статистике:

• критичные публичные сервисы и VPN-шлюзы - раз в неделю;
• серверы с персональными данными и ключевыми системами - раз в 2 недели;
• остальная серверная зона - раз в месяц;
• рабочие станции и периферия - раз в квартал;
• контрольный полный скан - после крупных изменений.

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

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

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

Аутентифицированные сканы без боли: доступы и безопасность

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

Главное правило - не использовать личные админские учетные записи. Нужны отдельные сервисные аккаунты и минимальные права под сканирование. Удобно разделять доступы по типам систем:

• Windows: отдельный доменный или локальный аккаунт, только нужные права (WMI/SMB, чтение реестра, доступ к списку обновлений).
• Linux: отдельный пользователь, доступ по SSH-ключу, sudo только на команды для инвентаризации и проверки пакетов.
• Сетевое оборудование: отдельный read-only аккаунт (SNMPv3 или SSH), без прав на изменения.
• Виртуализация и приложения: отдельные учетные записи к API/консолям, если это действительно нужно для проверки.

Хранение и ротацию паролей лучше вынести в единый процесс: парольный сейф, фиксированный срок смены, понятный владелец, журналирование выдачи. Для интерактивного входа поставьте запрет: сервисные аккаунты не должны ходить в RDP/консоль «как человек». На Linux это часто решается запретом shell или ограничением команд, на Windows - правами Deny log on locally/through RDP, но с сохранением нужных протоколов для сканера.

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

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

Исключения и ложные срабатывания: правила, а не хаос

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

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

Любое исключение должно быть временным. Ставьте срок действия (например, 30-90 дней) и дату пересмотра. Если срок «бесконечный», исключение превращается в дыру в процессе. Владельцем исключения обычно должен быть владелец сервиса или системы, а не команда ИБ, иначе решения по риску становятся ничьими.

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

Ложные срабатывания ведите отдельно от исключений. Сначала подтверждайте: перепроверьте версию пакета, баннер, конфигурацию, повторите скан аутентифицированно. Удобное правило: исключение - это про принятый риск, ложноположительное - про ошибку детекта.

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

Пример: на сервере бухгалтерии найден «уязвимый SSH-алгоритм», но обновление OpenSSH возможно только при апгрейде ОС. Команда фиксирует исключение NVT на 60 дней, включает строгий доступ по VPN и отдельную сеть, и ставит задачу на миграцию с контрольной датой. Так находка не исчезает, а превращается в план действий.

Приоритизация: что исправлять первым и почему

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

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

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

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

Закрепите это в SLA, иначе приоритеты будут меняться «по настроению»:

• критично: 72 часа (или быстрее при активной эксплуатации);
• высоко: 7-14 дней;
• средне: 30-60 дней;
• низко: по окну обновлений, раз в квартал;
• исключение: только с владельцем системы, сроком пересмотра и компенсирующей мерой.

Так список находок превращается в понятную очередь работ, и прогресс становится измеримым.

Отчетность, которую читают и по ней действуют

Хороший отчет начинается не с деталей сканера, а с ответа на вопрос: что именно нужно сделать и кому. Если после скана человек не понимает, куда смотреть и что править, даже точные результаты превращаются в архив PDF.

Два уровня отчета: для руководства и для исполнителей

Для руководства работает формат на одну страницу: динамика за период, самые рискованные направления и где процесс застрял. Важно, чтобы цифры были сопоставимы от месяца к месяцу, без смены терминов и критериев.

Для админов нужен рабочий документ, по которому можно сразу заводить задачи. Там ценна конкретика: хост, порт, что обнаружено, чем подтверждается, и короткий план исправления.

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

Сделайте находки пригодными для тикетов

Большая часть боли в отчетах связана с разным языком: один пишет «Win Server», другой «Windows 2019», третий «AD». Нормализуйте названия систем, сервисов и сред, чтобы отчеты сводились без ручной правки.

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

Для технического отчета хватает 4-5 полей, но они должны быть стабильными: актив (понятное имя, среда prod/test, владелец), доказательство (версия, баннер, вывод проверки), риск и приоритет (почему это важно именно вам, а не «по CVSS»), шаги устранения, связь с работой (номер тикета, срок, исключение если согласовано).

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

Пример сценария: как внедрить процесс за 3 месяца

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

План на 3 месяца

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

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

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

Удобный ритм выглядит так:

• Месяц 1: инвентаризация + пилот на одном сегменте.
• Месяц 2: расписания + учетные данные + исключения.
• Месяц 3: SLA + еженедельный разбор критичных + снижение повторов.

Что пошло не так и как поправили

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

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

Частые ошибки и ловушки при работе с OpenVAS/Greenbone

Самые болезненные проблемы в OpenVAS/Greenbone почти всегда не про «настройки сканера», а про организацию. Из-за этого проверки быстро превращаются в шум, а потом их просто выключают.

Типичные ловушки:

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

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

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

Без владельцев активов отчет не имеет адресата. Практичный минимум - у каждой группы целей должен быть ответственный: ИТ (за ОС и конфигурации) и владелец сервиса (за окна работ и приоритет).

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

Рабочая отчетность часто начинается со страницы на 10 строк. Один понятный сценарий: после еженедельного скана по серверному сегменту команда получает не полный отчет, а список из 5-10 задач с владельцами, дедлайнами и обязательной проверкой повторным сканом.

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

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

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

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

Следующие шаги на ближайший месяц

• Привяжите находки к реальным задачам: один формат тикета, один владелец, один срок, короткий комментарий «как проверить после фикса».
• Разделите сканы по критичности: чаще для внешнего периметра и базовых сервисов, реже для менее важных сегментов.
• Согласуйте базовые исключения и окна сканирования с владельцами систем, чтобы не ломать бизнес-процессы.
• Назначьте регулярный 30-минутный разбор: топ-10 по риску, что делаем сейчас, что переносим, что закрыли.

Если параллельно нужно выстроить инфраструктурную часть (сегментацию, серверную базу, надежные рабочие станции, поддержку), это проще делать вместе с командой, которая отвечает за результат end-to-end. В Казахстане такие задачи часто закрывают через GSE.kz (gse.kz) как производителя и системного интегратора с круглосуточной технической поддержкой и опытом в госсекторе, медицине, образовании и финансах.