SIEM (Security Information and Event Management) служит для агрегации, анализа и обработки событий из различных систем, фиксируя инциденты и выявляя угрозы с использованием многофакторных методов. Несмотря на его полезность, SIEM не заменяет другие системы безопасности и требует квалифицированного персонала для эффективного функционирования. Он также предоставляет возможности для расследования инцидентов, улучшения видимости инфраструктуры и снижения количества ложных срабатываний.

1. 2

2. Что такое SIEM
SIEM – Security Information and Event Management
• Собирает события с различных систем (операционные системы,
средства защиты, бизнес-системы, базы данных, сетевая среда)
• Приводит к общему формату для дальнейшей обработки
• Анализирует разнородные данные и выявляет отклонения, нарушения,
аномалии, выявляет угрозы на основе сигнатур, алгоритмов,
математических методов и моделей
• Фиксирует инцидент, чтобы он не остался незамеченным, скрытым
• Уменьшает время реагирования на возникающие инциденты
• *Предотвращает инциденты
3

3. Что такое SIEM
SIEM это не панацея, это не замена
AV/IPS/IDS/DLP/DPI!
• SIEM – аггрегатор информации от различных источников
• Получаемые данные слишком разнородны, поэтому приводятся к
одному виду
• Данные от источников как «сплетни». Поэтому они проверяются
по нескольким факторам
• Это «думалка», визуализация для полученной информации и
быстрые поисковые механизмы
• Кроме всего – это защищенное хранилище в котором факты о
случившемся не будут удалены даже администратором.
4

4. Инциденты
• Сетевые атаки
• Вирусные эпидемии
• Отключение средств защиты
• Злонамеренные действия
• Несанкционированный доступ
• Использование служебного положения
• Отказ в обслуживании
• Сбои в работе
• Аномалии и всплески
• *Мошеннические действия
• Несоответствие требованиям Законодательства и регуляторов
5

5. «Сопутствующие» варианты применения
• Расследование инцидентов
• Снижение числа ложных срабатываний от СЗИ
• Антифрод
• Инвентаризация активов
• Обнаружение сбоев в работе ИТ инфраструктуры
• *Прогнозирование инцидентов ИТ и ИБ
• *Прогнозирование состояний активов
6

6. Зачем SIEM
• Из за большого количества источников – не
знаем что происходит в инфраструктуре
• Смотреть логи чтобы «понять» - нет ни бюджета
ни свободных сотрудников
• Если рассматривать пословицу «Мальчик кричал
волки» - то ваши СЗИ это куча съеденных
мальчиков в единицу времени
• Слова «Да узнаем когда это случится. Инциденты
ведь происходят не часто» - следует
воспринимать как «мне все равно что
произойдет с компанией, работу другую найду».
7

7. А что происходит в инфраструктуре
• Что то «упало». Идут ли бекапы?
Или в случае вируса-шифровальщика вам восстановиться будет не из чего?
• «Вася Пупкин» запустил Hamachi.
Ваша DLP абсолютно бесполезна так как диск «Васи» подмаплен к домашнему
компьютеру в зашифрованном тоннеле. На другом краю Земли над вашим
Квартальным отчетом смеется группа китайцев.
• «Маша» уже скачала фильм «Злые будни»
но не оставлять же других без пира торрента. Интернет то безлимитный. Репликация базы с удаленным
филиалом шла безумно долго.
• Администратору Жене было не все равно
заплатите ли премиальные и бонусы после обходного. Скрипт уже был вывешен и сработает автоматически
ровно через 7 дней стерев все данные. Спишется все на злых хакеров. Логов ведь все равно не будет.
• Новая внедренная IPS система работает «отлично».
Посмотрите сколько писем шлет. Все «видит», обо всем «знает». Видите вот за сегодня 100500 событий.
8

8. Идеальный кейс в помощь
1. Пригласите хороших пентестеров или объявите «Bug bounty».
2. Не ожидайте стороннего воздействия хакеров. Пусть это будет
внезапностью. Считайте что Вы не объявляли никаких конкурсов. Вы
же не знаете в другие моменты времени что вас кто то решил
взломать.
Постфактум:
• Обнаружили ли вы действия посторонних лиц?
• Какой процент обнаружения?
• Задайте вопрос нам – можно ли это обнаружить?
9

9. Нужна ли Вам SIEM?
Для начала задайтесь вопросом – а вообще есть что защищать?
Есть ли что то ценное и можно ли это защитить?
10

10. Вам НЕ_нужен_SIEM если:
• У Вас совсем небольшая инфраструктура
• Не планируется роста/слияния компаний
• Совокупные нижеуказанные стоимости ниже 20% стоимости проекта:
• потери_данных
• стоимость_простоя
• стоимость_восстановления
• потери_преимущества
• репутационные/регуляторные риски
• Нет квалифицированных специалистов кто может хотя бы базово понять как
закрыть уязвимость и как ее могут проэксплуатировать.
Бюджет можно потратить разумнее купив «бюджетные» продукты и
закрыв для начала часть рисков. Ну или open source решения.
11

