Коррелятору достаточно только читать, обагатителю записать только первые N раз для каждого фолзящего правила. Если у вас каждое из правил фолзит, то это немного странно)

1. Где-то в настройках сиема (в ptsiem.conf?) есть настройка временного окна для ашгрегации инцидентов. По умолчанию пять минут, для начала ее надо увеличить.
2. Аггрегируются в один инцидент корреляции у которых совпали два кортежа полей про соус и дестинейшн. Полный список на память не помню, а я сейчас не на работе.
3. Если хоть одно из этих полей не задано, т.е. null, то поле считается "другим" и агрегация не происходит.

В основном из-за третьего пункта агрегация инцидентов никогда не наблюдается в дикой природе.

вот, цимес в том, что и схема такая начала работать только с 19.1 (появилась возможность коррелятором и обогащатором лазить в один список), а синхронная схема работы со списком коррелятора при этом отъехала

Коррелятор, вроде, всё так же работает последовательно, что там отъехало я не догадался...
И до R19.1 схема работала, просто приходилось прокидывать "метку" из обогатителя в коррелятор через datafieldN.

3й пункт это дичь, равно как и фиксированный набор полей в агрегации

Логичным выглядит агрегация инцидентов через механизм агрегации событий, точнее реализовать преагрегацию через него.

и как это будет работать? инцидент будет задерживаться агрегатором на Н минут? или в уже созданный инцидент будут привязываться новые?

1. Где-то в настройках сиема (в ptsiem.conf?) есть настройка временного окна для ашгрегации инцидентов. По умолчанию пять минут, для начала ее надо увеличить.
2. Аггрегируются в один инцидент корреляции у которых совпали два кортежа полей про соус и дестинейшн. Полный список на память не помню, а я сейчас не на работе.
3. Если хоть одно из этих полей не задано, т.е. null, то поле считается "другим" и агрегация не происходит.

В основном из-за третьего пункта агрегация инцидентов никогда не наблюдается в дикой природе.

Если рассматривать текущий механизм агрегации событий - с задержкой в N минут.

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

Ну вы же сами говорили про 2 часа ночи и миллионы инцидентов. N в 1 минуту уже значительно упростит вам жизнь.

1 - mpxcore, параметры
IncidentAggregationTimeout = '00:01:00' (String)
IncidentIdenticalNotificationLimit = '100' (String)
?

упростит чем? тем, что выгребать меньшее количество инцидентов по итогу?

Да, и что БД не упадет.

в тему про минимальные аппаратные требования для пилотов, вот дока