Comments 5
Неужели у Вас нет круглосуточной дежурной смены для отработки инцидентов? Отправка инцидентов в корпоративные мессенджеры скорее всего реализовано у большинства пользователей MP SIEM (как и у нас), но если нет дежурной смены, то какая от них польза ночью?
В случае наличия дежурной смены не лучьше ли было присылать CISO только открытие критичных инцидентов и оповещения об их устранении/закрытии?
Отправка инцидентов в корпоративные мессенджеры скорее всего реализовано у большинства пользователей MP SIEM (как и у нас), но если нет дежурной смены, то какая от них польза ночью?
я без всякого сарказма рад за вас, что у вас достаточно ресурсов (собственно, как и у нас) для организации круглосуточной дежурной смены по мониторингу событий и доработки механизмов автоматизации уведомлений. Но, уверяю вас, далеко не все пользователи SIEM имеют такую возможность (в т ч привлекать SOC на аутсорсинг), кто-то использует и open-source проекты. И мы планируем доработать коннекторы и к другим SIEM, сделать подход автоматизации универсальным. В первую очередь это решение будет полезно таким организациям. Тезис: «не можешь себе позволить SOC – не лезь в SIEM» крайне спорный.
не лучьше ли было присылать CISO только открытие критичных инцидентов и оповещения об их устранении/закрытии?
спасибо, что подтверждаете нашу гипотезу по доработке функционала. В планах реализовать ролевую модель. Например, что бы тот же человек с ролью CISO мог получать ограниченное или настраиваемое количество информации и представление в дашбордах.
Если у вас есть опыт подобной реализации, было бы любопытно услышать и его, делитесь своими наработками!
Мы также начинали с opensource решений. Но через некоторое время пришли к выводу, что их стоимость владения выше, при более низкой эффективности, по сравнению с более зрелыми SIEM (под не зрелыми я понимаю всякие "перекрашенные" в недрах Сколково opensource, а также "перекрашенные" иностранные вендоры в рамках импортозамещения, где так называемый разработчик не разбирается в продукте). Ведь в стоимость владения opensouce также входит собственная разработка коннекторов, постоянный поиск самых актуальных источников индикаторов компроментации (TI) и как оказалось документирование всех изменений и улучшений (очень важная вещь, которой пренебрегают из-за загруженности).
Мы реализовывали оповещения не на основе ролевой модели, а матрицы эскалации с несколькими метриками. Вот основные из них:
владелец актива (например, руководителю ИТ не интересно, что взломали камеру видеонаблюдения, т.к. её обслуживает подрядчик, а эксплуатируют безопасники);
максимальное время, допустимое для реагирования на инцидент;
критичность инцидента.
Эта матрица эскалации является динамической, т.к. интегрирована с CMDB, откуда берется информация.
А на портал расширений PT не добавляли?
addons.ptsecurity.com
«Галя, у нас инцидент!» или зачем мы написали SIEM-чатбота для MaxPatrol