Как приоритезировать события в SOC?

На последнем PHDays, где я вел секцию по SIEM, все участники сошлись во мнении, что правила корреляции из коробки не работают и про них надо забыть сразу после покупки решения по управлению событиями безопасности. С SOC ситуация ровно таже самая и перед нами встает вопрос не только о том, как создать правила корреляции событий, но и как приоритезировать эти события, попадающие в поле зрения SOC. Как отсечь ложные срабатывания от реальных инцидентов?

Можно предложить следующий алгоритм, завязанный в том числе и на Kill Chaim, которой посвящено несколько моих последних заметок. При приоритезации мы должны учесть несколько важных параметров:

• фазу Kill Chain
• зрелость метода обнаружения
• кампанию.

Я уже писал раньше, что чем раньше мы обнаруживаем угрозу, тем эффективнее работает SOC. Верно и другое. Чем дальше по Kill Chain продвинулась угроза, тем опаснее она для нашей компании и тем меньше действий злоумышленнику надо осуществить для нанесения ущерба. Поэтому стадия Kill Chain является первым элементом при приоритезации обнаруживаемых угроз, требующих реакции работников SOC.

Вторым важным параметром является принадлежность инцидента/угрозы какой-либо хакерской кампании, оцениваемой по результатам атрибуции, о которой я уже тоже неоднократно писал. Мы прекрасно понимаем, что одно дело, когда мы попадаем под раздачу в рамках веерной атаки, даже и направленной не нас. И совсем другое дело, когда именно мы являемся мишенью для злоумышленников и все свои усилия они соредотачивают на нас. В этом случае наша реакция должна быть в первую очередь направлена на инциденты, напрямую нас затрагивающие.

Третий параметр, влияющий на приоритет рассмотрения угроз в SOC, - это зрелость способа детектирования угрозы. Мы прекрасно понимаем, что у нас может быть сигнатура IDS или результат работы Threat Intelligence Platform, которые на 100% дают нам положительной ответ о наличии угрозы в сетевом трафике или каком-либо файле. Это так называемый стабильный уровень зрелости обнаружения, который будет давать тот же самый результат при любом количестве повторов. Уровень ложных срабатываний при нем будет равен или очень близок нулю. Никакой доработки данный метод не потребует и он живет своей жизнью в рамках SOC. Другое дело, когда мы имеем дело с совершенно новым и еще не аппробированным методом детектирования, который не имеет доказанной эффективности и может давать достаточно высокий процент ложных срабатываний. В этом случае можно говорить о низком, экспериментальном уровне зрелости.

Соответственно, приоритет инцидента является функцией от трех параметров, и чем дальше от нуля на графике у нас находится значение любого из параметров рассматриваемого инцидента, тем приоритетнее он для нас является. Можно, конечно, числол оцениваемых параметров увеличить, но работать с ними будет тогда сложнее. Меньше тоже можно. В конце концов можно и вовсе свести все к фазе KIll Chain и приоритезировать только по ней. Однако трехкритериальная оценка мне видится наиболее оптимальной.

ЗЫ. На SOC Forum можно подисскутировать на эту тему и задать вопрос о приоритезации выступающим, представляющим разные SOCи России.