.

1. Олеся Шелестова
CEO RuSIEM
oshelestova@rusiem.com
RuSIEM vs рынок
Рынок. Состав продукта.
Механизмы. Возможности.

2. Что такое SIEM
• Программный продукт, ядро. Готовый к использованию
• На входе – события с ОС, сетевого оборудования, различного
программного обеспечения, средств защиты, приложений
• На выходе – комплексные обоснованные выводы о том что
происходит: статистика, оповещения об аномалиях, сбоях, утечке
данных, попытках НСД, быстро распространяющихся вирусных
эпидемиях, подозрительных транзакциях и много чем еще.
3

3. Рынок
4

5. Основные игроки
• IBM Qradar
• HP ArcSight
• LogRhythm
• SolarWinds
• RSA Envision
• McAfee
• Tenable
• AlienVault OSSIM
• Splunk (LM)
6

6. Игроки на рынке РФ
Разработчики:
• RuSIEM
• PT SIEM
• «НПО Эшелон Комрад» (OSSIM)
7

7. Игроки на рынке РФ
8
Продаются:
• IBM Qradar
• HP ArcSight
• Splunk
• RSA EnVision
• OSSIM
• McAfee
• Tenable

8. Форм-фактор
9
• Hardware appliance
• Virtual Appliance

9. Типовой состав
10
• Агент
• Коллектор (like LM)
• Ядро (парсеры/корреляторы/отчеты/аналитика)
• Хранилище
• Консоль управления

10. «Потребители»
• Банки/процессинг/Финансовые организации – как минимум для
PCI DSS, SOX, ISO27**, СТО БР ИББС
• Коммерческие/Государственные организации/Телекомм –
осознав необходимость в быстрой реакции на инциденты
• Финансовые/нефте-газовые – для выявления фрода и
мошеннических действий
• SOC/Security monitoring
• Сервис-провайдеры/MSSP
11

11. «Пользователи» (преимущественно)
• ИТ подразделение
• ИБ подразделения
• Экономическая безопасность
• Физическая безопасность
12

12. Для чего используется
(на практике)
13

13. • Standard compliance (SOX, PCI DSS, ISO 27**, BASEL II, HIPAA, СТО БР
ИББС ….)
• «Быстро узнавать что происходит что то плохое». Инфраструктура,
транзакции, доступ к данным, изменение конфигураций,
злонамеренные действия, СКУД, видеонаблюдение, физическая
безопасность и т.п.
• «Мозг» для автоматического обнаружения инцидентов и
сопутствующих факторов. Предупреждения о назревающем
инциденте.
• База и инструментарий для расследования, анализа происходящего
или случившегося.
• Регистрация фактов инцидентов. Фиксация решений.
• «Источник состояний». К примеру – DDOS/действия
пользователей/целостность приложения в сравнении с транзакциями.
14

14. Процессы «внутри»
15

15. 16
Data
extraction
Symptoms
Correlations
LOT
Database
Agent
Apps
WebSecurity
logs
Transaction
Aggregations
Asset
profiler
Asset
Modeling
Real-time Executions
Asset
Modeling
Feeds
Threat
modelling
Policy
compliance
Vulnerability
detection
Workflow
Relationship
detection
Broker
Log-source
management
API
Meta
addition
Connectors
Knowledge
Update
Log source recognition
Fast data Time-seriesRaw dataAnalytics Metadata History
correlations

16. Нормализация Корреляция
Обогащение Аналитика
Экстракторы
Историческая
корреляция
Активный
сбор
Пассивный
сбор

17. RuSIEM vs Конкуренты
18

18. С одной стороны…
• SIEMов много
• Есть устоявшиеся игроки занявшие рынок
• Пересекающийся и повторяющийся набор функциональности
• Есть конструкторы из которых можно «городить» почти все что
угодно
• Множество провальных проектов внедрения
• «Из коробки» работает плохо
19

19. С Другой стороны…
• «Дальше носа» никто не смотрит
• Более 87% вендоров не развивают продукт заняв рыночную нишу
• Конструкторы позволяют «городить» но все также из «ПВА» и
веток. Вашими силами и вашим бюджетом.
• Разные SIEMы как костюмы – один в рукавах узок, другой
болтается
• И да, «Санкции». И с ними столкнулись наши Заказчики.
20

