Корпоративные SIEM ловят всего 24% техник MITRE ATT&CK! На кой они тогда нужны?

Знаете, чем Gartner навредил рынку ИБ? Он приучил нас выбирать не решение своих задач в ИБ, а аббревиатуры классы средств защиты (NGFW, WAF, VM, DLP, EDRM, SIEM и т.п.). А ведь нам нужно не это — нам нужно предотвратить реализацию недопустимых событий или, для апологетов старой школы, бороться с актуальными для нас угрозами и нарушителями. Бессмысленно выбирать NGFW, если мы не знаем, с какими угрозами он борется. То, что вендор присвоил своему продукту какую-то аббревиатуру, еще не значит, что продукт способен бороться с соответствующей угрозой.

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

Что такое SIEM? Система управления событиями безопасности, ответите вы и будете… правы. Но правота эта у каждого своя. Кто-то действительно оценивает такие решения по их возможности собирать события безопасности… от своих же собственных продуктов, коих всего два или три. Кто-то умеет работать с разными продуктами разных вендоров. А кто-то фокусируется на обнаружении именно инцидентов. Кто требует встроенной интеграции с ГосСОПКОЙ, а кому-то интеграции с SOAR/IRP подавай?

Вы, кстати, можете схожу описать отличия SOAR и IRP?

В 2020-м году Positive Technologies проводила исследование и среди прочего выяснила, какие типовые задачи ставят перед собой пользователи SIEM.

И кажется, что если выбираемая вами SIEM умеет собирать, хранить и обрабатывать события ИБ, то мы решаем все свои проблемы. Но это, увы, не так. CardinalOps тут разродился третьим ежегодным исследованием способности SIEM детектировать угрозы.

Вы же помните, что задача средств защиты делать недопустимое невозможным обнаруживать и отражать, нет, не события безопасности, а угрозы/атаки/инциденты ИБ?

И вот что интересно. Собранные проанализированными SIEM, а это были решения Splunk, Microsoft Sentinel, IBM QRadar, Sumo Logic (MaxPatrol SIEM в тестах не участвовал), данные позволяют покрыть 94% техник MITRE ATT&CK. Ура, фанфары!.. Но стоп. Позволять-то они позволяют, но в реальности обнаруживают только 24% от выбранных для исследования 196 техник из 13-й версии матрицы MITRE (почему 196, а не 500, история умалчивает, но тогда бы цифры были еще хуже). То есть производителям SIEM пора фокусироваться не на том, чтобы собирать больше данных, а на том, чтобы больше и быстрее детектировать в существующих.

Иными словами, большинство SIEM не могут детектировать не менее 150 техник, используемых злоумышленниками!

А учитывая, что многие покупатели используют правила корреляции «из коробки», то даже если бы они и могли самостоятельно настроить возможности купленных SIEM, то все равно не могут этого делать по множеству причин — от нехватки квалификации до нехватки времени.

Если вернуться к исследованию CardinalOps, то они обращают внимание на еще один момент с корпоративными SIEM, а именно на покрытие им различных платформ. Логично, что основные серверные и ПКшные платформы неплохо анализируются, но вот бизнес-приложения и контейнеры сегодня находятся явно не в фаворе:

1. Windows — 96%
2. Network — 96%
3. Identity & Access Management (IAM) — 96%
4. Linux/Mac — 87%
5. Cloud — 83%
6. Email – 78%
7. Productivity Suites (primarily Office 365) – 63%
8. Containers — 32%

И это несмотря на то, что согласно Red Hat 68% организаций уже используют контейнеры в своей инфраструктуре.

А что делать, спросите вы. И я вам скажу банальную вещь. Не надо выбирать аббревиатуру, как бы ее не рекламировали и какие бы плюшки не сулили за покупку. У вас, у вендора и у регулятора может быть свое понимание аббревиатуры SIEM. Более того, может вам вообще не нужен SIEM. Ну это я крамолу высказал 🙂 Решение по обнаружению инцидентов (заметили, что я уже не использовал четырехбуквенную аббревиатуру) вам скорее всего нужно, но выбирать его надо с умом. Вот на что я бы обратил внимание:

• Для каких сценариев вам нужно решение по мониторингу? Как и кем они определяются? Как управляются?
• Как и кем разрабатываются новые детекты для выбираемого решения?
• Как долго разрабатываются новые детекты?
• Как и кем оцениваются уже несрабатывающие детекты?
• Как вы отрабатываете ложные срабатывания?

Из первого пункта можно сделать вывод, что и MITRE ATT&CK нам не особо и показатель, если мы можем четко определить сценарии (use cases) для работы решения по мониторингу. Да, вполне возможно. Если по результатам использования бюллетеней Threat Intelligence, BAS, пентестов, редтиминга, багбаунти, киберучений вы можете четко описать, что надо ловить, как (детекты) и где (источники телеметрии). Тогда и на число покрываемых техник MITRE ATT&CK можно закрыть глаза.

В общем, не ведитесь на аббревиатуры и кем-то определенные классы средств защиты. Неблагодарное это дело и ведущее не к тому результату, который вам нужен.