Что такое use-cases для SIEM, как их правильно составить.

1. SIEM use-cases
Олеся Шелестова
CEO RuSIEM
https://rusiem.com

2. Возможности
системы
Потребности
пользователей
Use-cases
Симптомы
угроз
Сценарии
известных атак
Интеграции
Средства
обнаружения

3. Что хочет потребитель продукта
• Detect compromised assets
• Web applications attacks detection
• Other attack (network, database, applications, etc) detection
• Infected system tracking, malware and anomaly detection
• User behavior analysis (old terms - User authentication tracking)
• Authorization and rights assign tracking
• Tracking use of system and privileged accounts
• Tracking application, software, assets, network devices
• Tracking mobile and portable devices
• Network, applications, database, OS, device errors and lost prevention
• Personal tracking, relationship and total control with possible threat prevention
• Compliance

4. Как хочет
• Минимум сил для поддержания эффективности системы
• Само-восстанавливаемость, контроль поступления событий с
источников
• Минимизация числа ложных срабатываний, агрегация
• Пополнение базы знаний (KB) от вендора с регулярной
периодичностью
• Развитие механизмов обнаружения угроз продукта
• Возможность влияния на реализацию кейсов и возможностей
продукта
• С оценкой влияния на бизнес-процессы
• С расчетами затрат, оценкой эффективности и приносимой пользы
бизнесу

5. Почему классических СЗИ не хватает
• Множество ложных срабатываний
• Скупость данных для принятий решения
• Отсутствуют механизмы глубокого анализа и корреляции
• Ресурсоемкие операции
• Недостаточность исторических данных

6. Как работает SIEM
Событие
источника
• Уровни
детализации
• Что пишем в лог
• Какие источники
Агент или без-
агент
• Частота сбора
• Оффлайн-хранение
• Неизменность
данных
• QoS
Нормализация
событий
• Разбивка по
key:value
• Обогащение
событий
• Тегирование
событий
Корреляция
• По факту события
• По числу событий с
контекстом
• По
последовательности
фактов
• С учетом доп-
данных
• Формирование
инцидентов и
уведомлений
Аналитика
• Управляемые
алгоритмы
• Управляемые
модели
• Счетчики, триггеры
и данные в быстром
доступе
Долгосрочное
хранение
• Хранилище событий
• Статистические
данные
• Данные расчетов и
моделей
• API

7. Откуда брать кейсы
• «Коробочное решение вендора» с экспертной KB – как фундамент
• Слайд #3 с оценкой на ваши системы
• Уже произошедшие инциденты в вашей или другой компании
• Потребности и слабые технологические стороны бизнеса
• Бюллетени угроз и новостные ленты
• Фантазия в стиле «а если…»
• Пентесты
• Уязвимости и угрозы которые нельзя устранить, но можно
контролировать
• Подход «хочу видеть как, что и где»

8. Различие кейсов, симптомов и сценариев
Use case
• Контроль
привилегированных
пользователей
• Массовое удаление
файлов
• Использование чужих
учетных записей
• НСД к почтовым
ящикам на почтовом
сервере
Сценарии
• Вход с ip под УЗ с
которого ранее не
было подключения
• Удаление более 500
файлов за минуту под
УЗ увольняемого
сотрудника
• Вход на сервер и
использование ранее
открытой консоли
управления в другом
сеансе
Симптомы
• Удаление файлов
• Интерактивный
вход
• Подключение к
почтовому ящику
• Установка опции
копирования почты
в другой ящик

9. Что на выходе кейса?
• Инцидент, зафиксированный в SIEM с уведомлением
• Правило аналитики и инцидент с уведомлением
• Проактивная команда с принимаемым на вход массивом переменных (например,
блокируемых ip)
• Порожденное событие/snmp trap/уведомление
• Регламент реагирования на инцидент
Если нет необходимости в незамедлительном уведомлении:
• Сохраненный запрос для быстрой выборки
• Отчет
• Виджеты дашборда
• Статистические данные

10. Залог успешных use-cases
• Вариант 1. Мы понимаем что конкретно хотим контролировать/знать
об этом/предотвращать.
• Нам необходимо:
• Понимать вектора реализации наших угроз
• Эмулировать кейс, выделить идентифицирующие события для этой угрозы
• Понять что об этом факте генерируется одно, множество (различных) или
последовательность событий
• Если нет событий – возможно включить аудит или повысить уровень
детализации или использовать другое СЗИ
• Понять с помощью каких источников сможем достоверно определять,
подключить их при необходимости
• Написать правило корреляции/аналитики/статистики для данной угрозы или
вынести идентификаторы на дашборд/в сохраненный запрос/отчет.

11. • Вариант 2. Необходима помощь и сторонняя оценка
• Необходимо:
• Провести независимый пентест (экспертизу)
• Обратиться к интегратору или вендору
Залог успешных use-cases

