«Периодичность сканирования, это не догма из учебника, а инструмент управления рисками. Часто, это не значит каждую неделю. Речь о том, чтобы интервал между проверками был меньше времени, которое нужно злоумышленнику для подготовки и проведения атаки. Задача — создать ситуацию, когда в системе не успевает накапливаться критическое количество необнаруженных уязвимостей.»
Отчёт об уязвимости, это не приговор, а карта рисков
Сканирование на уязвимости, это не тест на профпригодность ИБ-специалиста. Это инструмент для сбора первичных данных о состоянии защищённости. Цель — получить структурированную информацию о потенциальных слабых местах: устаревшие версии ПО, открытые порты, стандартные конфигурации. Отчёт сканера, это не список ошибок, которые нужно немедленно исправить, а основа для анализа приоритетов. Многие уязвимости могут быть ложноположительными или иметь низкую степень критичности в конкретной инфраструктуре.
Частота сканирования зависит от жизненного цикла инфраструктуры
Единого расписания для всех не существует. Ключевой фактор — скорость изменений в вашей среде. Если вы разворачиваете новые сервисы еженедельно, то ежемесячное сканирование бессмысленно — оно всегда будет отставать от реальности.
Можно выделить несколько зон с разными подходами:
- Зона активной разработки и CI/CD. Здесь изменения происходят ежедневно, даже ежечасно. Сканирование должно быть встроено в процесс сборки и деплоя. Каждый новый образ контейнера или обновление конфигурации должны проходить автоматическую проверку перед попаданием в продуктив. Частота здесь определяется не календарём, а событиями.
- Зона критической инфраструктуры. Серверы БД, системы контроля, сетевые узлы. Их обновляют реже, но последствия взлома катастрофичны. Здесь уместно регулярное плановое сканирование (например, раз в две недели) плюс внеочередное после любого значимого изменения конфигурации.
- Зона рабочих станций пользователей. Парк часто однороден, управляется через централизованные инструменты. Здесь эффективнее сканирование выборочное, но частое (например, раз в неделю для случайной выборки машин), чтобы выявлять тенденции, и полное — перед массовым обновлением ПО.
Законодательные требования задают лишь нижнюю планку
152-ФЗ и приказы ФСТЭК (например, приказ №21) говорят о необходимости «своевременного» выявления уязвимостей. Это расплывчатая формулировка, которая интерпретируется проверяющими. На практике «своевременно» часто означает наличие задокументированного и обоснованного регламента, а не его абсолютную эффективность. Если в вашем положении о сканировании прописано, что оно проводится ежеквартально, и у вас есть документы, подтверждающие исполнение, формально требования могут считаться выполненными. Однако квартал, это огромный срок в цифровом мире. За это время для критической уязвимости могут появиться и эксплойт, и массовые атаки. Ориентироваться только на формальные требования — значит создавать иллюзию защищённости.
Периодичность и глубина: от быстрых проверок к глубокому анализу
Не каждое сканирование должно быть полным и глубоким, занимая часы и нагружая сеть. Эффективная стратегия — комбинация разных типов проверок:
- Ежедневное/еженедельное поверхностное сканирование. Быстрая проверка только на наличие новых критических уязвимостей (CVE с высоким CVSS), сканирование только основных диапазонов адресов. Цель — раннее предупреждение о самых опасных угрозах.
- Ежемесячное полное сканирование. Стандартная проверка по всем политикам, охватывающая всю инфраструктуру. Формируется основной отчёт для анализа и планирования работ.
- Ежеквартальное углублённое сканирование (Penetration Test). Проверка с повышенными привилегиями (учётные данные тестировщика), анализ бизнес-логики, социальной инженерии. Это не автоматическое сканирование, а работа специалистов, но её также следует включать в общий цикл.
Автоматизация как способ увеличить частоту без роста затрат
Ручное инициирование сканирований обрекает на низкую частоту. Автоматизация — ключ к переходу от периодичности «по решению специалиста» к событийно-управляемой модели. Настройте триггеры для запуска сканирований:
- По расписанию (cron).
- При обнаружении нового актива в сети (по данным NAC или системы инвентаризации).
- После публикации критического обновления безопасности для ключевого компонента вашего стека.
- При изменении конфигурации межсетевого экрана или балансировщика.
Так вы смещаете фокус с вопроса «как часто?» на вопрос «при каких условиях?».
Метрики, которые покажут, что вы сканируете слишком редко
О недостаточной частоте сигнализируют конкретные индикаторы в ваших отчётах:
- Высокий «возраст» обнаруженных уязвимостей. Если в отчёте регулярно фигурируют уязвимости, обнаруженные 90 и более дней назад, цикл сканирования явно длиннее, чем цикл жизни уязвимостей.
- Обнаружение уязвимостей, для которых уже есть активные эксплойты в открытых источниках. Это прямое указание на то, что ваше сканирование отстаёт от угроз.
- Большое количество уязвимостей, обнаруженных на недавно развёрнутых системах. Значит, сканирование не интегрировано в процесс поставки, и проблемное ПО попадает в продуктив.
Интеграция результатов в процесс исправления
Само по себе частое сканирование бессмысленно, если его результаты годами лежат в виде отчётов. Периодичность сканирования должна быть синхронизирована с циклами обновлений и процессами Service Desk. Установите правило: отчёт за предыдущий период должен быть проанализирован, а задачи на устранение критических и высоких уязвимостей — поставлены до начала следующего планового сканирования. Таким образом, частота сканирования диктует максимальный срок реакции на инциденты безопасности.
Итоговая частота, это компромисс между риском, ресурсами и требованиями. Начните с обязательного минимума по регламенту, затем уменьшайте интервал в самых критичных сегментах, опираясь на метрики и автоматизацию. Главный критерий — уязвимости должны обнаруживаться вами, а не инцидентами.