Приём обнаружений уязвимостей, событий сканирования и логов аудита Tenable

Материал из Документация Ключ-АСТРОМ

Приём обнаружений уязвимостей, событий сканирования и логов аудита Tenable

Расширение

Приоритизируйте уязвимости Tenable с учётом контекста продуктивной среды.

Начало работы

Обзор

Tenable предлагает надёжные решения для выявления, приоритизации и устранения уязвимостей, что критически важно для снижения киберрисков и защиты цифровой инфраструктуры. Интеграция обнаружений Tenable в Ключ-АСТРОМ позволяет повысить общий уровень безопасности за счёт всесторонней видимости и оптимизированного управления уязвимостями.

Сценарии использования

С загруженными данными можно реализовать различные сценарии, например:

  • Визуализировать и анализировать обнаружения безопасности
  • Выявлять пробелы в покрытии обнаружений безопасности
  • Автоматизировать и оркестрировать обнаружения безопасности

Требования

Поддерживаемые продукты Tenable

  • Tenable Vulnerability Management (для уязвимостей и событий сканирования)
  • Tenable Web App Scanning (для уязвимостей и событий сканирования)
  • Tenable One (для логов аудита)
  • (больше — скоро)

Требования Tenable

Создайте ключ доступа API и секретный ключ со следующими ролями:

  • Basic — для управления уязвимостями и сканирования веб-приложений.
    • Чтобы получить полные сведения о сканированиях, убедитесь, что настроенный ключ API также имеет доступ на чтение сканирований и истории сканирований. Подробности о необходимых API см. в разделе «API, используемые для получения данных».
  • Administrator или Custom — для логов аудита.

Подробности см. в разделе «Роли и привилегии, предоставляемые Tenable».

Требования Ключ-АСТРОМ

  • Версия АктивныйШлюз 1.299+

Разрешения:

  • Для запуска Расширений: перейдите в Расширения, откройте Расширения и просмотрите техническую информацию.
  • Для запроса принятых данных: storage:security.events:read.

Токены:

  • Создайте токен доступа с областью действия openpipeline.events_security и сохраните его. Подробности см. в разделе «Токены и аутентификация API Ключ-АСТРОМ».

Активация и настройка

  1. В Ключ-АСТРОМ найдите Tenable и выберите Установить.
  2. Следуйте инструкциям на экране для настройки расширения.

Проверьте конфигурацию, выполнив следующие запросы в Блокнотах:

Для уязвимостей и сканирований ресурсов:

fetch security.events
| filter dt.system.bucket=="default_securityevents"
| filter event.provider == "Tenable"

Для логов аудита:

fetch logs
| filter log.source == "Tenable"

После установки и запуска расширения вы можете получить к нему доступ и управлять им в Ключ-АСТРОМ через Расширения. Подробности см. в разделе «О расширениях».

Теперь вы можете визуализировать обнаружения, анализировать логи аудита и автоматизировать уведомления.

Подробности

Как это работает

Интеграция Ключ-АСТРОМ с Tenable — это расширение, работающее на АктивныйШлюз Ключ-АСТРОМ. После включения и настройки расширения Tenable для Ключ-АСТРОМ:

  1. Оно периодически обращается к продуктам Tenable и получает новые обнаружения, сканирования и логи аудита через API Tenable.
  2. Полученные данные загружаются в Ключ-АСТРОМ и сопоставляются с Семантическим словарём Ключ-АСТРОМ.
  3. Данные сохраняются в бакете default_securityevents (подробности см. в разделе «Встроенные бакеты»).

Визуализация

  1. Откройте Расширения и перейдите в Tenable.
  2. В разделе Содержимое расширения выберите нужный готовый дашборд.
  3. В фильтре Продукт выберите Tenable, чтобы просмотреть данные, сообщённые Tenable, например критические уязвимости и затронутые объекты.

Анализ

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

Примеры построения запросов см. ниже.

Запрос логов во времени по действию

fetch logs
| filter log.source == "Tenable"
| makeTimeseries logs=countDistinctExact(id), by:{audit.action}, time:{toTimestamp(received)}, interval:{3h}

Запрос распределения уязвимостей по уровню риска

fetch security.events
| filter dt.system.bucket=="default_securityevents"
| filter event.type == "VULNERABILITY_FINDING"
| filter event.provider == "Tenable"
| dedup {object.id, vulnerability.id}, sort:{timestamp}
| summarize Vulnerabilities=countDistinctExact(vulnerability.id), by:{dt.security.risk.level}
| fieldsAdd order=if(dt.security.risk.level=="CRITICAL", 1, else:



                 if(dt.security.risk.level=="HIGH", 2, else:
                 if(dt.security.risk.level=="MEDIUM", 3, else:
                 if(dt.security.risk.level=="LOW", 4, else:5))))



| sort order asc

Запрос топ-10 сканирований с наибольшим покрытием хостов

fetch security.events
| filter dt.system.bucket=="default_securityevents"
| filter event.type == "VULNERABILITY_SCAN"
| filter event.provider == "Tenable"
| dedup {object.id, scan.id}
| summarize Hosts=countDistinctExact(object.id), by:{scan.name}
| sort Hosts desc
| limit 10

Автоматизация уведомлений

  1. Скачайте наш пример рабочего процесса для Jira или пример рабочего процесса для Slack.
  2. Откройте Рабочие процессы, выберите Загрузить, затем выберите скачанный файл.
  3. Настройте рабочий процесс под свои задачи, чтобы создавать уведомления о критических обнаружениях Tenable.

Лицензирование и затраты

Информацию о выставлении счетов см. в разделе о событиях.

Наборы функций

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

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

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

