0_о как это, кролика еще и поднастроить надо порой

К вопросу о форвдинге событий. TLDR

Дано SIEM A – сборщик, SIEM B – обработчик.
Лог хранится на источнике событий в своем, внутреннем формате (БД, плоские файлы (XML, JSON, syslog)). Источники по типу хранения логов можно разделить на структурированные и неструктурированные. Структурированные – данные изначально нормализованы на уровне хранения (БД, XML…). Сборщик выгружает события тем или иным способом формируя датасет. Выбирая структурированные данные агент сборщика вынужден представить датасет в каком-то внутреннем формате. Если этого не сделать, придется на уровне правил нормализации оперировать бинарным объектом (тупо писать парсер бинарного блока). Внутренним форматом может быть тот же JSON, XML и т.д. Если собираем неструктурированные данные, то никакого представления не надо. Просто в нормализатор приходит строка текста.
Т.о. мы имеем агент Сборщика, и его выхлоп в виде датасета в том формате, который удобнее всего использовать для конкретной реализации нормализатора. В этом датасете вся структурированная инфа разложена в логике исключительно конкретного SIEM.

Пусть теперь есть Обработчик. Он получает на вход такой датасет. Он абсолютно ничего не знает об этом формате и не может передать его в свой нормализатор (как точку интерпретации данных).
Выхода из этой ситуации 2:
1.  Все вендоры договариваются об общем формате (CEF – не стандарт для отрасли… почему не LEEF или еще что-то). Утопия
2.  Почему-то именно вендор вашего SIEM должен представить датасет по правилам других вендоров. Т.е. изначально делать 2,3 4-ную работу при поддержке источника. Это экономически нецелесообразно.
3.  При интеграции Сборщика с Обработчиком вы сами пишете правила перенормализации одного формата в другой. Делаете это именно под ваш стек вендоров и именно ваши источники. Следите за появлением новых типов событий (при обновлении источников событий).

Стена бУкАв... я предупреждал... уберите от мониторов женщин, детей

мы забили и делаем свою датамодель для нормализации. И под неё уже делаем парсеры/обработчики/etc. Да, в начале затратно по ресурсам, но в процессе эксплуатации, а еще тем паче интеграции со всяким внутри - головняка в разы меньше

Ну вот ровно в этой логике и реализованы все SIEM :)

но я же написал то же самое, только кратко! Почему всегда больше верят тем кто умеет в много бУкАв?

они реализованы в рамках “кругозора” и решаемых разработчиком задач. Ну и собственно в этом случае никто не обещал стандартных решений

Попробую развенчать еще один миф (Миф – морозная свежесть(реклама стирального порошка)): «Засуньте все в CEF, его все понимают».
Давайте разделять проблемы формата и семантики. Засунуть-то в CEF можно, главное - чтоб полей хватило. Вопросы начинаются с семантикой. Откуда Обработчик узнает по каким правилам я расталкал данные в поля CEF? Правильно, никак. Тогда эта проблема ноднимается на уровень выше – правил корреляции. Вот там-то и начинаются условия: Если пришлоиз SIEM A, то имя пользователя в этом поле, а если из SIEM B, то вот в этом поле.
Или еще хуще… правилами корр. или обогащения начинают перенормализовывать события.

Потому, что лень читать. Но раз буКаВ много, значит есть какие-то аргументы и надо думать ))))

Да ну хорош... тут же все инженеры. в чем проблема взять написать скрипт или распарсить незнакомый стандарт (file, cef, json and etc).
В чем вообще проблема куда то выгрузить или принять события

да нет никаких проблем, если изначально быть готовым к тому, что надо будет поработать руками. Я хотел донести почему из коробки такого не получить.

Ну, тебя я прочитал например 😅
А Николай ... ну прошу прощения

в этом чатике остались наивные люди, уверовавшие в коробочное решение? 😁

Да, я, например

Поэтому ты создал продукт, работающий в облаке)))
На правах легкого троллинга

Юношеский идеализ с нотками слабоумия... мне простительно

Кек.... изкаробкиже

Ты силён бро, пилок для лобзика выслать? 😉