Comments 4
SolarSecurity
Например, ретроспективный анализ индикаторов компрометации средствами SIEM занимает слишком много времени, и необходимо найти инструмент, который выполнит эту задачу быстрее.

Не могли бы ли вы подробнее описать функционал этого иструмента, будьте добры, хотя бы в общих чертах.
Встречал множество описаний «best practices» по построению SQL based SIEM запросов, направленных именно на анализ IoC, но не встечал каких либо описаний приватных решений.
Спасибо за статью.
Этой задачей в данный момент как раз занимается команда развития :)
Сейчас часть вопросов автоматизировано в SIEM посредством трендов по ключевым индикаторам компрометации – попробуем описать механизм в отдельной статье.
Но у нас есть несколько идей, которые мы прорабатываем, возможно, поделимся ими чуть позже.
Спасибо, что читаете нас.
Можно ещё цифру — как много подозрений на инцидент (как вы их называете, кстати? ticket? request?) переходит в собственно инцидент?
Каждый шестой — критичный?
Полагаю, что дело в формулировках и преувеличениях, ибо 17% критичных инцидентов — это много.
Дошедшие до первой линии подозрения на инцидент мы называем кейсами. Где то 85% на этом этапе фильтруется, а инцидентами оказываются около 3-4%.
Такая цифра вызвана тем, что часть показателей (критичность инцидента, хоста и УЗ), влияющих на итоговую критичность, проставляется совместно с клиентами.
Также, как правило, скоуп подключенных источников ограничивается системами с довольно высокой критичностью.
Only those users with full accounts are able to leave comments. Log in, please.