Downloaded 22 times
Uploaded byOlesya Shelestova
SIEM use cases - как их написать
Документ описывает возможности и потребности в системах SIEM, включая use cases для обнаружения угроз и сценариев атак. Рассматриваются требования пользователей, способы интеграции и необходимость в минимизации ложных срабатываний и улучшении аналитики. Обсуждаются примеры реализации кейсов и важность обратной связи с вендором для улучшения продукта.
More Related Content
Similar to SIEM use cases - как их написать
SIEM use cases - как их написать
- 1. SIEM use-cases Олеся Шелестова CEORuSIEM https://rusiem.com
- 2.
- 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. Спасибо за внимание Олеся Шелестова CEORuSIEM https://rusiem.com