Корреляция в siem системах
TRANSCRIPT
СОЗДАНИЕ ПРАВИЛ КОРРЕЛЯЦИИ В SIEM СИСТЕМАХ
SKOLKOVO CYBERDAY CONFERENCE, 8/12/2016OLESYA SHELESTOVA, CEO RUSIEM
SIEM/LM• SIEM (Security information and event management) —
Система управления информацией и событиями. Технология SIEM обеспечивает сохранение событий для расследования инцидентов и анализ в реальном времени событий операционных систем, сетевых устройств и приложений, баз данных, различных датчиков и сетевого траффика.• LM (Log management) — Система сбора событий с целью обеспечения целостности журналов для последующего разбора инцидентов и обеспечения доказательной базы.
ЗАЧЕМ НЕОБХОДИМА КОРРЕЛЯЦИЯ• Очень много индикаторов и угроз• Миллионы разрозненных событий за день• Невозможно увидеть «глазом»
• Автоматическое обнаружение в режиме реального времени• Фиксация инцидента и его параметров• Своевременное обнаружение• Превентивность
РАЗДЕЛЕНИЕ ПО ПРИНЦИПУ
• Real-time• Near real-time• Historical• Analytics• Algorithm
ДАННЫЕ ДЛЯ КОРРЕЛЯЦИИ
• SIEM = событийная система• Для обнаружения используются события/факты• Факт = нечто в событии или полученные ранее данные
ИСТОЧНИКИ ДАННЫХ
• 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
• Появление определенного события по условию(ям)
[event][id] == "4625" and ( [status][code] == "0xC000006A" )
• По количеству событийCount >= 10 in 30 min[event][id] == "4625" and ( [status][code] == "0xC000006A" )
• Последовательность событий
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
• С проверкой по ассетам/уязвимостям/номеру AS и т.п.
( [symptoms][category] == «Атаки на веб приложения» ) and[asset][port][state] == “open"
GROUP BY
Case: 1000 неверных попыток входа под 10 пользователями с 20 хостов
1000 инцидентов?20 инцидентов?10 инцидентов?1 инцидент?
GROUP BY
Case: 1000 неверных попыток входа под 10 пользователями с 20 хостов
1000 инцидентов – группировка по факту «неуспешный вход»
20 инцидентов – по хосту-источнику10 инцидентов – по имени пользователя1 инцидент – по хосту-назначению/комплексу условий
КАК БУДЕМ ОТСЛЕЖИВАТЬ ИНЦИДЕНТЫ• Отслеживать по почте/push-уведомлениям• Встроенный/внешний инцидент-менеджмент по ITIL• В среднем, от 5 до 15 инцидентов в сутки. Иначе – проблема.• В уведомлениях по почте – о постановке задач/инцидентах с минимум
достаточной информации• 1-3 линия поддержки• Обязательна градация инцидентов по критичности• Сроки инцидентов, эскалация, групповое назначение и задачи• Просрочки и повторные уведомления
ДОПОЛНИТЕЛЬНЫЕ ИНСТРУМЕНТЫ
• Настроенные дашборды со статистическими данными• Настроенные представления (search query)• Отчеты• Аналитика
ИСКЛЮЧЕНИЯ И ЛОЖНЫЕ СРАБАТЫВАНИЯ• Опишите правило• Напишите стандартные исключения через AND NOT (….)• Эмулируйте кейс чтобы инцидент отработал• Если есть у системы возможность – проверьте на
исторических данных• Всегда проверяйте отработку правила корреляции на
реальной эмуляции
КАК ПРАВИЛЬНО ПОДХОДИТЬ К ПРАВИЛАМ• Threat exchange• White/black behavior list• Hack this• Incident response• Incident history
ОТКУДА БРАТЬ КЕЙСЫ• Векторы атак исходя из реальных пентестов• Входы на консоли управления• Изменения конфигураций• Управление учетными записями, группами и привилегиями• Массовые операции• Нестандартные размещения• Зоны с которых производится подключение• Оценка типовых конфигураций• Учет «это уже было»• Репутационные метрики• Риск метрики• Standard/Policy compliance
