Благодарю за ответы! Буду разбираться

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

В качестве тактирующих отлично годятся WMI подписки, кстати. Прямо в профиле частоту задать можно в запросе. Собирать агентом с самого себя

Ну и алгоритм принятия решения о нарушении вам надо очень чётко представлять. Как задать эталон? Что делать, если он меняется?

В моём случае эталон наверное это будет что порт закрыт, если порт открыт соответственно какой то сервис там начал работать и генерируется инцидент.

Источник информации об открытости кто? Host discovery и pentest? Они у вас в фоне постоянно идут?

Постоянно не идут, планировалось по расписанию запускать

Источник... это уже тестировать надо, что будет лучше

Друзья, через 20 минут начинаем наш онлайн-запуск новой версии PT Sandbox. Присоединяйтесь по ссылке: https://youtu.be/dtngvgtkGRo

18+, однако

думаешь, что стоило 21+ поставить?

ну если вы туда реальный "кастомер экспириенс" показывать будете, то, пожалуй, да... и площадку выбрать другую, а то это вроде как запрещенный на тытрубе контент

ну вот если вы запускаете сканирование раз в сутки или реже, то, кажется, можно сделать следующие предположения:
1) Целью генерации алерта/инцидента является привлечение внимание условного аналитика к факту наличия проблемы как таковой
2) Для начала "расследования" аналитику будет достаточно выполнить сохранённый PDQL запрос, которые выведет список узлов и открытых портов
3) Генерировать "инцидент" чаще раза в сутки нет никакого смысла

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

Вот возможная и легко реализуемая схема

Спасибо за развёрнутый ответ, вроде все ваши слова и логику построения процесса понял

процесс тут всему голова
алерты сами по себе не нужны

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

Единственное я не понимаю как через pdql запрос получить список портов актива. Зайдя в актив там порты просто ведь перечисленны, у них нет никакой переменной.

что такое "переменная"?

Это я имею ввиду «поле»

В синтаксисе только имеются Src.port и dst.port, но тут они не помогут ведь