Рекомендации для журналов событий Cato и процесса передачи

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

Обзор

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

Рекомендуемые лучшие практики включают два основных рабочих процесса:

  • Сжатие событий для уменьшения потребностей в хранении

  • Устранение событий ограниченной ценности при передаче в SIEM

В дополнение к этим рабочим процессам мы также представляем несколько общих лучших практик ведения журналов для аккаунтов Cato.

Сжатие событий для оптимизации хранения

Чтобы оптимизировать объем хранения, необходимый для журналов событий Cato, вы можете сжимать данные событий в процессе экспорта и уменьшить требуемое хранилище до 95%, включая сжатие gzip при отправке API-запросов.

Для получения дополнительной информации о работе с API Cato смотрите Начало работы с API Cato.

Для примера Python-скрипта eventsFeed, который выполняет API-запросы с включенной компрессией, смотрите Примеры скриптов: Использование API Cato с Python.

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

Устранение ненужных событий

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

  1. Устранить события по Типу события - На странице События используйте панель Популярные Поля, чтобы просмотреть количество событий по каждому Типу события. В большинстве случаев подавляющее большинство сгенерированных событий - это события Безопасности. Если вам не нужно регистрировать события Безопасности, вы можете исключить их из запроса eventsFeed или интеграции журнала событий и избежать их передачи в ваш SIEM. Устранение других Типов событий вряд ли окажет значительное влияние на общее количество.

    Event_Logging_BP_-_Тип_События.png
  2. Устранить события по Подтипу - Если вам необходимо регистрировать события Безопасности, вы можете устранить конкретные Подтипы событий Безопасности, которые не нужны для ваших нужд. Для многих аккаунтов события фаервола Интернет и межсетевого экрана WAN представляют собой подавляющее большинство событий Безопасности. Если вас интересуют только другие Типы событий Безопасности, вы можете значительно сократить количество передаваемых событий, исключив события фаервола из вашего запроса eventsFeed или интеграции журнала событий и избегая их передачи в ваш SIEM

    Event_Logging_BP_-_Подтип_2.png
  3. Устранить события по Приложению - Предполагается, что вам необходимо регистрировать события фаервола, значительная доля которых может быть сгенерирована трафиком приложений, которые вам не нужно регистрировать. Например, события DNS часто представляют собой большое количество событий фаервола и могут иметь ограниченную полезность для вас. В разделе Доступные Поля, проанализируйте количество событий для каждого Приложения и определите трафик, который вам не нужно регистрировать. Затем создайте правила фаервола с действием Разрешить и без События, чтобы устранить генерацию событий для этих приложений. Мы рекомендуем создать Пользовательское приложение с определенными IP-адресами назначения для DNS-серверов, за которыми не требуется отслеживание событий. Затем вы можете создать одно правило фаервола, чтобы разрешить это Пользовательское приложение.

    Event_Logging_BP_-_Приложение.png

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

    • Общие протоколы мониторинга сети, такие как ICMP и SNMP

    • Приложения с большим количеством событий, которые известны как безопасный трафик, такие как Windows Update, Microsoft Teams и Zoom

Общие лучшие практики ведения журнала для учетных записей Cato

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

    Event_Logging_BP_-_Enable_Integration.png
  • Настроить политику реагирования XDR для создания событий для историй XDR, которые будут включены в ваш поток событий. По умолчанию события истории XDR не генерируются, события генерируются только согласно настроенным правилам. Для получения дополнительной информации о создании правил политики реагирования XDR и полях события XDR см. Создание политики реагирования для историй XDR.

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

    Event_Logging_BP_-_Total_Events.png

Была ли эта статья полезной?

Пользователи, считающие этот материал полезным: 0 из 0

0 комментариев