Предварительная фильтрация и сокращение объема логов перед передачей в SIEM: как снизить расходы на сбор данных, не теряя возможности обнаружения угроз

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

Фильтрация и сокращение объема логов перед отправкой в SIEM (Pre-SIEM log filtering) решают эту проблему путем фильтрации, дедупликации, усечения или маршрутизации событий до того, как они пересекут границу приема данных SIEM. Обработка данных на агенте сбора или промежуточном узле (relay) позволяет снизить сетевой трафик, нагрузки на инфраструктуру и объем потребления SIEM.

NXLog Agent позволяет организациям применять эти методы непосредственно у источника, помогая командам безопасности контролировать объем логов при сохранении событий, необходимых для обнаружения угроз, расследований и соблюдения требований комплаенса.

В этом руководстве объясняется, что следует сохранять, что сокращать и как внедрить практические стратегии оптимизации логов с помощью NXLog Agent.

Что такое фильтрация и сокращение объема логов перед SIEM?

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

Место проведения обработки имеет значение. Фильтрация на конечном устройстве с помощью NXLog Agent одновременно снижает потребление пропускной способности сети, нагрузку на ретрансляторы и объем приема в SIEM. Фильтрация на центральном ретрансляторе упрощает управление политиками, но по-прежнему требует передачи исходных данных от источника к ретранслятору.

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

Что касается уровня Data Lake в Microsoft Sentinel, ознакомьтесь с документацией Microsoft по биллингу, чтобы понимать, когда взимается плата за обработку данных. Перемещение данных в более дешевое хранилище после приема — это не то же самое, что сокращение телеметрии до ее попадания на платформу.

Зачем фильтровать логи до их попадания в SIEM?

1. Контроль расходов на сбор данных

Многие модели ценообразования SIEM зависят от объема данных. Microsoft Sentinel предлагает варианты оплаты по факту (pay-as-you-go) и зарезервированные уровни (commitment tiers) для аналитических данных, а Splunk предлагает несколько моделей, включая варианты на основе объема приема и на основе нагрузки (workload-based).

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

Для справки обратитесь к официальной документации по биллингу Microsoft Sentinel и ценообразованию на сбор данных Splunk.

2. Повышение эффективности обнаружения

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

3. Поддержка требований комплаенса и аудита

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

Совместное руководство Best Practices for Event Logging and Threat Detection подчеркивает важность утвержденных корпоративных политик и централизованного сбора логов. Стандарт NIST SP 800-92 (Guide to Computer Security Log Management) содержит дополнительную информацию о создании, передаче, хранении, доступе и утилизации логов.

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

Что следует сохранять, сокращать или перенаправлять?

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

Используйте руководства по мониторингу событий Windows

Документ Microsoft "Приложение L: События для мониторинга" предоставляет полезный базовый уровень для определения потенциально важных событий безопасности Windows. Используйте его вместе с конкретными ID событий, используемыми вашими правилами аналитики SIEM и запросами для поиска угроз (threat hunting).

Некоторые события создают огромный объем, но остаются жизненно важными для определенных типов обнаружения. Например, событие Windows Security 4662 может быть важным для мониторинга доступа к службам каталогов и выявления активности DCSync. Вместо того чтобы бездумно отбрасывать это событие, пересмотрите политику аудита и настройки SACL на контроллерах домена, чтобы ограничить ненужный объем при сохранении требуемой видимости.

Сопоставляйте события с требованиями обнаружения

Сопоставьте каждый важный источник логов с правилами обнаружения, расследованиями и политиками хранения, которые от него зависят. Каталог источников данных MITRE ATT&CK помогает определить телеметрию, релевантную конкретным техникам злоумышленников.

Потенциальными кандидатами на сокращение в некоторых средах являются:

• Высокообъемные события платформы фильтрации Windows (WFP), такие как 5156 и 5158.
• События закрытия дескрипторов (handle-close), такие как событие 4658, если они не требуются контентом обнаружения.
• Сетевые входы в систему с машинных учетных записей (после анализа требований к обнаружению бокового перемещения / lateral movement).
• Сообщения Syslog с уровнем важности Informational или Debug.
• События разрешающих правил межсетевых экранов, не требуемые для расследований или контроля политик.
• Проверки работоспособности балансировщиков нагрузки (health checks) и другие повторяющиеся операционные события.

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

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

Пять методов сокращения логов с помощью NXLog Agent

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

1. Фильтрация событий по уровню важности Syslog или по полю

Порог важности (severity) — один из самых простых способов сократить объем syslog. В следующем примере NXLog Agent разбирает входящие сообщения syslog и отбрасывает события со значением важности больше 4. Важность в Syslog варьируется от 0 (emergency) до 7 (debug), поэтому правило сохраняет события уровня warning и более критичные сообщения.

<Extension syslog>
    Module        xm_syslog
</Extension>

