RuSIEM. Потребители. Состав продукта. Отличия. Применение

Олеся ШелестоваCEO RuSIEMoshelestova@rusiem.com

RuSIEM vs рынокРынок. Состав продукта.

Механизмы. Возможности.

2

Что такое SIEM

• Программный продукт, ядро. Готовый к использованию• На входе – события с ОС, сетевого оборудования, различного

программного обеспечения, средств защиты, приложений• На выходе – комплексные обоснованные выводы о том что

происходит: статистика, оповещения об аномалиях, сбоях, утечке данных, попытках НСД, быстро распространяющихся вирусных эпидемиях, подозрительных транзакциях и много чем еще.

3

Рынок

5

Основные игроки

• IBM Qradar• HP ArcSight• LogRhythm• SolarWinds• RSA Envision• McAfee• Tenable• AlienVault OSSIM• Splunk (LM)

6

Игроки на рынке РФ

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

7

Игроки на рынке РФ

Продаются:• IBM Qradar• HP ArcSight• Splunk• RSA EnVision• OSSIM• McAfee• Tenable

8

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

9

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

10

«Потребители»• Банки/процессинг/Финансовые организации – как минимум для

PCI DSS, SOX, ISO27**, СТО БР ИББС• Коммерческие/Государственные организации/Телекомм –

осознав необходимость в быстрой реакции на инциденты• Финансовые/нефте-газовые – для выявления фрода и

мошеннических действий• SOC/Security monitoring• Сервис-провайдеры/MSSP

11

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

12

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

13

• Standard compliance (SOX, PCI DSS, ISO 27**, BASEL II, HIPAA, СТО БР ИББС ….)• «Быстро узнавать что происходит что то плохое». Инфраструктура,

транзакции, доступ к данным, изменение конфигураций, злонамеренные действия, СКУД, видеонаблюдение, физическая безопасность и т.п.• «Мозг» для автоматического обнаружения инцидентов и сопутствующих

факторов. Предупреждения о назревающем инциденте.• База и инструментарий для расследования, анализа происходящего или

случившегося.• Регистрация фактов инцидентов. Фиксация решений.• «Источник состояний». К примеру – DDOS/действия

пользователей/целостность приложения в сравнении с транзакциями.

14

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

15

Dataextraction Symptoms

Correlations

LOT

Database

Agent

Apps

WebSecuritylogs

Transaction

Aggregations

Assetprofiler

AssetModeling

Real-time Executions

AssetModeling

Feeds

Threatmodelling

Policycompliance

Vulnerabilitydetection

Workflow

Relationshipdetection

Broker

Log-sourcemanagement

API

Metaaddition

Connectors

Knowledge Update

Log source recognition

Fast data Time-seriesRaw dataAnalytics Metadata Historycorrelations

Нормализация Корреляция

Обогащение Аналитика

Экстракторы Историческаякорреляция

Активный сбор

Пассивный сбор

17

RuSIEM vs Конкуренты

18

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

угодно• Множество провальных проектов внедрения• «Из коробки» работает плохо

19

С Другой стороны…• «Дальше носа» никто не смотрит• Более 87% вендоров не развивают продукт заняв рыночную нишу• Конструкторы позволяют «городить» но все также из «ПВА» и

веток. Вашими силами и вашим бюджетом.• Разные SIEMы как костюмы – один в рукавах узок, другой

болтается• И да, «Санкции». И с ними столкнулись наши Заказчики.

20

Мы постарались и стараемся дальше:• Взяли востребованный набор кейсов и необходимой

функциональности• Принимаем фидбэк: что удобно, что нет. Прислушиваемся и

упрощаем вашу работу, повышаем удобство.• Мы сделали «фундамент» продукта. Для того чтобы двигаться

дальше и решать действительно полезные и интересные кейсы.• RuSIEM это не банальный siem, а следующий шаг к продвинутой

аналитике, к автоматическому анализу, построению моделей, обнаружению угроз без сигнатурными методами

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

Симптоматика (RuSIEM) ©: обогащение и приоритезация

SIEM: Rule Based Reasoning Correlation

SIEM: Форенсика и инцидент-менеджмент

RuSIEM: Аналитика

RuSIEM: Continous monitoring and assesment

