одним и тем же результатам

Как так? Ведь в отчете есть полное описание найденной уязвимости:

<id>
<title>
<short_description>
<description>
<how_to_fix>
<links>
<publication_date>
<cvss>
<cvss3>
<CVE>

Можно же взять эти данные и импортировать в SIEM. Но...

Коллеги привет! Подскажите, кому-нибудь приходилось настраивать логирование Linux не поддерживаемых официально версий? Например у меня много машин с Ubuntu 16.04 (auditd 2.4.5), а поддерживается не ниже Ubuntu 18.04 (auditd 2.6), соответственно есть проблема при конфигурации auditd. Официальная поддержка ничего предложить не может, а обновляться нельзя. Есть какие-нибудь варианты настройки, может быть с ограниченным функционалом?

Можно, просто не установятся некоторые правила auditd (в большинстве случаев это некритично) и не будет enriched-формата - это имеет значение, но события всё равно обрабатываться должны
Тонкость с нагруженными системами (например, haproxy), там не получится сделать адекватную фильтрацию
Соответственно, не нужно включать enriched и делать настройку для высоконагруженных систем

ок, попробую не включать

Честно говоря, до реализации дело не дошло. Когда делал оценку этой задачи, то получилось, что трудозатраты на изменение нормализации всех логов винды выше, чем потенциальная польза от такого подхода (в моём случае польза была небольшой). В итоге сошлись на стандартном подходе - WEF + кастомная нормализация некоторых событий.
По транспорту приценивался как раз к ODBC и не увидел особых проблем.

У нас просто задача собирать логи кастомного приложения, которые оно пишет в ES на репорт-сервере

То есть нормализацию в любом случае делать нужно, но только для 1-2 типов событий

Подскажите. Не получается выполнить задачу Unix audit.  При разных настройках транспорта всегда одна ошибка: Не удалось выполнить сценарий ds~SSH.MicrodetectDeviceType...

Debian 9.12

там вариантов почему так море

можете весь лог задачи показать?
(можно приватно)

Коллеги, всем привет. Извинияюсь, что немного не по теме, но может кто подскажет: есть коннекты до серваков с майнером, АВЗ проверкой все чисто, порты по которым ходят согласно сессиям в НАДе закрыты на конечном узле. Как следы xmr.nanopool моэно найти?

Подскажите пожалуйста, в SIEM можно как то оперировать открытыми портами активов? К примеру, провожу инвентаризацию подсети, и при обнаружении открытого порта N на узле создаётся инцидент, это реально сделать или нет? В активе просто порты перечислены и как я понял не привязаны к переменным

Можно сделать табличный список, который будет PDQL-запросом дергать инфу из активов и уже его использовать в корреляции. Допустим если есть событие с IDS в котором упоминается данный порт, то создавать инцидент

Другой вопрос есть-ли IDS и увидит-ли она обращения на этот порт

Там ведь только сработавшие правила логируются а не все пакеты

Без скриптов это делается правилом, перепроверяющим ТС по pdql с активом в ответ на "тактирующее" событие. Поллинг по таймеру, короче говоря. Событие должно быть таким, чтобы не дёргать опрос слишком часто