12. • Вариант 3. Мы мало знаем о нашей инфраструктуре и процессах
• Необходимо:
• Подключайте источники. Можно даже наобум.
• Смотрите события и информативность источников
• Меньше правил корреляции с оповещениями если вы не уверены. Больше
дашбордов и уточняющих сохраненных запросов. Изучайте.
• Попробуйте взглянуть глазами злоумышленника – какие вектора и сценарии
есть для того чтобы:
• Вывести приложение/БД/ОС из строя (а также симптомы-предвестники программно-
аппаратных сбоев не по вине атак)
• Повысить привилегии для доступа к данным
• Удалить/скопировать/несанкционированно изменить данные
• Инфицировать систему
Залог успешных use-cases

13. «Обладать информацией – быть богом»
• Логируйте кто/что/куда/когда/как/откуда. Возможно, это спасет не только
вашу карьеру но и бизнес.
• Держите руку на пульсе. Сценарий/правило/сигнатура в лучшем случае
придет через сутки-трое. Возможно вам написать обнаружение угрозы будет
намного быстрее.
• Сконцентрируйтесь на главном. Представьте что SIEM не «еще один»
инструмент, а ваша единственная приборная панель. Причем достаточно
гибкая. Все что вы хотели бы увидеть – можно осуществить!
• Всегда! Всегда! Проверяйте кейсы и сценарии, даже если это прислал
вендор/интегратор. Язык ОС/продукта, версия, настройки логирования могут
отличаться. В итоге вы будете словно в пустыне ждать волны с серфинговой
доской.
• Чаще PDCA! Приглашайте сторонних аудиторов, устраивайте своими силами
проверки кейсов, выявляйте новые вектора и пишите детектирующие
правила.

14. Простые примеры
• Пример 1. Нам необходимо контролировать изменение пары ip-mac.
Цель - событие в SIEM/отчет/инцидент/уведомление.
• Технической возможности в SIEM (к примеру) нет.
• Вариант 1: использовать стороннее приложение, способное
предоставлять такие события об изменении.
• Вариант 2: использовать arpwatch внутри сегментов (или с arp-proxy
если сеть небольшая).
• Вариант 3: использовать скрипт в доменных групповых политиках с
передачей в локальный евент-лог с последующим сбором.
• Вариант 4: если имеется DPI/Flow-like сетевой сенсор - подключить его.
• Вариант 5: Обратиться к вендору/интегратору с FR для реализации
кейса.

15. Простые примеры
• Пример 2. Нам необходимо знать об устаревших и
незаблокированных учетных записях.
• Технической возможности в SIEM (к примеру) нет. События на
источнике об этом не генерируются, так как учетная запись не
используется.
• Вариант 1: использовать стороннее приложение/скрипт,
способное получить необходимый параметр с отправкой на SIEM.
• Вариант 2: использовать сканер и интеграцию с SIEM

16. Простые примеры
• Пример 3. Нам необходимо знать об устаревших, не валидных и
самоподписанных сертификатах, используемых на веб-серверах
в нашей компании.
• Вариант 1: использовать сетевой сенсор в SPAN режиме с
возможностью разбора протокола, извлечения сертификата с
отправкой на SIEM.
• Вариант 2: использовать сканер и интеграцию с SIEM

17. Простые примеры
• Пример 4. Контроль запускаемых исполняемых файлов вне
системных директорий ОС.
• Вариант 1: Включить аудит в групповых политиках, либо
использовать auditd для linux серверов.
• Вариант 2: Использовать агент RuSIEM или стороннее ПО для
контроля процессов.
• Вариант 3: Использовать антивирусное ПО на Windows серверах и
рабочих станциях (если оно установлено) с возможностью снятия
дампа по процессам.

18. Простые примеры
• Пример 5. Контроль областей автозапуска в ОС.
• Вариант 1: Включить аудит в групповых политиках, либо
использовать auditd для linux серверов.
• Вариант 2: Использовать сторонее ПО, интеграцию с аудитными
сканерами.

19. Простые примеры
• Пример 6. Контроль несанкционированного подключения к
чужим почтовым ящикам MS Exchange.
• Вариант 1: Воспользоваться уже имеющейся базой знаний в SIEM
системах. Сэмулировать кейс подключившись различными
способами, проверить детектирование. Проверить
детектирование на установку опции копирования на другой
почтовый ящик.
• Вариант 2: Написать самим правило корреляции, отчеты для
данного кейса, либо обратиться за помощью к вендору или
интегратору.

20. Фидбэк для вендора
• Большая часть кейсов могут быть индивидуальны и применимы
только для вашей компании и только для ваших систем.
• Не ленитесь описать ваш кейс и отправить вендору. Скорее всего,
кейс будет расширен и будут обновлены возможности продукта.
Или с помощью экспертного мнения – в продукт будет добавлены
еще правила обнаружения, которые помогут в дальнейшем Вам!

21. Спасибо за
внимание
Олеся Шелестова
CEO RuSIEM
https://rusiem.com