RuSIEM: Оценка влияния угроз на бизнес-процессы

22

Важно понимать что RuSIEM ©:

• не «интеграторская версия», а полноценный самостоятельный

продукт

• не open-source! Это свой код, исключая разве что БД

используемые в продукте

• релиз уже состоялся. Мы вышли на рынок. Пилотируемся,

внедряемся и продаем решение.

23

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

24

Предвестники инцидента• Появление события(й) по паттерну, с определенным id или классом• Последовательность событий по паттерну/категориям• Всплески/рост количества событий по сравнению с историческими

(общее или определенного типа)• Объект ранее не используемый (dst.ip/url/fqdn)• Аномалия или последовательность классов аномалий (не

соответствие профилю трафика, флаги, пропущенные данные, мисматчинг)• Маркированные данные или по паттерн-матчингу (фиды, useragents,

версии протоколов)

Декомпозиция угроз

25

Обнаружение

События

Траффик

Косвенныепризнаки

Аналитические методы

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

Методы обнаружения угроз

Up to 2min

Up to 3min

Correlation Rules

Dashboard

Active searches

Feeds,Reputation

lists

Basicsymptoms

Symptomsaggregations

Data Analytics (in development)

time

com

plet

enes

s of t

he th

reat

ass

essm

ent

Historical trends

28

Инструментарий и методы обнаружения• Корреляция счетчиком (по условию события, количеству событий, последовательность

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

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

29

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

30

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

31

Корреляция

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

32

Корреляция. Жизненный цикл правила

• Зависит от условия и применимости к гетерогенным продуктам• В среднем, от 3х месяцев до 5 лет• Комплексное на симптомах – 8-10 лет

• Система не обновляемая и не поддерживаемая станет не_эффективной через год-полтора• В составе с аналитиком даже без обновлений вендора – «5 лет

не срок».

33

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

34

Отладка и создание правил корреляции• Исходя из кейсов• Исходя из угроз• Обязательно тестируется на реальных данных (эмуляция)• Идеальный случай – проведение пентестов не дожидаясь реальных

инцидентов и актуализация правил по результатам• Описывать «коня в вакууме» нельзя! Это будет пустая трата времени.

• Эмулируется ситуация/последовательность действий Смотрятся логиОписывается правило корреляции. При недостаточности данных – думаем откуда и как их собрать.

35

На выходе корреляции• Инцидент, назначенный на пользователя/группу во встроенном

workflow или внешней системе ServiceDesk• Сгруппированный дата-сет для повторного использования в

корреляции• Совсем плохо если только событие или алерт в виде события

36

Инцидент-менеджмент• Фиксация инцидентов для руководства/аудиторов• Фиксация инцидентов для взаимодействия с другими подразделениями

и сотрудниками• Группировка типовых повторяющихся инцидентов в проблему (см.ITIL)• Фиксация инцидентов для формирования базы знаний и выдаче советов

в случае повторного появления инцидентов• Инциденты должны быть сгруппированы по объекту (src.ip/user.name)• Склейка инцидентов происходит по предзаданным правилам• Сроки решения инцидента должны быть выставлены и выдержаны.

Уведомления о просрочке решения – руководителям.

37

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

важные, до 3х лет для compliance по категориям.• Инциденты – до 3х лет.

38

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

• Экспорт данных – syslog/CEF/csv/api

39

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

• Нормализация - это просто. Достаточно «набить руку».

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

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

нет возможностиВыход:- Установка в span/tap порт и сбор необходимых данных по трафику- Разбор событий на RuSIEM

РЕАЛИЗОВАНО В

RuSIEM

42

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

43

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

корреляции, минимизация ложных срабатываний и т.д.)• Система должна работать не только через сигнатуры и глаза аналитика• Вендор должен совершенствовать систему под новые условия• Некорректный расчет ресурсов

44

Контактная информация:Вопросы: support@rusiem.comЗаказы на пилот: info@it-task.ru Олеся Шелестова oshelestova@rusiem.com (skype, mail)

Официальный дистрибьютор:

СПАСИБО ЗА ВНИМАНИЕОстались вопросы? Обращайтесь!

105082, Россия, г. Москваул. Большая Почтовая, 55/59с1Телефон: +7 (495) 972-98-26E-mail: info@it-task.ru