11. SIEM не поможет Вам
• В сокращении штата ИТ специалистов
• *В автоматическом отражении сетевых атак
• Ни в чем, если не обеспечите SIEM необходимыми данными
• Ни в чем, если не будет «смотрящего эксперта»/процессов реагирования на
инциденты.
Утро ИТ/ИБ эксперта должно начинаться не с просмотра логов, а с чашечки
кофе за просмотром инцидентов SIEM
12

12. От простого к сложному
 Откуда, когда и почему блокировались учетные записи
 Доступ к финансовым сервисам с анонимных сетей
 Поток данных из продакшн зон в тестовую
 Изменение конфигураций «не админами»
 Повышение привилегий (локально, ldap, приложения, бизнес-системы)
 Выявление несанкционированных сервисов (проброс в продакшн зону, несанкционированный
прокси-сервер)
 Обнаружение НСД (вход под учеткой уволенного сотрудника)
 Hacker-profiling (поисковые запросы, попытки повышения привилегий и т.д.)
 Отсутствие антивирусной защиты на новом установленном компьютере
 Изменение критичных конфигураций с VPN подключений
 Статистика работы удаленных пользователей
13

13.  Аудит изменений конфигураций (сетевых устройств, приложений, ОС)
 Вход в систему под пользователем, отсутствующим в офисе
 Аномальная активность пользователя (массовое удаление/копирование)
 Обнаружение распределенной атаки или вирусной эпидемии
 Обнаружение уязвимости по событию об установке софта
 Оповещение об активной уязвимости по запуску ранее отключенной службы
 Обнаружение распределенных по времени атаках (APTx)
 Влияние отказа в инфраструктуре на бизнес-процессы (отказ базы данных – не сможем оказывать
услугу)
 ……
От простого к сложному
14

14. Отличие от конкурентов
 Тариф ноль за входящие  Отсутствует лицензирование по EPS и объему хранения
 Нет ограничений по скорости потока и объему хранения
 Извлечение бОльшего числа полей событий для глубокого детального анализа
 Приведение событий в читаемый и понятный вид
 Приведение полей к единому формату
 Симптоматика, позволяющая понимать о чем событие
 Обнаружение угроз и аномалий безсигнатурными методами
 Наличие аналитических моделей и представлений, а не только RBR корреляция
 Скорость разработки и возможность реализовать ваши «хотелки»
Мы не моем посуду в стиральной машинке 
15

15. Что у нас на входе
• События с операционных, бизнес систем, AV, СЗИ, IDM, баз данных и т.п.
(абсолютно любой источник, который может предоставить полезную
информацию о состоянии и угрозе)
• Сетевой поток (Flow, span/tap порт)
• Экспертные данные (симптомы простые и составные, правила корреляции,
аналитические пакетные задания, модели, риск-метрики, параметры
нормализации событий и т.д.)
• Данные от пользователя (описание границ инфраструктуры и объектов,
запросы, дашборды, прочие настройки)
• Фиды (CIF по умолчанию, возможны: *Kaspersky, OTX, Cisco …)
• *Данные по инвентаризации, топологии, уязвимостях, открытых портах,
конфигурациях
16

16. Что на выходе
• Инциденты по правилам корреляции
• *Инциденты в результате построения и анализа моделей :
• *Поведенческая
• Скоринговая
• *Baseline
• *Регрессионная
• *Кластерная
• Транзакционная
• *Семантическая
• Инциденты в результате анализа «умными» роботами (для определения
многофакторных слабозаметных развивающихся во времени угроз)
• Данные для поисковых запросов и аналитики
• Скоринговые метрики для акцентирования внимания экспертов
• Влияние на соответствие политикам и стандартам
17

17. Развеем «мифы» и сплетни 
С октября 2015 по январь 2015:
Мы использовали kibana,logstash,
Чтобы:
Быстро стартануть
Научить разработчиков. В предыдущей компании на
аналогичном проекте я учила на Splunk-е ;)
Уменьшить стоимость конечного решения для Заказчика
Посмотреть – насколько это будет работать и применимо
18

18. Что мы усвоили
• SMB рынок большой, но мы не желаем делать siem
из г... и веток
• У выбранной связки уйма неработающих
элементов, низкая производительность и
неприменимость для решения задач больше чем
log management.
• Доработка open source механизмов до
работающего стабильного релиза обходится
дороже собственной разработки
• И да. Мы 2 раза поменяли команду собственной
разработки доводя до идеальной 
19