<Input udp_listen>
    Module        im_udp
    ListenAddr    0.0.0.0:514
    <Exec>
        parse_syslog();
        if ($SyslogSeverityValue > 4) {
            drop();
        }
    </Exec>
</Input>

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

Дополнительную информацию см. в документации NXLog по фильтрации событий.

2. Фильтрация событий Windows на источнике

Фильтрация журнала событий Windows может выполняться в два этапа. Сначала используйте запрос XPath, чтобы ограничить список событий, собираемых NXLog Agent. Затем примените условия на основе полей в блоке Exec для дополнительной логики фильтрации.

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

<Input windows_security>
    Module    im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id="0">
                <Select Path="Security">*[System[(Level<=4)]]</Select>
                <Suppress Path="Security">
                    *[System[(EventID=4658 or EventID=5156 or EventID=5158)]]
                </Suppress>
            </Query>
        </QueryList>
    </QueryXML>
    <Exec>
        if $EventID == 4624 and $LogonType == 3 and $TargetUserName =~ /\$$/ {
            drop();
        }
        if $EventID == 4688 and $NewProcessName =~ /^C:\\Windows\\System32\\conhost\.exe$/i {
            drop();
        }
    </Exec>
</Input>

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

Модуль ввода Windows Event Log в NXLog Agent предоставляет структурированные поля, такие как EventID, LogonType и TargetUserName. Сравнение этих полей гораздо надежнее, чем поиск по всему сырому сообщению.

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

См. дополнительную информацию в руководстве по фильтрации журналов событий Windows в NXLog.

3. Дедупликация повторяющихся событий

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

В следующем примере используется процессор De-Duplicator в NXLog Agent для сравнения последовательных событий по выбранным полям.

<Extension syslog>
    Module         xm_syslog
</Extension>

<Input udp_listen>
    Module         im_udp
    ListenAddr     0.0.0.0:514
    Exec           parse_syslog();
</Input>

<Processor norepeat>
    Module         pm_norepeat
    CheckFields    Hostname, Message, SourceName
</Processor>

<Output agent_relay>
    Module         om_batchcompress
    Host           relay.example.com:2514
</Output>

<Route r>
    Path           udp_listen => norepeat => agent_relay
</Route>

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

Согласно исходной документации, модуль De-Duplicator постепенно выводится из эксплуатации. Для новых развертываний изучите текущее справочное руководство NXLog Agent и планируйте реализацию с использованием поддерживаемых языковых переменных или другого рекомендуемого функционала.

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

Обратитесь к документации NXLog De-Duplicator и текущему справочнику по языковым переменным NXLog.

4. Усечение ненужных полей и повторяющегося текста

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

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

<Extension allowlist>
    Module    xm_rewrite
    Keep      AccountName, Channel, EventID, EventReceivedTime, EventTime, \
              Hostname, Severity, SeverityValue, SourceName
</Extension>

<Input eventlog>
    Module    im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id='0'>
                <Select Path='Security'>*[System/Level<=4]</Select>
            </Query>
        </QueryList>
    </QueryXML>
    Exec      allowlist->process();
</Input>

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

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

<Exec>
    if ($Channel == 'Security') and ($EventID == 4769) {
        $Message =~ s/\s*This event is generated every time access is.*$//s;
    }
    $raw_event = $EventTime + ' ' + $Message;
</Exec>

Пересборка $raw_event важна при использовании потоковых модулей вывода, которые отправляют сырое событие, а не разобранные поля. Удаление полей только из внутреннего представления события не обязательно уменьшит размер передаваемой записи.

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

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

Узнайте больше в руководствах NXLog по усечению событий и усечению событий Windows.

5. Маршрутизация ценных событий в SIEM и архивация остальных

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

В следующем примере события Windows Security маршрутизируются в защищенное через TLS назначение SIEM и в Amazon S3. Список ID событий приведен для иллюстрации и должен быть адаптирован под требования обнаружения вашей среды.

define CERTDIR %CONFDIR%/cert

<Extension json>
    Module    xm_json
</Extension>

<Input windows_security>
    Module    im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id="0">
                <Select Path="Security">*</Select>
            </Query>
        </QueryList>
    </QueryXML>
</Input>

<Output siem>
    Module    om_ssl
    Host      siem.example.com:6514
    CAFile    %CERTDIR%/ca.pem
    <Exec>
        if $EventID NOT IN (4624, 4625, 4648, 4672, 4688, 4697, 4698,
                            4720, 4728, 4732, 4756, 4768, 4769, 4776) {
            drop();
        }
        to_json();
    </Exec>
</Output>

<Output archive>
    Module    om_amazons3
    Region    eu-west-1
    Bucket    security-archive
    Server    SRV01
    Exec      to_json();
</Output>

<Route split>
    Path      windows_security => siem, archive
</Route>

Условие drop() в модуле вывода SIEM влияет только на это конкретное направление. Вывод в архив продолжает получать полный поток событий, что позволяет аналитикам извлекать события, которые не были проиндексированы в SIEM.

