Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

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

•Download as PPTX, PDF•
•
Olesya Shelestova
Olesya Shelestova

.

Related slideshows

PT ESC - кто полечит доктора?
PT ESC - кто полечит доктора?PT ESC - кто полечит доктора?
PT ESC - кто полечит доктора?
 
Free RvSIEM. Intro (Rus)
Free RvSIEM. Intro (Rus)Free RvSIEM. Intro (Rus)
Free RvSIEM. Intro (Rus)
 
SOC в большой корпоративной сети. Challenge accepted
SOC в большой корпоративной сети. Challenge acceptedSOC в большой корпоративной сети. Challenge accepted
SOC в большой корпоративной сети. Challenge accepted
 
1 of 44
Олеся Шелестова CEO RuSIEM oshelestova@rusiem.com RuSIEM vs рынок Рынок. Состав продукта. Механизмы. Возможности.
Что такое SIEM • Программный продукт, ядро. Готовый к использованию • На входе – события с ОС, сетевого оборудования, различного программного обеспечения, средств защиты, приложений • На выходе – комплексные обоснованные выводы о том что происходит: статистика, оповещения об аномалиях, сбоях, утечке данных, попытках НСД, быстро распространяющихся вирусных эпидемиях, подозрительных транзакциях и много чем еще. 3
Рынок 4
RuSIEM. Потребители. Состав продукта. Отличия. Применение.
Основные игроки • IBM Qradar • HP ArcSight • LogRhythm • SolarWinds • RSA Envision • McAfee • Tenable • AlienVault OSSIM • Splunk (LM) 6
Игроки на рынке РФ Разработчики: • RuSIEM • PT SIEM • «НПО Эшелон Комрад» (OSSIM) 7
Игроки на рынке РФ 8 Продаются: • IBM Qradar • HP ArcSight • Splunk • RSA EnVision • OSSIM • McAfee • Tenable
Форм-фактор 9 • Hardware appliance • Virtual Appliance
Типовой состав 10 • Агент • Коллектор (like LM) • Ядро (парсеры/корреляторы/отчеты/аналитика) • Хранилище • Консоль управления
«Потребители» • Банки/процессинг/Финансовые организации – как минимум для PCI DSS, SOX, ISO27**, СТО БР ИББС • Коммерческие/Государственные организации/Телекомм – осознав необходимость в быстрой реакции на инциденты • Финансовые/нефте-газовые – для выявления фрода и мошеннических действий • SOC/Security monitoring • Сервис-провайдеры/MSSP 11
«Пользователи» (преимущественно) • ИТ подразделение • ИБ подразделения • Экономическая безопасность • Физическая безопасность 12
Для чего используется (на практике) 13
• Standard compliance (SOX, PCI DSS, ISO 27**, BASEL II, HIPAA, СТО БР ИББС ….) • «Быстро узнавать что происходит что то плохое». Инфраструктура, транзакции, доступ к данным, изменение конфигураций, злонамеренные действия, СКУД, видеонаблюдение, физическая безопасность и т.п. • «Мозг» для автоматического обнаружения инцидентов и сопутствующих факторов. Предупреждения о назревающем инциденте. • База и инструментарий для расследования, анализа происходящего или случившегося. • Регистрация фактов инцидентов. Фиксация решений. • «Источник состояний». К примеру – DDOS/действия пользователей/целостность приложения в сравнении с транзакциями. 14
Процессы «внутри» 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
Нормализация Корреляция Обогащение Аналитика Экстракторы Историческая корреляция Активный сбор Пассивный сбор
RuSIEM vs Конкуренты 18
С одной стороны… • SIEMов много • Есть устоявшиеся игроки занявшие рынок • Пересекающийся и повторяющийся набор функциональности • Есть конструкторы из которых можно «городить» почти все что угодно • Множество провальных проектов внедрения • «Из коробки» работает плохо 19
С Другой стороны… • «Дальше носа» никто не смотрит • Более 87% вендоров не развивают продукт заняв рыночную нишу • Конструкторы позволяют «городить» но все также из «ПВА» и веток. Вашими силами и вашим бюджетом. • Разные SIEMы как костюмы – один в рукавах узок, другой болтается • И да, «Санкции». И с ними столкнулись наши Заказчики. 20
Мы постарались и стараемся дальше: • Взяли востребованный набор кейсов и необходимой функциональности • Принимаем фидбэк: что удобно, что нет. Прислушиваемся и упрощаем вашу работу, повышаем удобство. • Мы сделали «фундамент» продукта. Для того чтобы двигаться дальше и решать действительно полезные и интересные кейсы. • RuSIEM это не банальный siem, а следующий шаг к продвинутой аналитике, к автоматическому анализу, построению моделей, обнаружению угроз без сигнатурными методами 21
LM: сбор и подготовка данных
Важно понимать что 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
Методы обнаружения угроз 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
Инструментарий и методы обнаружения • Корреляция счетчиком (по условию события, количеству событий, последовательность событий) • «Всплески», тенденции • Историческая аналитика • Сигнатурный анализ • «Песочницы» (сравнение по хэшам, отправка подозрительных файлов и получение результатов в облаке) • Корреляция триггером (триггерное, например: 3 неуспешных попытки входа, затем успешная) • Симптоматика или критичность событий • Агрегация (суммарные веса объектов симптомов за интервалы) • Фиды (репутационные списки) • «Беглый просмотр событий» 29
Корреляция • Предзаданные пакеты (наборы) правил • Пользовательские (адаптированные) 30
Корреляция • Одно событие по условию как триггер • Количество событий по условию за единицу времени • Последовательная цепочка событий 31
Корреляция • Фильтр по времени • Функции (запрос к дата-сетам, подсчеты, отправка в песочницу) • Группировка • Составное условие • Последовательное условие • Запуск скрипта с передачей параметра • Генерация инцидента • Параметры оповещения • Группы определения/симптоматика 32
Корреляция. Жизненный цикл правила • Зависит от условия и применимости к гетерогенным продуктам • В среднем, от 3х месяцев до 5 лет • Комплексное на симптомах – 8-10 лет • Система не обновляемая и не поддерживаемая станет не_эффективной через год-полтора • В составе с аналитиком даже без обновлений вендора – «5 лет не срок». 33
Кто делает правила корреляции • Вендор • Интеграторы • Аналитики заказчика 34
Отладка и создание правил корреляции • Исходя из кейсов • Исходя из угроз • Обязательно тестируется на реальных данных (эмуляция) • Идеальный случай – проведение пентестов не дожидаясь реальных инцидентов и актуализация правил по результатам • Описывать «коня в вакууме» нельзя! Это будет пустая трата времени. • Эмулируется ситуация/последовательность действий Смотрятся логиОписывается правило корреляции. При недостаточности данных – думаем откуда и как их собрать. 35
На выходе корреляции • Инцидент, назначенный на пользователя/группу во встроенном workflow или внешней системе ServiceDesk • Сгруппированный дата-сет для повторного использования в корреляции • Совсем плохо если только событие или алерт в виде события 36
Инцидент-менеджмент • Фиксация инцидентов для руководства/аудиторов • Фиксация инцидентов для взаимодействия с другими подразделениями и сотрудниками • Группировка типовых повторяющихся инцидентов в проблему (см.ITIL) • Фиксация инцидентов для формирования базы знаний и выдаче советов в случае повторного появления инцидентов • Инциденты должны быть сгруппированы по объекту (src.ip/user.name) • Склейка инцидентов происходит по предзаданным правилам • Сроки решения инцидента должны быть выставлены и выдержаны. Уведомления о просрочке решения – руководителям. 37
Хранение 38 • Хранить «все» ради standard compliance – не обязательно • Актуальное хранение: 7-30 дней все события, до полугода важные, до 3х лет для compliance по категориям. • Инциденты – до 3х лет.
Интеграция с внешними системами • Входной поток событий – 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 42
Почему встречаются провальные проекты 43
Почему встречаются провальные проекты • Не выстроены процессы • Не закреплено аналитика на SIEM • Не хватает квалификации • Не событиями едиными: нужен мониторинг траффика • Источники подключаются «тыканьем пальца», а не от кейсов • Не хватает экспертной оценки для ведения процессов системы (правила корреляции, минимизация ложных срабатываний и т.д.) • Система должна работать не только через сигнатуры и глаза аналитика • Вендор должен совершенствовать систему под новые условия • Некорректный расчет ресурсов 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

