Попередня фільтрація та скорочення обсягу логів перед передачею в 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, щоб обговорити вашу стратегію скорочення обсягів логів та виявити можливості зниження витрат на збір даних без втрати якості виявлення загроз.