20. Мы постарались и стараемся дальше:
• Взяли востребованный набор кейсов и необходимой
функциональности
• Принимаем фидбэк: что удобно, что нет. Прислушиваемся и
упрощаем вашу работу, повышаем удобство.
• Мы сделали «фундамент» продукта. Для того чтобы двигаться
дальше и решать действительно полезные и интересные кейсы.
• RuSIEM это не банальный siem, а следующий шаг к продвинутой
аналитике, к автоматическому анализу, построению моделей,
обнаружению угроз без сигнатурными методами
21

21. LM: сбор и подготовка данных

22. Важно понимать что RuSIEM ©:
• не «интеграторская версия», а полноценный самостоятельный
продукт
• не open-source! Это свой код, исключая разве что БД
используемые в продукте
• релиз уже состоялся. Мы вышли на рынок. Пилотируемся,
внедряемся и продаем решение.
23

23. Механизмы обнаружения угроз
24

24. Предвестники инцидента
• Появление события(й) по паттерну, с определенным id или классом
• Последовательность событий по паттерну/категориям
• Всплески/рост количества событий по сравнению с историческими
(общее или определенного типа)
• Объект ранее не используемый (dst.ip/url/fqdn)
• Аномалия или последовательность классов аномалий (не соответствие
профилю трафика, флаги, пропущенные данные, мисматчинг)
• Маркированные данные или по паттерн-матчингу (фиды, useragents,
версии протоколов)
25

25. Декомпозиция угроз
26
Обнаружение
События
Траффик
Косвенные
признаки
Аналитические
методы

26. «Говорящие» источники
• Определяются в рамках применимых векторов атак
• Основные:
• События аутентификации/авторизации, получения привилегий, изменения
конфигураций (windows event log, syslog, AA, DB logs, etc)
• Доступ к ресурсам (web servers, proxy)
• Сетевые соединения (сенсор либо имеющееся)
• Mail logs (transport + access + management)
• Md5/sha1 file checksum (network + processes)
• AV-centers
• File extractors
• L7 analyzers
• DPI/Protocol analyzers
• IDS/IPS/Fw’s
• Audit VM scans
• Feeds
27

27. Методы обнаружения угроз
28
Up to
2min
Up to
3min
Correlation
Rules
Dashboard
Active
searches
Feeds,
Reputation
lists
Basic
symptoms
Symptoms
aggregations
Data Analytics (in
development)
time
completenessofthethreatassessment
Historical
trends

28. Инструментарий и методы обнаружения
• Корреляция счетчиком (по условию события, количеству событий,
последовательность событий)
• «Всплески», тенденции
• Историческая аналитика
• Сигнатурный анализ
• «Песочницы» (сравнение по хэшам, отправка подозрительных файлов и получение
результатов в облаке)
• Корреляция триггером (триггерное, например: 3 неуспешных попытки входа, затем
успешная)
• Симптоматика или критичность событий
• Агрегация (суммарные веса объектов симптомов за интервалы)
• Фиды (репутационные списки)
• «Беглый просмотр событий»
29

29. Корреляция
• Предзаданные пакеты (наборы) правил
• Пользовательские (адаптированные)
30

30. Корреляция
• Одно событие по условию как триггер
• Количество событий по условию за единицу времени
• Последовательная цепочка событий
31

31. Корреляция
• Фильтр по времени
• Функции (запрос к дата-сетам, подсчеты, отправка в песочницу)
• Группировка
• Составное условие
• Последовательное условие
• Запуск скрипта с передачей параметра
• Генерация инцидента
• Параметры оповещения
• Группы определения/симптоматика
32

32. Корреляция. Жизненный цикл правила
• Зависит от условия и применимости к гетерогенным продуктам
• В среднем, от 3х месяцев до 5 лет
• Комплексное на симптомах – 8-10 лет
• Система не обновляемая и не поддерживаемая станет
не_эффективной через год-полтора
• В составе с аналитиком даже без обновлений вендора – «5 лет
не срок».
33

