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 системах

836 views

Published on

Security Information and Event Management
Презентация с Skolkovo Security Day (8/12/2016)

Published in: Technology
  • Be the first to comment

Корреляция в SIEM системах

  1. 1. СОЗДАНИЕ ПРАВИЛ КОРРЕЛЯЦИИ В SIEM СИСТЕМАХ SKOLKOVO CYBERDAY CONFERENCE, 8/12/2016 OLESYA SHELESTOVA, CEO RUSIEM
  2. 2. SIEM/LM • SIEM (Security information and event management) — Система управления информацией и событиями. Технология SIEM обеспечивает сохранение событий для расследования инцидентов и анализ в реальном времени событий операционных систем, сетевых устройств и приложений, баз данных, различных датчиков и сетевого траффика. • LM (Log management) — Система сбора событий с целью обеспечения целостности журналов для последующего разбора инцидентов и обеспечения доказательной базы.
  3. 3. ЗАЧЕМ НЕОБХОДИМА КОРРЕЛЯЦИЯ • Очень много индикаторов и угроз • Миллионы разрозненных событий за день • Невозможно увидеть «глазом» • Автоматическое обнаружение в режиме реального времени • Фиксация инцидента и его параметров • Своевременное обнаружение • Превентивность
  4. 4. РАЗДЕЛЕНИЕ ПО ПРИНЦИПУ • Real-time • Near real-time • Historical • Analytics • Algorithm
  5. 5. ДАННЫЕ ДЛЯ КОРРЕЛЯЦИИ • SIEM = событийная система • Для обнаружения используются события/факты • Факт = нечто в событии или полученные ранее данные
  6. 6. ИСТОЧНИКИ ДАННЫХ • IDS/IPS/Routers/Firewalls • LDAP • Database • Web apps • SPAN: Flow/network capture/protocol decode/app detection • Event log/syslog with audit enabled • Audit scanners • Vulnerability management
  7. 7. • Появление определенного события по условию(ям) [event][id] == "4625" and ( [status][code] == "0xC000006A" )
  8. 8. • По количеству событий Count >= 10 in 30 min [event][id] == "4625" and ( [status][code] == "0xC000006A" )
  9. 9. • Последовательность событий Count >= 10 in 30 min [event][id] == "4625" and ( [status][code] == "0xC000006A" ) ( ( [event][id] == "4624" and [user][name] !~ /[w._-]+[$]+$/ ) and [logon][type] =~ /2|9|7|10/ Followed by
  10. 10. • С проверкой по ассетам/уязвимостям/номеру AS и т.п. ( [symptoms][category] == «Атаки на веб приложения» ) and [asset][port][state] == “open"
  11. 11. GROUP BY Case: 1000 неверных попыток входа под 10 пользователями с 20 хостов 1000 инцидентов? 20 инцидентов? 10 инцидентов? 1 инцидент?
  12. 12. GROUP BY Case: 1000 неверных попыток входа под 10 пользователями с 20 хостов 1000 инцидентов – группировка по факту «неуспешный вход» 20 инцидентов – по хосту-источнику 10 инцидентов – по имени пользователя 1 инцидент – по хосту-назначению/комплексу условий
  13. 13. КАК БУДЕМ ОТСЛЕЖИВАТЬ ИНЦИДЕНТЫ • Отслеживать по почте/push-уведомлениям • Встроенный/внешний инцидент-менеджмент по ITIL • В среднем, от 5 до 15 инцидентов в сутки. Иначе – проблема. • В уведомлениях по почте – о постановке задач/инцидентах с минимум достаточной информации • 1-3 линия поддержки • Обязательна градация инцидентов по критичности • Сроки инцидентов, эскалация, групповое назначение и задачи • Просрочки и повторные уведомления
  14. 14. ДОПОЛНИТЕЛЬНЫЕ ИНСТРУМЕНТЫ • Настроенные дашборды со статистическими данными • Настроенные представления (search query) • Отчеты • Аналитика
  15. 15. ИСКЛЮЧЕНИЯ И ЛОЖНЫЕ СРАБАТЫВАНИЯ • Опишите правило • Напишите стандартные исключения через AND NOT (….) • Эмулируйте кейс чтобы инцидент отработал • Если есть у системы возможность – проверьте на исторических данных • Всегда проверяйте отработку правила корреляции на реальной эмуляции
  16. 16. КАК ПРАВИЛЬНО ПОДХОДИТЬ К ПРАВИЛАМ • Threat exchange • White/black behavior list • Hack this • Incident response • Incident history
  17. 17. ОТКУДА БРАТЬ КЕЙСЫ • Векторы атак исходя из реальных пентестов • Входы на консоли управления • Изменения конфигураций • Управление учетными записями, группами и привилегиями • Массовые операции • Нестандартные размещения • Зоны с которых производится подключение • Оценка типовых конфигураций • Учет «это уже было» • Репутационные метрики • Риск метрики • Standard/Policy compliance
  18. 18. СПАСИБО ЗА ВНИМАНИЕ Шелестова Олеся CEO RuSIEM oshelestova@rusiem.com

×