More Related Content

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

  • 1. Олеся Шелестова CEO RuSIEM oshelestova@rusiem.com RuSIEM vs рынок Рынок. Состав продукта. Механизмы. Возможности.
  • 2. Что такое SIEM • Программный продукт, ядро. Готовый к использованию • На входе – события с ОС, сетевого оборудования, различного программного обеспечения, средств защиты, приложений • На выходе – комплексные обоснованные выводы о том что происходит: статистика, оповещения об аномалиях, сбоях, утечке данных, попытках НСД, быстро распространяющихся вирусных эпидемиях, подозрительных транзакциях и много чем еще. 3
  • 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
  • 9. Типовой состав 10 • Агент • Коллектор (like LM) • Ядро (парсеры/корреляторы/отчеты/аналитика) • Хранилище • Консоль управления
  • 10. «Потребители» • Банки/процессинг/Финансовые организации – как минимум для PCI DSS, SOX, ISO27**, СТО БР ИББС • Коммерческие/Государственные организации/Телекомм – осознав необходимость в быстрой реакции на инциденты • Финансовые/нефте-газовые – для выявления фрода и мошеннических действий • SOC/Security monitoring • Сервис-провайдеры/MSSP 11
  • 11. «Пользователи» (преимущественно) • ИТ подразделение • ИБ подразделения • Экономическая безопасность • Физическая безопасность 12
  • 13. • Standard compliance (SOX, PCI DSS, ISO 27**, BASEL II, HIPAA, СТО БР ИББС ….) • «Быстро узнавать что происходит что то плохое». Инфраструктура, транзакции, доступ к данным, изменение конфигураций, злонамеренные действия, СКУД, видеонаблюдение, физическая безопасность и т.п. • «Мозг» для автоматического обнаружения инцидентов и сопутствующих факторов. Предупреждения о назревающем инциденте. • База и инструментарий для расследования, анализа происходящего или случившегося. • Регистрация фактов инцидентов. Фиксация решений. • «Источник состояний». К примеру – DDOS/действия пользователей/целостность приложения в сравнении с транзакциями. 14
  • 18. С одной стороны… • SIEMов много • Есть устоявшиеся игроки занявшие рынок • Пересекающийся и повторяющийся набор функциональности • Есть конструкторы из которых можно «городить» почти все что угодно • Множество провальных проектов внедрения • «Из коробки» работает плохо 19
  • 19. С Другой стороны… • «Дальше носа» никто не смотрит • Более 87% вендоров не развивают продукт заняв рыночную нишу • Конструкторы позволяют «городить» но все также из «ПВА» и веток. Вашими силами и вашим бюджетом. • Разные SIEMы как костюмы – один в рукавах узок, другой болтается • И да, «Санкции». И с ними столкнулись наши Заказчики. 20
  • 20. Мы постарались и стараемся дальше: • Взяли востребованный набор кейсов и необходимой функциональности • Принимаем фидбэк: что удобно, что нет. Прислушиваемся и упрощаем вашу работу, повышаем удобство. • Мы сделали «фундамент» продукта. Для того чтобы двигаться дальше и решать действительно полезные и интересные кейсы. • RuSIEM это не банальный siem, а следующий шаг к продвинутой аналитике, к автоматическому анализу, построению моделей, обнаружению угроз без сигнатурными методами 21
  • 21. LM: сбор и подготовка данных
  • 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
  • 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
  • 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