33. Кто делает правила корреляции
• Вендор
• Интеграторы
• Аналитики заказчика
34

34. Отладка и создание правил корреляции
• Исходя из кейсов
• Исходя из угроз
• Обязательно тестируется на реальных данных (эмуляция)
• Идеальный случай – проведение пентестов не дожидаясь реальных
инцидентов и актуализация правил по результатам
• Описывать «коня в вакууме» нельзя! Это будет пустая трата времени.
• Эмулируется ситуация/последовательность действий Смотрятся
логиОписывается правило корреляции. При недостаточности данных
– думаем откуда и как их собрать.
35

35. На выходе корреляции
• Инцидент, назначенный на пользователя/группу во встроенном
workflow или внешней системе ServiceDesk
• Сгруппированный дата-сет для повторного использования в
корреляции
• Совсем плохо если только событие или алерт в виде события
36

36. Инцидент-менеджмент
• Фиксация инцидентов для руководства/аудиторов
• Фиксация инцидентов для взаимодействия с другими
подразделениями и сотрудниками
• Группировка типовых повторяющихся инцидентов в проблему (см.ITIL)
• Фиксация инцидентов для формирования базы знаний и выдаче
советов в случае повторного появления инцидентов
• Инциденты должны быть сгруппированы по объекту (src.ip/user.name)
• Склейка инцидентов происходит по предзаданным правилам
• Сроки решения инцидента должны быть выставлены и выдержаны.
Уведомления о просрочке решения – руководителям.
37

37. Хранение
38
• Хранить «все» ради standard compliance – не обязательно
• Актуальное хранение: 7-30 дней все события, до полугода
важные, до 3х лет для compliance по категориям.
• Инциденты – до 3х лет.

38. Интеграция с внешними системами
• Входной поток событий – syslog/CEF c /n разделителями
• Входной поток – коннекторы
• Импорт – api/коннекторы агента
• Экспорт данных – syslog/CEF/csv/api
39

39. Кто пишет нормализацию?
• Вендор
• Интеграторы
• Аналитики заказчика
• «Транспорты» - фактически только вендор.
• Нормализация - это просто. Достаточно «набить руку».
40

40. Как собираются «состояния и события»
• White box
• Windows Event logs
• Syslog
• Snmp
• Wmi
• Rcommand (rexec, ssh, sql-like, php, post/get, etc)
• Scan (audit mode, authorized)
• …
• Black box
• Network traffic
• Scan (remote unauthorized, pentest)
• Information from its neighbors
• …
41

41. Пример «Black box»
Задачи:
- Аудит доступа к SQL-like БД
- Аудит передаваемых данных
Анализ:
- Включение аудита грузит сильно БД и не информативно
- Фронт-энд/бэк-энд/клиент не может логировать необходимые данные
или нет возможности
Выход:
- Установка в span/tap порт и сбор необходимых данных по трафику
- Разбор событий на RuSIEM
42

42. Почему встречаются провальные проекты
43

43. Почему встречаются провальные проекты
• Не выстроены процессы
• Не закреплено аналитика на SIEM
• Не хватает квалификации
• Не событиями едиными: нужен мониторинг траффика
• Источники подключаются «тыканьем пальца», а не от кейсов
• Не хватает экспертной оценки для ведения процессов системы
(правила корреляции, минимизация ложных срабатываний и т.д.)
• Система должна работать не только через сигнатуры и глаза аналитика
• Вендор должен совершенствовать систему под новые условия
• Некорректный расчет ресурсов
44

44. Контактная информация:
Вопросы: support@rusiem.com
Заказы на пилот: info@it-task.ru
Олеся Шелестова oshelestova@rusiem.com (skype, mail)
Официальный дистрибьютор:
СПАСИБО ЗА ВНИМАНИЕ
Остались вопросы? Обращайтесь!
45
105082, Россия, г. Москва
ул. Большая Почтовая, 55/59с1
Телефон: +7 (495) 972-98-26
E-mail: info@it-task.ru