Метрика наследует набор функций подгруппы, которая, в свою очередь, наследует набор функций группы. Кроме того, набор функций, определённый на уровне метрики, переопределяет набор функций, определённый на уровне подгруппы, который, в свою очередь, переопределяет набор функций, определённый на уровне группы.

FAQ

Почему в моей конфигурации отображается ошибка?

Сообщение об ошибке: Failed to assign monitoring configuration to ActiveGate. Reason: Extension com.astromkey.extension.tenable(<version-number>) not available in cache yet (queued for download).

Если в вашей конфигурации отображается указанное выше сообщение об ошибке, это означает, что АктивныйШлюз всё ещё загружает расширение для кластера. Статус должен измениться через несколько минут.

Почему я вижу дублирующиеся события?

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

Вы можете выполнить запрос DQL и удалить дубликаты событий с помощью полей object.id, scan.id и finding.id.

  • Для VULNERABILITY_FINDING уникальный идентификатор — {object.id, finding.id}.
  • Для VULNERABILITY_SCAN уникальный идентификатор — {object.id, scan.id}.

Пример:

fetch security.events
| filter dt.system.bucket=="default_securityevents"
| filter event.type == "VULNERABILITY_FINDING"
| filter event.provider == "Tenable"
| dedup {object.id, finding.id}, sort:{timestamp}

Почему у некоторых событий сканирования совпадают время начала и окончания?

При получении уязвимостей расширение Tenable пытается сопоставить данные с недавними запусками сканирований. Если сканирование, упомянутое в уязвимости Tenable, не найдено (например, из-за отсутствия разрешений), расширение создаёт событие сканирования на основе этого обнаружения. У таких событий сканирования время начала и окончания совпадает со временем обнаружения уязвимости.

Почему мои данные не загружаются?

Если вы установили и настроили расширение, но данные не загружаются, выполните следующие шаги.

  1. Откройте расширение и перейдите в Состояние, чтобы проверить статус конфигурации мониторинга.
  2. Если статус не OK, прокрутите вниз до раздела Логи и выберите Запустить запрос, чтобы увидеть информацию об ошибке.
  3. Если информации об ошибке недостаточно или статус показывает OK, но данные всё равно не поступают, извлеките архив поддержки из АктивныйШлюз для дальнейшей диагностики.

Как извлечь архив поддержки

  1. Найдите идентификатор АктивныйШлюз для экземпляра, на котором выполняется конфигурация, и извлеките архив поддержки. Подробности см. в разделе «Диагностика АктивныйШлюз: сбор и локальный просмотр».
  2. Распакуйте архив поддержки и найдите файл лога расширения по пути COLLECTOR/<id>/remotepluginmodule/log/extensions/datasources/com.astromkey.extension.tenable/python3.log.
  3. Если информации там всё ещё недостаточно для диагностики, включите флаг Логи отладки в конфигурации мониторинга и обратитесь в службу поддержки Ключ-АСТРОМ.

Распространённые причины пропуска приёма данных:

  • Нет соединения между АктивныйШлюз и облаком Tenable.
    • Рекомендация: попробуйте выполнить curl к URL облака Tenable с АктивныйШлюз, чтобы убедиться, что соединение работает.
  • Неверный ключ доступа и/или секретный ключ.
    • Рекомендация: перепроверьте учётные данные, настроенные в конфигурации мониторинга.
  • Отсутствуют разрешения у пользователя API.
    • Рекомендация: убедитесь, что пользователь API может вызывать API, используемые для получения данных.

Какие поля расширения добавляются к основным полям событий, принятых из Tenable?

Добавляется пространство имён tenable для извлечения ряда специфичных для Tenable атрибутов, что удобно для пользователя, поверх исходного JSON проблемы, который хранится в поле event.original_content.

Примеры:

  • tenable.vpr
  • tenable.last_found
  • tenable.first_found
  • tenable.last_fixed

Какие типы ресурсов Tenable поддерживаются Ключ-АСТРОМ для контекстуализации среды выполнения?

HOST — все обнаружения из Tenable Vulnerability Management, полученные при сканировании хостов, сопоставляются со значением HOST в поле object.type, и добавляется пространство имён host с соответствующими полями:

  • host.name представляет имя хоста, обнаруженное Tenable.
  • host.ip представляет IP-адрес хоста, просканированный Tenable.
  • host.fqdn представляет FQDN хоста, разрешённый Tenable.

Контекстуализацию среды выполнения можно выполнять по полю host.ip.

Как нормализуется оценка риска для обнаружений Tenable?

Ключ-АСТРОМ нормализует оценки серьёзности и риска для всех обнаружений, принятых через текущую интеграцию. Это помогает согласованно приоритизировать обнаружения независимо от их источника.

Подробности о том, как работает нормализация, см. в разделе «Нормализация серьёзности и оценок».

Уровни и оценки риска Ключ-АСТРОМ сопоставляются из исходного уровня серьёзности Tenable.

Tenable использует оценку VPR. Однако уровни серьёзности устанавливаются на основе оценок CVSS (v2 или v3, в зависимости от конфигурации). Поэтому Ключ-АСТРОМ сопоставляет уровень серьёзности с уровнем риска и затем присваивает соответствующую оценку риска на его основе.

  • dt.security.risk.level берётся из уровня серьёзности Tenable и сопоставляется из исходных значений в finding.severity.
  • dt.security.risk.score сопоставляется из сопоставленного уровня риска с набором статических оценок.
dt.security.risk.level (сопоставлено с finding.severity) dt.security.risk.score (сопоставлено с dt.security.risk.level)
critical -> CRITICAL 10.0
high -> HIGH 8.9
medium -> MEDIUM 6.9
low -> LOW 3.9
Источник — https://doc.ruscomtech.ru/index.php?title=Приём_обнаружений_уязвимостей,_событий_сканирования_и_логов_аудита_Tenable&oldid=6824