Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

RuSIEM

2,949 views

Published on

SIEM

Published in: Data & Analytics

RuSIEM

  1. 1. 2
  2. 2. Что такое SIEM SIEM – Security Information and Event Management • Собирает события с различных систем (операционные системы, средства защиты, бизнес-системы, базы данных, сетевая среда) • Приводит к общему формату для дальнейшей обработки • Анализирует разнородные данные и выявляет отклонения, нарушения, аномалии, выявляет угрозы на основе сигнатур, алгоритмов, математических методов и моделей • Фиксирует инцидент, чтобы он не остался незамеченным, скрытым • Уменьшает время реагирования на возникающие инциденты • *Предотвращает инциденты 3
  3. 3. Что такое SIEM SIEM это не панацея, это не замена AV/IPS/IDS/DLP/DPI! • SIEM – аггрегатор информации от различных источников • Получаемые данные слишком разнородны, поэтому приводятся к одному виду • Данные от источников как «сплетни». Поэтому они проверяются по нескольким факторам • Это «думалка», визуализация для полученной информации и быстрые поисковые механизмы • Кроме всего – это защищенное хранилище в котором факты о случившемся не будут удалены даже администратором. 4
  4. 4. Инциденты • Сетевые атаки • Вирусные эпидемии • Отключение средств защиты • Злонамеренные действия • Несанкционированный доступ • Использование служебного положения • Отказ в обслуживании • Сбои в работе • Аномалии и всплески • *Мошеннические действия • Несоответствие требованиям Законодательства и регуляторов 5
  5. 5. «Сопутствующие» варианты применения • Расследование инцидентов • Снижение числа ложных срабатываний от СЗИ • Антифрод • Инвентаризация активов • Обнаружение сбоев в работе ИТ инфраструктуры • *Прогнозирование инцидентов ИТ и ИБ • *Прогнозирование состояний активов 6
  6. 6. Зачем SIEM • Из за большого количества источников – не знаем что происходит в инфраструктуре • Смотреть логи чтобы «понять» - нет ни бюджета ни свободных сотрудников • Если рассматривать пословицу «Мальчик кричал волки» - то ваши СЗИ это куча съеденных мальчиков в единицу времени • Слова «Да узнаем когда это случится. Инциденты ведь происходят не часто» - следует воспринимать как «мне все равно что произойдет с компанией, работу другую найду». 7
  7. 7. А что происходит в инфраструктуре • Что то «упало». Идут ли бекапы? Или в случае вируса-шифровальщика вам восстановиться будет не из чего? • «Вася Пупкин» запустил Hamachi. Ваша DLP абсолютно бесполезна так как диск «Васи» подмаплен к домашнему компьютеру в зашифрованном тоннеле. На другом краю Земли над вашим Квартальным отчетом смеется группа китайцев. • «Маша» уже скачала фильм «Злые будни» но не оставлять же других без пира торрента. Интернет то безлимитный. Репликация базы с удаленным филиалом шла безумно долго. • Администратору Жене было не все равно заплатите ли премиальные и бонусы после обходного. Скрипт уже был вывешен и сработает автоматически ровно через 7 дней стерев все данные. Спишется все на злых хакеров. Логов ведь все равно не будет. • Новая внедренная IPS система работает «отлично». Посмотрите сколько писем шлет. Все «видит», обо всем «знает». Видите вот за сегодня 100500 событий. 8
  8. 8. Идеальный кейс в помощь 1. Пригласите хороших пентестеров или объявите «Bug bounty». 2. Не ожидайте стороннего воздействия хакеров. Пусть это будет внезапностью. Считайте что Вы не объявляли никаких конкурсов. Вы же не знаете в другие моменты времени что вас кто то решил взломать. Постфактум: • Обнаружили ли вы действия посторонних лиц? • Какой процент обнаружения? • Задайте вопрос нам – можно ли это обнаружить? 9
  9. 9. Нужна ли Вам SIEM? Для начала задайтесь вопросом – а вообще есть что защищать? Есть ли что то ценное и можно ли это защитить? 10
  10. 10. Вам НЕ_нужен_SIEM если: • У Вас совсем небольшая инфраструктура • Не планируется роста/слияния компаний • Совокупные нижеуказанные стоимости ниже 20% стоимости проекта: • потери_данных • стоимость_простоя • стоимость_восстановления • потери_преимущества • репутационные/регуляторные риски • Нет квалифицированных специалистов кто может хотя бы базово понять как закрыть уязвимость и как ее могут проэксплуатировать. Бюджет можно потратить разумнее купив «бюджетные» продукты и закрыв для начала часть рисков. Ну или open source решения. 11
  11. 11. SIEM не поможет Вам • В сокращении штата ИТ специалистов • *В автоматическом отражении сетевых атак • Ни в чем, если не обеспечите SIEM необходимыми данными • Ни в чем, если не будет «смотрящего эксперта»/процессов реагирования на инциденты. Утро ИТ/ИБ эксперта должно начинаться не с просмотра логов, а с чашечки кофе за просмотром инцидентов SIEM 12
  12. 12. От простого к сложному  Откуда, когда и почему блокировались учетные записи  Доступ к финансовым сервисам с анонимных сетей  Поток данных из продакшн зон в тестовую  Изменение конфигураций «не админами»  Повышение привилегий (локально, ldap, приложения, бизнес-системы)  Выявление несанкционированных сервисов (проброс в продакшн зону, несанкционированный прокси-сервер)  Обнаружение НСД (вход под учеткой уволенного сотрудника)  Hacker-profiling (поисковые запросы, попытки повышения привилегий и т.д.)  Отсутствие антивирусной защиты на новом установленном компьютере  Изменение критичных конфигураций с VPN подключений  Статистика работы удаленных пользователей 13
  13. 13.  Аудит изменений конфигураций (сетевых устройств, приложений, ОС)  Вход в систему под пользователем, отсутствующим в офисе  Аномальная активность пользователя (массовое удаление/копирование)  Обнаружение распределенной атаки или вирусной эпидемии  Обнаружение уязвимости по событию об установке софта  Оповещение об активной уязвимости по запуску ранее отключенной службы  Обнаружение распределенных по времени атаках (APTx)  Влияние отказа в инфраструктуре на бизнес-процессы (отказ базы данных – не сможем оказывать услугу)  …… От простого к сложному 14
  14. 14. Отличие от конкурентов  Тариф ноль за входящие  Отсутствует лицензирование по EPS и объему хранения  Нет ограничений по скорости потока и объему хранения  Извлечение бОльшего числа полей событий для глубокого детального анализа  Приведение событий в читаемый и понятный вид  Приведение полей к единому формату  Симптоматика, позволяющая понимать о чем событие  Обнаружение угроз и аномалий безсигнатурными методами  Наличие аналитических моделей и представлений, а не только RBR корреляция  Скорость разработки и возможность реализовать ваши «хотелки» Мы не моем посуду в стиральной машинке  15
  15. 15. Что у нас на входе • События с операционных, бизнес систем, AV, СЗИ, IDM, баз данных и т.п. (абсолютно любой источник, который может предоставить полезную информацию о состоянии и угрозе) • Сетевой поток (Flow, span/tap порт) • Экспертные данные (симптомы простые и составные, правила корреляции, аналитические пакетные задания, модели, риск-метрики, параметры нормализации событий и т.д.) • Данные от пользователя (описание границ инфраструктуры и объектов, запросы, дашборды, прочие настройки) • Фиды (CIF по умолчанию, возможны: *Kaspersky, OTX, Cisco …) • *Данные по инвентаризации, топологии, уязвимостях, открытых портах, конфигурациях 16
  16. 16. Что на выходе • Инциденты по правилам корреляции • *Инциденты в результате построения и анализа моделей : • *Поведенческая • Скоринговая • *Baseline • *Регрессионная • *Кластерная • Транзакционная • *Семантическая • Инциденты в результате анализа «умными» роботами (для определения многофакторных слабозаметных развивающихся во времени угроз) • Данные для поисковых запросов и аналитики • Скоринговые метрики для акцентирования внимания экспертов • Влияние на соответствие политикам и стандартам 17
  17. 17. Развеем «мифы» и сплетни  С октября 2015 по январь 2015: Мы использовали kibana,logstash, Чтобы: Быстро стартануть Научить разработчиков. В предыдущей компании на аналогичном проекте я учила на Splunk-е ;) Уменьшить стоимость конечного решения для Заказчика Посмотреть – насколько это будет работать и применимо 18
  18. 18. Что мы усвоили • SMB рынок большой, но мы не желаем делать siem из г... и веток • У выбранной связки уйма неработающих элементов, низкая производительность и неприменимость для решения задач больше чем log management. • Доработка open source механизмов до работающего стабильного релиза обходится дороже собственной разработки • И да. Мы 2 раза поменяли команду собственной разработки доводя до идеальной  19
  19. 19. Что имеем сейчас • Собственный агент управляемый с сервера для локального и удаленного сбора Windows event log, событий с таблиц и представлений MsSQL, Oracle, текстовых файлов … • Написанный с нуля интерфейс для взаимодействия с пользователем • Корреляцию первой версии • Высокопроизводительные инпуты/аутпуты и обработчики • API • Симптоматику • Трансляторы • Рабочую масштабируемую архитектуру хранения и обработки • Набитую руку на кейсах пилотных внедрений • Обученную команду первоклассных разработчиков Утопические идеи по разработке собственной базы данных оставим для других  20
  20. 20. На чем построено решение • ОС серверов решения – (Ubuntu Server 14.*/RH-like) X64 на реальном или виртуальном оборудовании. Разворачивается из OVF или образа • Агент (пока только под Windows системы) – собственная разработка с защищенным хранилищем и управлением с сервера. Для сервера подписки событий Windows может использоваться дополнительный сервер с win OS и агентом • Базы данных – Hadoop + Elasticsearch + секрет:) • MQ: Redis, 0mq, Kafka Apache • Прием событий – собственные инпуты на с++ и API для агента • Анализ сетевого трафика – доработанное open source решение • Нормализация событий – собственные парсеры • Симптоматика – свое решение • Корреляция – свое решение • Интерфейс – свое решение • Аналитика – свое решение • Фиды – внешние + наших экспертов 21
  21. 21. • Для Заказчика - black box • Вся настройка – из веб-интерфейса • Доступ к консоли – с браузера по https • LDAP аутентификация • Ролевая модель доступа • Кастомизируемый интерфейс • Возможность добавления пользовательских сущностей (правил, запросов, симптомов …) • Горизонтальное увеличение производительности и вертикальное масштабирование • *Возможность автоматического обновления продукта (база знаний, правила корреляции, батчи, фиды, новые фичи …) Подробности о продукте 22
  22. 22. Минимальная одно-нодовая конфигурация • Физический сервер или гипервизор • 1 сервер • ОЗУ от 16 GB • Процессор 2x2.4 GHz, суммарно не менее 4х ядер • HDD 100GB под систему + под данные. На что то постарше тестов желательно RAID/SSD 23
  23. 23. Оптимальная Enterprise конфигурация: • Минимально 1 нода для сбора и обработки событий • 1 нода для встроенной аналитики и работы с интерфейсом • Опционально: 1 нода для работы с трафиком (span/tap) • Опционально: 1 нода для API к фидам 24
  24. 24. Планы развития (август 2015) • Интеграция с PaloAlto • Интеграция с Kaspersky SC, Symantec EndPoint • Интеграция с Cisco FireSIGHT (eStreamer) • Допишем ролевую модель • Корреляция v.2.0 • Доработаем свои парсеры • Добавим в релиз аналитическую модель • Переработаем работу с источниками и агентами • Добавим раздел работы с трафиком • Группировка весов в симптоматике • Наполнение контента (корреляция, симтоматика, списки) 25
  25. 25. Планы развития (по октябрь 2015) • Инвентаризация и управление активами • Активное обнаружение активов • Регрессионная модель • Составная симтоматическая модель • Расширенное пассивное обнаружение активов • Интеграция со сканерами уязвимостей • Добавление механизмов обнаружения аномалий и угроз • Динамические активы • Workflow для фиксации и работы с инцидентами • Улучшенный интерфейс и дашборды 26
  26. 26. Планы развития (ближайшие направления) • Расширение управления продуктом через web консоль • Нормализация событий и подключение новых источников интеграторами через web консоль • Управление конфигурациями в разрезе влияния на соответствие стандартам и политикам • Интеграции с вендорами для более точного, полного и оперативного обнаружения угроз • Интеграция с Service Desk системами 27
  27. 27. Варианты внедрения RuSIEM • All-in-One SIEM решение • Только LM • SOC • Снижение стоимости лицензий имеющихся SIEM систем за счет фильтрации событий • Антифрод • Аналитическая система 28
  28. 28. Контактная информация: Максим Степченков m.stepchenkov@it-task.ru Олеся Шелестова oshelestova@rusiem.com Официальный дистрибьютор: СПАСИБО ЗА ВНИМАНИЕ (Далее – более техническая часть) 105082, Россия, г. Москва ул. Большая Почтовая, 55/59с1 Телефон: +7 (495) 972-98-26 E-mail: info@it-task.ru 29
  29. 29. Техническая часть 30
  30. 30. Лишь некоторые принципы в разработке • Пользовательские и системные сущности • Модульность системы • Взаимозаменяемость модулей. Любых. Даже БД. • Буферизация данных между модулями во избежание потерь данных и сглаживания всплесков • Вертикальная скалируемость • Горизонтальное увеличение производительности • Отсутствие каких либо узлов и архитектуры «звезда» 31
  31. 31. Нормализация • Все поля сводятся к единому формату • Формат «модели» с вложенными объектами и свойствами • Вложенность рекомендуется до 4-5 уровней • Наименования объектов – вне зависимости от источника. То есть user.name это имя пользователя и не важен тип источника. Свойство учетной записи определяется другими атрибутами. 32
  32. 32. Нормализация
  33. 33. Производительность одной ноды • Приемники событий - до 100 000 EPS суммарно • Обработчики – от 5 000 EPS на 1 ядро процессора в 1 поток • Агрегаты – от 4 000 EPS на 1 ядро процессора в 1 поток • Сохранение в БД – от 5 000 EPS на 1 ядро процессора Производительность кластера не имеет ограничений. Все тесты производились на реальных событиях при полном разборе полей в JSON формате от источников: MS Windows, Linux Syslog, Bluecoat Proxy, Stonegate. Производительность на элементарном разборе коротких событий как LM - свыше 100 000 EPS 34
  34. 34. Дашборды
  35. 35. Разделы Группировка и быстрый поиск Интервал времени Количество событий в интервале Авторефреш Настройка представления Выбор представления Текущий фильтр запроса Навигация по событиям
  36. 36. Симптоматика и события
  37. 37. Фильтрация запроса Предварительная фильтрация запроса Настройка представления Поиск с использованнием симтоматики Настройка полей предварительного и детального просмотра событий Настройка полей грида событий Настройка представлений
  38. 38. Правила корреляции
  39. 39. Инциденты (пока без воркфлоу)
  40. 40. Мониторинг и управление системой
  41. 41. Управление агентами RuSIEM
  42. 42. Простая симптоматика
  43. 43. Списки
  44. 44. Настройки системы
  45. 45. Аналитика • Будет скоро  • Задания будут крутиться в фоновом режиме, near real-time, обрабатывая имеющиеся данные • В первых релизах не будут предоставляться пользователю возможность управления/изменения аналитических тасков. Пользователю лишь будут доступны результаты в виде инцидентов или простых событий • Задания работают как по трафику так и по простым событиям • В первых версиях будут учитываться скоринговые, регрессионные показатели (например, «топ-10 ip адресов имеющих сегодня трафик в сеть DMZ отличный от прошлой недели», «активы, имеющие иные соединения на порт назначения чем на прошлой неделе». 46
  46. 46. Контактная информация: Максим Степченков m.stepchenkov@it-task.ru Олеся Шелестова oshelestova@rusiem.com Официальный дистрибьютор: СПАСИБО ЗА ВНИМАНИЕ Остались вопросы? Обращайтесь! 105082, Россия, г. Москва ул. Большая Почтовая, 55/59с1 Телефон: +7 (495) 972-98-26 E-mail: info@it-task.ru 47

×