Только сислог чистый 200 мб за раб. смену. Жмется в 10 раз, хранится 2-3 года. Дампы месяц-два, репорты из них подольше.

А события этого сислога ни чем не агализируются?  Корреляции никакой не проводится?

А есть другие варианты?

Ничего круче, чем увидеть факт трафика, которого быть не должно - нет, имхо.

В тему вопрос: кто как мониторит, есть штатная позиция аналитика? что-нибудь вроде ot soc или все льётся в корпоративную сеть?

Все самописное.

Ну есть варианты более постоянного мониторинга: netflow, snmp, syslog, zeek, от опенсорс до коммерческих

Не понял ничего. Все это используется в совокупности, но не все применимо на любом участке сети. Это все и есть логи в широком симсле. Например, в лвс иметь нетфлов - не всегда возможно, класс оборудования может не позволить. Значит задействуем зеркалирование, будем дампить и парсить для критичных сегментов. Если сегментация средствами фв - у него есть логи и это будет сислог и так далее, тот еще слоеный пирог костылей. Как это соотносится с постоянством  - не понял.

У нас в организации другая проблема - это не нужно никому.

+ такая же беда

Я делал, что бы спать спокойно и посмеиваться над кидо и ванойкрай. Вроде пока получается. А так, нарыть если зловредную активность в сторону бизнеса - даже доложить некому. Бывает целый квест, до кого донести инфу. Потом приходит понимание - ни до кого, а то крайним станешь.

Собирать логи не проблема, вот нужна позиция для анализа. Что считать нормальным поведением на АРМах, а что нет.Для этого нужен сием или аналитик выделенный. По трафику есть участки где вообще не получится снимать копию трафика онлайн в связи с архитектурой которая уже построена на предприятии, а модернизировать сеть это очень много проблем и затрат пока.

Мы разрабатывали специальные учетки для операторов, где строили шаблон разрешенных действий, так сказать что является нормальным поведением оператора за АРМом, и если события с логов не выходили за рамки этого шаблона то значит гуд. (я имею виду события с ОС а не с технологии).

Хорошему админу делать все равно нечего :) Пусть сидит и матрицу читает :) На счет понимания - когда все построено с нуля и каждое правило в фв ты методом проб и ошибок добавлял, то л3-л4 понимание де факто есть. Л7 внутри уже конечно не потянешь, идс не заменишь :)

События с ос - это другое, я о телекоме больше.

Мы трафик анализируем тока пост фактум, я гросмарлин юзаю. Так у нас на каждой точке локальный FW который режет все что не нужно для работы ПО по портам (а вот в трафик приложения не разбираем не нужно это пока).

Как решаете проблему разбросоной инфраструктуры, много сетевого оборудования по площадкам. Как трафик заводите на точку для анализа?  У нас когда с сетевого оборудования начинаешь настраивать передачу копии трафика всего для анализа, то резко возрастает нагрузка на сетевое оборудование + во время тестирования выяснили что не вся копия трафика заворачивается с зеркалирования.

Решается размещением сенсора на площадке и организацией низко скоростного каналы до точки агрегации событий.

Сам аналииз трафика и  его хранение для пост анализа выполняет сам сенсор, в канал отдаёт мету.

Гроссмарлин 61850 же не может?!