Nxlog не сием, если что

я же сказал да nxlog-ом эту задачу можно решить, сисмон в данном сценарии не нужен

Там выше вам другие люди приводили примеры

Не нужен так не нужен. Продолжайте.

ок, не вижу смысла спорить, я же писал выше, каждый решает задачи как может

кто то длп, кто то лог менеджмент ковыряет, а кто то с сием работает

Вам лишь указали на то что вы неэффективно и нерационально это делаете

Ковыряет и работает. Классные аналогии)))

Я так понимаю tenable sc реашет все проблемы, данного специалиста

Не не не. Тут только сием. Тем более его уже оплатили

злые вы )

Иногда)
А вообще мы прекрасно понимаем какова она - ИБ в идеале и как все делается в реале. Именно поэтому особо нет метрик по эффективности того или иного специалиста в ИБ ;)

Alexey твой выход)

Я тут вспомнил что что-то должен был. А именно продолжить разговор про то , а зачем вообще нужен Сием. И сделать это с одной стороны не совсем общо а с другой стороны в таких терминах чтоб всем было понятно и не очень технически хардкорно.

Внимательно перечитал что писали выше, особенно Максим. И иногда даже его цитировал.

В общем кому не день давайте по генерим ещё.

Зачем тебе SIEM?

В целом:

1.       Знать свою инфраструктуру

2.       Систематизировать и упорядочить происходящее внутри организации

3.       Оперативно выявлять инциденты

4.       Выявлять старые инциденты на основе новых данных

5.       Расследовать инциденты

6.       Делать всё вышеперечисленное с минимальными трудозатратами

7.       Дополнительно (при условии успешности пункта #6).. Дублировать некоторые функции других СЗИ (пересекающиеся с пунктами #1-#5).

 

В частности, (на примерах):

1.       Получать ответы на вопросы о текущем состоянии инфраструктуры (например: что за узлы у меня в DMZ, какие службы запущены на серверах с IIS, и др.).

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

3.       Возможность давать быстрые ответы на простые вопросы, касаемо, как состояния инфраструктуры, так и того что в ней произошло.  (сколько узлов с запущенным сервисов Х, сколько винды на периметре, когда и кто создал учетку Х, когда резолвился и во что домен Х, кто логинился на ip X, Когда и где был файл X с md5 Y, Кто удалил файл Х в папке Y на сервере Z)

4.       При срабатывании корреляции видеть контекст и давать возможность докинуть сюда же дополнительную информацию

5.       Максимально «коробочно» выявлять типовые проблемы\инциденты инфраструктуры, и в то же время иметь простейший инструмент по работе с исключениями и фолсами.

6.       Чтоб система хранила всё и по этому всему можно было делать любой сложности аналитику. Например ретроспективно искать новые паттерны.

7.       Иметь систему способную из коробки собрать всё самое необходимое и нужное с большей части инфраструктуры (без писания скриптов на питоне и других больших трудозатрат). И с другой стороны при подключение новых узлов (обычных\типовых) не переписывать уже настроенные детекты.

8.       Архитектурно поддержать «большие» объёмы. (другими словами не думать, что оно опять не прожует сейчас или отбросит по лицензии).

9.        Иметь возможность впихнуть любые данные в систему и любые из неё вытащить (API и всё что с этим связано)

Все смешалось в доме Сиемских

Да хочется заметить что тут в итоге тебе и AM, и IRP и другие куски других решений.

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

Задач там реально три из всего списка. Остальное характеристики, которые к любому продукту можно отнести. А часть вообще не про СИЕМ ;-)

Я цитировал там других из этого же чатика. Да мне было это приятно ).