19. Что имеем сейчас
• Собственный агент управляемый с сервера для локального и
удаленного сбора Windows event log, событий с таблиц и
представлений MsSQL, Oracle, текстовых файлов …
• Написанный с нуля интерфейс для взаимодействия с
пользователем
• Корреляцию первой версии
• Высокопроизводительные инпуты/аутпуты и обработчики
• API
• Симптоматику
• Трансляторы
• Рабочую масштабируемую архитектуру хранения и обработки
• Набитую руку на кейсах пилотных внедрений
• Обученную команду первоклассных разработчиков
Утопические идеи по разработке собственной базы
данных оставим для других  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. • Для Заказчика - black box
• Вся настройка – из веб-интерфейса
• Доступ к консоли – с браузера по https
• LDAP аутентификация
• Ролевая модель доступа
• Кастомизируемый интерфейс
• Возможность добавления пользовательских сущностей (правил,
запросов, симптомов …)
• Горизонтальное увеличение производительности и вертикальное
масштабирование
• *Возможность автоматического обновления продукта (база знаний,
правила корреляции, батчи, фиды, новые фичи …)
Подробности о продукте
22

22. Минимальная одно-нодовая конфигурация
• Физический сервер или гипервизор
• 1 сервер
• ОЗУ от 16 GB
• Процессор 2x2.4 GHz, суммарно не менее 4х ядер
• HDD 100GB под систему + под данные. На что то постарше тестов
желательно RAID/SSD
23

23. Оптимальная Enterprise конфигурация:
• Минимально 1 нода для сбора и обработки событий
• 1 нода для встроенной аналитики и работы с интерфейсом
• Опционально: 1 нода для работы с трафиком (span/tap)
• Опционально: 1 нода для API к фидам
24

24. Планы развития (август 2015)
• Интеграция с PaloAlto
• Интеграция с Kaspersky SC, Symantec EndPoint
• Интеграция с Cisco FireSIGHT (eStreamer)
• Допишем ролевую модель
• Корреляция v.2.0
• Доработаем свои парсеры
• Добавим в релиз аналитическую модель
• Переработаем работу с источниками и агентами
• Добавим раздел работы с трафиком
• Группировка весов в симптоматике
• Наполнение контента (корреляция, симтоматика, списки)
25

25. Планы развития (по октябрь 2015)
• Инвентаризация и управление активами
• Активное обнаружение активов
• Регрессионная модель
• Составная симтоматическая модель
• Расширенное пассивное обнаружение активов
• Интеграция со сканерами уязвимостей
• Добавление механизмов обнаружения аномалий и угроз
• Динамические активы
• Workflow для фиксации и работы с инцидентами
• Улучшенный интерфейс и дашборды
26

26. Планы развития (ближайшие направления)
• Расширение управления продуктом через web консоль
• Нормализация событий и подключение новых источников
интеграторами через web консоль
• Управление конфигурациями в разрезе влияния на соответствие
стандартам и политикам
• Интеграции с вендорами для более точного, полного и
оперативного обнаружения угроз
• Интеграция с Service Desk системами
27

27. Варианты внедрения RuSIEM
• All-in-One SIEM решение
• Только LM
• SOC
• Снижение стоимости лицензий имеющихся SIEM систем за
счет фильтрации событий
• Антифрод
• Аналитическая система
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. Техническая часть
30

30. Лишь некоторые принципы в разработке
• Пользовательские и системные сущности
• Модульность системы
• Взаимозаменяемость модулей. Любых. Даже БД.
• Буферизация данных между модулями во избежание потерь
данных и сглаживания всплесков
• Вертикальная скалируемость
• Горизонтальное увеличение производительности
• Отсутствие каких либо узлов и архитектуры «звезда»
31

31. Нормализация
• Все поля сводятся к единому формату
• Формат «модели» с вложенными объектами и свойствами
• Вложенность рекомендуется до 4-5 уровней
• Наименования объектов – вне зависимости от источника. То есть
user.name это имя пользователя и не важен тип источника.
Свойство учетной записи определяется другими атрибутами.
32

32. Нормализация

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. Дашборды

35. Разделы
Группировка и
быстрый поиск
Интервал
времени
Количество
событий в
интервале
Авторефреш
Настройка
представления
Выбор
представления
Текущий фильтр
запроса
Навигация по событиям

36. Симптоматика и события

37. Фильтрация
запроса
Предварительная
фильтрация
запроса
Настройка
представления
Поиск с
использованнием
симтоматики Настройка полей
предварительного
и детального
просмотра
событий
Настройка полей
грида событий
Настройка представлений

38. Правила корреляции

39. Инциденты (пока без воркфлоу)

40. Мониторинг и управление системой

41. Управление агентами RuSIEM

42. Простая симптоматика

43. Списки

44. Настройки системы

45. Аналитика
• Будет скоро 
• Задания будут крутиться в фоновом режиме, near real-time,
обрабатывая имеющиеся данные
• В первых релизах не будут предоставляться пользователю
возможность управления/изменения аналитических тасков.
Пользователю лишь будут доступны результаты в виде
инцидентов или простых событий
• Задания работают как по трафику так и по простым
событиям
• В первых версиях будут учитываться скоринговые,
регрессионные показатели (например, «топ-10 ip адресов
имеющих сегодня трафик в сеть DMZ отличный от прошлой
недели», «активы, имеющие иные соединения на порт
назначения чем на прошлой неделе».
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