http://www.slideshare.net/OlesyaShelestova/rusiem/1 

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 отличный от прошлой недели», «активы, имеющие иные соединения на порт назначения чем на прошлой неделе».