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