Используйте утвержденный список событий, составленный на основе руководства Microsoft по мониторингу событий Windows и правил, которые реально выполняются в вашей SIEM.

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

Подробнее см. в руководстве NXLog по маршрутизации событий в различные назначения и документации к модулю вывода в Amazon S3.

Управление правилами фильтрации на тысячах агентов с помощью NXLog Platform

Поддержка отдельных файлов nxlog.conf становится сложной по мере роста инфраструктуры. NXLog Platform обеспечивает централизованное управление агентами, позволяя администраторам создавать конфигурации, назначать их выбранным агентам и стандартизировать политики сбора и маршрутизации в распределенной инфраструктуре.

Ключевые возможности включают:

• Централизованное управление конфигурациями: создание и назначение правил фильтрации без ручного редактирования каждой конечной точки.
• Шаблоны конфигураций: повторное использование типовых шаблонов для Windows Event Log, syslog и других источников.
• История версий конфигураций: отслеживание изменений, определение авторства и восстановление предыдущих версий при необходимости.
• Визуализация потоков данных: анализ того, какие агенты отправляют события в какие назначения, и проверка правильности настроенных маршрутов в архив и SIEM.

NXLog опубликовала кейс клиента, описывающий, как QNB Finansbank использовал NXLog для фильтрации до 80% событий на конечных точках и передачи критически важных данных в системы безопасности. Это результат, зафиксированный клиентом в его конкретной среде, а не гарантированный или независимо контролируемый бенчмарк.

Ознакомьтесь с NXLog Platform и ее документацией по созданию конфигураций, назначению конфигураций и истории версий конфигураций.

Как проверить сокращение логов без ущерба для обнаружения угроз

Правило фильтрации определяет, какие события будут доступны вашим правилам обнаружения. Ошибочное подавление может ослабить мониторинг безопасности так же сильно, как и неверно составленное правило обнаружения. Относитесь к изменениям фильтрации как к части жизненного цикла разработки систем обнаружения (detection engineering).

1. Измеряйте количество событий до и после. Используйте внутренние метрики NXLog Agent для сравнения объемов с включенным и выключенным правилом. Отслеживайте счетчики отброшенных событий и мониторьте количество событий по источникам и маршрутам.
2. Воспроизводите известные сценарии атак. Запускайте контролируемые тесты для высокоприоритетных правил обнаружения и подтверждайте, что ожидаемые правила продолжают срабатывать после применения фильтрации.
3. Ведите версионность и документируйте каждое изменение. Фиксируйте цель каждого подавления, владельца, затронутые источники и проверенные правила обнаружения. Используйте историю конфигураций NXLog Platform для сравнения или восстановления версий.
4. Ведите список исключений. Документируйте события, которые категорически запрещено фильтровать, включая события, необходимые для криминалистических расследований, комплаенса и критически важных механизмов обнаружения.
5. Пересматривайте правила при изменении источников. Новые политики аудита, обновления операционных систем, релизы приложений и изменения в правилах SIEM могут изменить список необходимых событий.

Внутренние метрики NXLog Agent помогают отслеживать поведение процессов сбора и обработки. Обратитесь к документации модуля ввода Internal Metrics и соответствующей документации по удаленному управлению для вашей версии агента.

Распространенные ошибки при фильтрации перед SIEM

• Ненужная фильтрация сырого сообщения: Используйте разобранные поля, где это возможно. Условия на основе полей обычно проще в поддержке и менее хрупкие, чем сопоставление строк по всему сырому событию.
• Отбрасывание событий вместо их маршрутизации: Как только событие удалено, его невозможно восстановить во время инцидента, если не существует другой копии.
• Фильтрация только на границе SIEM: Это может снизить затраты на прием данных, но не устраняет расходы на транспортировку данных от конечной точки до границы приема.
• Удаление полей без проверки зависимостей: Парсеры, правила обнаружения, дашборды и отчеты могут зависеть от полей, которые кажутся избыточными.
• Оставление фильтров без владельца: Непроверяемые правила могут незаметно устаревать по мере изменения требований безопасности и источников данных.
• Игнорирование требований комплаенса: Сокращение объема данных должно соответствовать утвержденным политикам логирования, хранения и сохранения доказательной базы.

Заключение: Сокращайте расходы на SIEM с сохранением видимости безопасности

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

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

NXLog Agent позволяет организациям применять политики сбора и сокращения логов на источнике, в то время как NXLog Platform помогает централизованно управлять конфигурациями и потоками данных в крупных агентурных сетях.

Softprom является официальным дистрибьютором NXLog. Мы помогаем организациям оценивать решения NXLog, оптимизировать архитектуру сбора логов и интегрировать телеметрию безопасности с SIEM-платформами. Свяжитесь с Softprom, чтобы обсудить вашу стратегию сокращения объемов логов и выявить возможности снижения затрат на сбор данных без потери качества обнаружения угроз.