Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SIEM use cases - как их написать

747 views

Published on

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

Published in: Software
  • Be the first to comment

SIEM use cases - как их написать

  1. 1. SIEM use-cases Олеся Шелестова CEO RuSIEM https://rusiem.com
  2. 2. Возможности системы Потребности пользователей Use-cases Симптомы угроз Сценарии известных атак Интеграции Средства обнаружения
  3. 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. 4. Как хочет • Минимум сил для поддержания эффективности системы • Само-восстанавливаемость, контроль поступления событий с источников • Минимизация числа ложных срабатываний, агрегация • Пополнение базы знаний (KB) от вендора с регулярной периодичностью • Развитие механизмов обнаружения угроз продукта • Возможность влияния на реализацию кейсов и возможностей продукта • С оценкой влияния на бизнес-процессы • С расчетами затрат, оценкой эффективности и приносимой пользы бизнесу
  5. 5. Почему классических СЗИ не хватает • Множество ложных срабатываний • Скупость данных для принятий решения • Отсутствуют механизмы глубокого анализа и корреляции • Ресурсоемкие операции • Недостаточность исторических данных
  6. 6. Как работает SIEM Событие источника • Уровни детализации • Что пишем в лог • Какие источники Агент или без- агент • Частота сбора • Оффлайн-хранение • Неизменность данных • QoS Нормализация событий • Разбивка по key:value • Обогащение событий • Тегирование событий Корреляция • По факту события • По числу событий с контекстом • По последовательности фактов • С учетом доп- данных • Формирование инцидентов и уведомлений Аналитика • Управляемые алгоритмы • Управляемые модели • Счетчики, триггеры и данные в быстром доступе Долгосрочное хранение • Хранилище событий • Статистические данные • Данные расчетов и моделей • API
  7. 7. Откуда брать кейсы • «Коробочное решение вендора» с экспертной KB – как фундамент • Слайд #3 с оценкой на ваши системы • Уже произошедшие инциденты в вашей или другой компании • Потребности и слабые технологические стороны бизнеса • Бюллетени угроз и новостные ленты • Фантазия в стиле «а если…» • Пентесты • Уязвимости и угрозы которые нельзя устранить, но можно контролировать • Подход «хочу видеть как, что и где»
  8. 8. Различие кейсов, симптомов и сценариев Use case • Контроль привилегированных пользователей • Массовое удаление файлов • Использование чужих учетных записей • НСД к почтовым ящикам на почтовом сервере Сценарии • Вход с ip под УЗ с которого ранее не было подключения • Удаление более 500 файлов за минуту под УЗ увольняемого сотрудника • Вход на сервер и использование ранее открытой консоли управления в другом сеансе Симптомы • Удаление файлов • Интерактивный вход • Подключение к почтовому ящику • Установка опции копирования почты в другой ящик
  9. 9. Что на выходе кейса? • Инцидент, зафиксированный в SIEM с уведомлением • Правило аналитики и инцидент с уведомлением • Проактивная команда с принимаемым на вход массивом переменных (например, блокируемых ip) • Порожденное событие/snmp trap/уведомление • Регламент реагирования на инцидент Если нет необходимости в незамедлительном уведомлении: • Сохраненный запрос для быстрой выборки • Отчет • Виджеты дашборда • Статистические данные
  10. 10. Залог успешных use-cases • Вариант 1. Мы понимаем что конкретно хотим контролировать/знать об этом/предотвращать. • Нам необходимо: • Понимать вектора реализации наших угроз • Эмулировать кейс, выделить идентифицирующие события для этой угрозы • Понять что об этом факте генерируется одно, множество (различных) или последовательность событий • Если нет событий – возможно включить аудит или повысить уровень детализации или использовать другое СЗИ • Понять с помощью каких источников сможем достоверно определять, подключить их при необходимости • Написать правило корреляции/аналитики/статистики для данной угрозы или вынести идентификаторы на дашборд/в сохраненный запрос/отчет.
  11. 11. • Вариант 2. Необходима помощь и сторонняя оценка • Необходимо: • Провести независимый пентест (экспертизу) • Обратиться к интегратору или вендору Залог успешных use-cases
  12. 12. • Вариант 3. Мы мало знаем о нашей инфраструктуре и процессах • Необходимо: • Подключайте источники. Можно даже наобум. • Смотрите события и информативность источников • Меньше правил корреляции с оповещениями если вы не уверены. Больше дашбордов и уточняющих сохраненных запросов. Изучайте. • Попробуйте взглянуть глазами злоумышленника – какие вектора и сценарии есть для того чтобы: • Вывести приложение/БД/ОС из строя (а также симптомы-предвестники программно- аппаратных сбоев не по вине атак) • Повысить привилегии для доступа к данным • Удалить/скопировать/несанкционированно изменить данные • Инфицировать систему Залог успешных use-cases
  13. 13. «Обладать информацией – быть богом» • Логируйте кто/что/куда/когда/как/откуда. Возможно, это спасет не только вашу карьеру но и бизнес. • Держите руку на пульсе. Сценарий/правило/сигнатура в лучшем случае придет через сутки-трое. Возможно вам написать обнаружение угрозы будет намного быстрее. • Сконцентрируйтесь на главном. Представьте что SIEM не «еще один» инструмент, а ваша единственная приборная панель. Причем достаточно гибкая. Все что вы хотели бы увидеть – можно осуществить! • Всегда! Всегда! Проверяйте кейсы и сценарии, даже если это прислал вендор/интегратор. Язык ОС/продукта, версия, настройки логирования могут отличаться. В итоге вы будете словно в пустыне ждать волны с серфинговой доской. • Чаще PDCA! Приглашайте сторонних аудиторов, устраивайте своими силами проверки кейсов, выявляйте новые вектора и пишите детектирующие правила.
  14. 14. Простые примеры • Пример 1. Нам необходимо контролировать изменение пары ip-mac. Цель - событие в SIEM/отчет/инцидент/уведомление. • Технической возможности в SIEM (к примеру) нет. • Вариант 1: использовать стороннее приложение, способное предоставлять такие события об изменении. • Вариант 2: использовать arpwatch внутри сегментов (или с arp-proxy если сеть небольшая). • Вариант 3: использовать скрипт в доменных групповых политиках с передачей в локальный евент-лог с последующим сбором. • Вариант 4: если имеется DPI/Flow-like сетевой сенсор - подключить его. • Вариант 5: Обратиться к вендору/интегратору с FR для реализации кейса.
  15. 15. Простые примеры • Пример 2. Нам необходимо знать об устаревших и незаблокированных учетных записях. • Технической возможности в SIEM (к примеру) нет. События на источнике об этом не генерируются, так как учетная запись не используется. • Вариант 1: использовать стороннее приложение/скрипт, способное получить необходимый параметр с отправкой на SIEM. • Вариант 2: использовать сканер и интеграцию с SIEM
  16. 16. Простые примеры • Пример 3. Нам необходимо знать об устаревших, не валидных и самоподписанных сертификатах, используемых на веб-серверах в нашей компании. • Вариант 1: использовать сетевой сенсор в SPAN режиме с возможностью разбора протокола, извлечения сертификата с отправкой на SIEM. • Вариант 2: использовать сканер и интеграцию с SIEM
  17. 17. Простые примеры • Пример 4. Контроль запускаемых исполняемых файлов вне системных директорий ОС. • Вариант 1: Включить аудит в групповых политиках, либо использовать auditd для linux серверов. • Вариант 2: Использовать агент RuSIEM или стороннее ПО для контроля процессов. • Вариант 3: Использовать антивирусное ПО на Windows серверах и рабочих станциях (если оно установлено) с возможностью снятия дампа по процессам.
  18. 18. Простые примеры • Пример 5. Контроль областей автозапуска в ОС. • Вариант 1: Включить аудит в групповых политиках, либо использовать auditd для linux серверов. • Вариант 2: Использовать сторонее ПО, интеграцию с аудитными сканерами.
  19. 19. Простые примеры • Пример 6. Контроль несанкционированного подключения к чужим почтовым ящикам MS Exchange. • Вариант 1: Воспользоваться уже имеющейся базой знаний в SIEM системах. Сэмулировать кейс подключившись различными способами, проверить детектирование. Проверить детектирование на установку опции копирования на другой почтовый ящик. • Вариант 2: Написать самим правило корреляции, отчеты для данного кейса, либо обратиться за помощью к вендору или интегратору.
  20. 20. Фидбэк для вендора • Большая часть кейсов могут быть индивидуальны и применимы только для вашей компании и только для ваших систем. • Не ленитесь описать ваш кейс и отправить вендору. Скорее всего, кейс будет расширен и будут обновлены возможности продукта. Или с помощью экспертного мнения – в продукт будет добавлены еще правила обнаружения, которые помогут в дальнейшем Вам!
  21. 21. Спасибо за внимание Олеся Шелестова CEO RuSIEM https://rusiem.com

×