Количество фолсов на условные миллион событий - менее информативная метрика.

Разговоры об абсолютных числах при неопределенном масштабе инфраструктуры - вообще ни о чем

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

Если ты это имел в виду - то да, согласен

А с этим - нет :)

Дима говорил про метрику "количество фалсов на человека". 50 фалсов в день на одного безопасника - достаточно, чтобы тот перестал обращать внимание на поток мусора, который идет от продукта

Да 🙂 Никогда не видел ни одного продукта, который бы в доке детализировал конкретные требования к персоналу, а не ограничиваясь обычным - знай сетевые технологии и свою инфраструктуру. Если админ крутой CCIE, но при этом его ломает или ему не дают информации о том, какие ОС стоят на узлах, какие патчи и какие настройки, то фолсов будет много, так как продукт будет работать в ваккуме. И это проблема не продукта. И не админа продукта.

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

Поэтому некоторые вендоры продажу продукта конкретному заказчику сопровождают разработкой проектной документации под реалии этого заказчика :)

Ну начался продукт-плейсмент

Особенно применительно к снорту твой совет классно выглядит 🙂

Да ради бога. Если на рынке появится интегратор, который под снорт сделает честный расчет потребности в персонале, я только рад буду. Может, и поучусь чему. Только вот, увы, таких не наблюдается :)

Ну то есть все эти разговоры про требования к персоналу и т.п. - ни о чем в массе своей. И отдельные вендоры не меняют общей картины

Ну, факт, с которым сложно не согласиться: в логах большинства внедрений снорта, особенно в разборе пропртетарных протоколов, действительно творится лютый ад :)

В итоге можно вспомнить результаты аудита Эйнштейна счетной палатой США - когда внедренный снорт не ловил даже метасплойтовские эксплойты - сигнатуры были тупо отключены.

Ну согласись, что если изначально в снорте не было соответствующего препроцессора или кто-то не так использует AppID, то это проблема не совсем снорта 🙂 Как и в случае, если макспатрол натравят на какой-либо контроллер, который от обычного пинга выйдет из строя. Это макспатрол виноват будет?

Как участник одного из исследований архитектуры снорта - не соглашусь :) Там есть архитектурные проблемы, из-за которых он неспособен работать в реалтайме на большом количестве полключенных сигнатур

Именно с этим Эйнштейновцы и столкнулись :)

Есть, кто же спорит. Поэтому разработана была третья версия. А ты тестил вторую. Как и в Эйнштейне

Так Дима и говорил о проблемах тех внедрений, которые мы наблюдаем сейчас. :) Когда (и если) в товарном количестве появятся внедрения с более вменяемой архитектурой снорта, оценка, наверное, изменится :)