с таким-то ником неудивительны такие результаты, вы жы хакир!!1

Корреляция это тоже про поиск

я и не пробовал) проще было взять то что из коробки лучше и тюнить надо позже

Для человека который на инцидент реагирует дежурствами в серверной вы слишком много тут пишете

зачем переходить на личности, любой продукт можно затюнить

я на инцидент реагирую запуском одного из предварительно настроенных сценариев оркестратора

Я там выше написал что это частности. Смысла в кейсах нет

а если нет сценария под инцидент? )

"нет сценария" это универсальный сценарий "загнать сервис в песочницу")

ну ну. подозрительный днс запрос как вы в песочницу загоните

@stvTel и это, как хакир, расскажите мне, что такое серверная и зачем там дежурят?

Это вы об этом в своём знаменитом жж писали.

что бы свет отключать, когда сценарий не отработает )

описываемые там события были 20 лет назад:, закопайте уже стюардессу, гражданин

техника в руках дикарей-с.

А давай попробуем :)

1. структурирование и обогащение информации из исходных данных (контекст к хостам, уз, событиям, ip, обогащение из внешних источников и т.д.)
- Хочу вместо сырого лога видеть где и кто (имена и описания)
- понимать статус инфраструктуры: инвентаризация и детекты изменений
- типизация логов и возможность работать с данными от разных систем в едином интерфейсе единой логикой запросов\фильтров\правил

2. возможность давать быстрые ответы на простые вопросы:
- когда и кто создал учетку Х
- когда резолвился и во что домен Х
- кто логинился на ip X
- Когда и где был файл X с md5 Y
- Кто удалил файл Х в папке Y на сервере Z

3. Корреляция
- при срабатывании правила получить максимум контекста, необходимого для разбора: докинуть доступную в логах информацию (даже если это событие было год назад)\сделать запросы к внешним сервисам\добавить инфу из сетевой модели\привязать алерт к человеку а не к УЗ

- фильтрация фолсов\исключения (и по логам и по внешней информации) - хочу сам выбирать логику, что и как убирать из срабатываний. Причем делать это максимально просто и быстро без редактирования кода правила

- Получить информацию о статусе хоста\уз в момент возникновения события, а не то, что было неделю назад при сканировании или будет через Х минут после отработки скриптов при наличии доступов\прав\сзи и т.д.

- Выявлять инциденты: возможность любым способом обработать событие, приклеить к нему другие, посчитать кол-ва на нужном интервале времени. Хочу иметь возможность выявлять любые паттерны атак, которые есть в логах, максимально быстро (минуты) к моменту, когда соответствующая информация появилась в логах. При неограниченном кол-ве правил детекта (тысячи)

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


4. Поиск по данным
- Разбор инцидентов: хочу иметь возможность извлекать из данных различную информацию, группировать в разных вариантах, смотреть статистику, менять формат и набор полей\графиков для отображения событий

- выгрузки\отчеты для разбора\отчетности и\или дальнейшей обработки с гибкой настройкой

5. Архитектура
- нормально переживать всплески (х10 от «среднего»): не падать и не дропать события при превышениях лицензии\лимита и т.д.
- быстрое подключать новые системы так, чтобы вся корреляция для типовых кейсов на них распространялась без необходимости писать все заново
- возможность сокращать входящий поток для экономия места и железа
- интегрироваться с любыми внешними системами (скрипты на корреляцию, апи для получения данных, коннекторы для сбора данных по любым доступным протоколам)

6. Не терять логи и быть готовым к поиску и восстановлению таймлайна атаки\взлома\утечки

7. Упростить работу с логами: не писать скрипты на питоне\С\yaml\java и т.д., а работать с данными в нормальном удобном и простом

Ну и так далее :)

Макс, ты в электричке что ли едешь?

8. Приоритезация всего выявленного барахла (понимание где что-то единичное, а где массово. Что критично, а что - не очень). Но это в том числе про контекст

ага :)

Заметно )