IBM QRadar SIEM. Система управления инцидентами

IBM QRadar SIEM

Для эффективной работы с обширной клиентской базой банку потребовалось внедрить современную CRM-систему, которая объединила все коммуникации с розничными клиентами и процессы их обслуживания. Создание системы началось с автоматизации VIP-сегмента.

Ниже описан пример решения задачи по построению системы управления инцидентами информационной безопасности в крупной компании на базе IBM QRadar SIEM.

В компании создана разветвленная информационная инфраструктура, включающая ряд продуктов по информационной безопасности - межсетевые экраны, системы предотвращения вторжений, антивирусы, системы контроля доступа и т.п.

Указанные продукты в процессе работы генерируют большое количество событий и лог-файлов, куда записывается информация о событиях безопасности. Лог-файлы также генерируют операционные системы, приложения, базы данных и другие элементы информационной инфраструктуры заказчика.

При возникновении угроз информационной безопасности, для профилактики и расследования инцидентов проводится анализ данных из лог-файлов в ручном режиме. Анализ занимает значительное время и не всегда возможен в связи с загруженностью персонала компании. В инфраструктуре нет автоматизированных средств анализа данных и корреляции событий безопасности из различных лог-файлов.

Для оценки возможностей решения у заказчика было проведено тестирование QRadar SIEM: были подключены 10 источников данных, производился сбор и анализ сетевого трафика. В результате тестирования было создано более 100 событий безопасности и выявлено 13 критичных инцидентов, включая забытые аккаунты администраторов, ботнеты, вредоносное ПО и подозрительную активность.

По итогам тестирования заказчик принял решение о создании системы управления инцидентами информационной безопасности на базе QRadar SIEM.

Цель создания СУИБ – повышение уровня защищенности информационной инфраструктуры за счет сбора, корреляции и анализа данных о событиях и угрозах безопасности.

СУИБ должна обеспечивать сбор событий и сетевого трафика, их анализ, создание событий безопасности и сравнение их с установленными правилами, определение инцидентов безопасности и возможности их последующей обработки (расследования).

Типы источников событий

  • Стандартные лог-файлы аудита в ОС Windows Server
  • Серверы базы данных
  • Внутренний межсетевой экран, работающий в кластере на двух серверах
  • Внешний межсетевой экран, работающий в отказоустойчивом кластере
  • Сервер виртуальных машин
  • Сервер управления виртуальной инфраструктурой
  • Система мониторинга
  • Система антивирусной защиты
  • Веб-серверы

Всего в информационная инфраструктура содержала 55  источников для сбора событий.

1

Процесс работы СУИБ состоит из взаимосвязанных этапов:

  • Сбор событий от информационных систем и приведение их к единому формату.
  • Сбор сетевого трафика для IBM QRadar QFlow Collector через «зеркалированный» порт коммутатора.
  • Подсистема анализа событий производит анализ и корреляцию событий, используя данные об угрозах, сетевых потоках, уязвимостях, активах IT-инфраструктуры и сохраняет полученные события в хранилище событий
  • Полученные события безопасности вызывают срабатывание правил корреляции и создают инциденты безопасности.
  • Инциденты безопасности сохраняются в базе инцидентов.
  • Пользователи системы просматривают инциденты и отчеты о произошедших событиях и обеспечивают их разрешение (расследование).

Структура СУИБ

1. Подсистема анализа событий IBM QRadar Core Appliance Производительность комплекса обеспечивает подключение до 750 источников событий и обработку не менее 1 000 событий в секунду при установившемся потоке событий. Пиковая нагрузка подсистемы по сбору и обработке - 50 000 событий в секунду.

Для сбора событий используются протоколы: Syslog, Simple Network Management Protocol (SNMP), Java™ database Connectivity (JDBC), Open Platform for Security (OPSEC).

Все полученные события могут быть отнесены к одному из типов:

  • События (events);
  • Потоки сетевых данных (flows);
  • Информация об уязвимостях (vulnerability assessment).

2. Подсистема сбора сетевого трафика IBM QRadar QFlow Collector Сбор сетевого трафика производится на SPAN («зеркальных») портах и выполняет профилирование трафика до уровня приложений. Подсистема позволяет идентифицировать около 500 приложений и анализирует трафик на скорости 200 Мбит/с.

Способы подключения источников данных

Тип источника данных Способ подключения к СУИБ
Windows Server Audit Logs Агент WinCollect
Microsoft SQL Server JDBC
Microsoft TMG 2010 Агент Adaptive Log Exporter
Check Point UTM-1 OPSEC
Microsoft SCOM 2007 R2 JDBC
VMware ESX 5.1, VMware vCenter syslog
Symantec Endpoint Protection 12 syslog
Microsoft IIS syslog
Apache HTTP Server syslog

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

 В ходе внедрения было принято решение определять следующие категории угроз информационной безопасности:

Тип правила Описание Пример правила
Аномалия Правилами должны определяться потенциально опасные события, когда поведение хоста или сетевого трафика являются подозрительными (например, фрагментация пакетов или известные техники обхода систем обнаружения вторжений). Excessive Database Connections – срабатывает при превышении заданного количества подключений к БД
Аутентификация Правилами должны определяться события, относящиеся к аутентификации пользователей, групп или изменению привилегий аккаунтов (например, вход и выход пользователей из системы). Multiple Login Failures for Single Username – срабатывает при обнаружении нескольких неудачных попыток аутентификации для одного и того же имени пользователя.
DDoS атака Правилами должны определяться события, относящиеся к потенциальным атакам типа «Отказ в обслуживании» (Denial of Service) или «Распределенный отказ в обслуживании» (Distributed Denial of Service) на хосты или сервисы. Local Flood (TCP) – срабатывает при обнаружении, что локальный хост посылает в Интернет более чем 60 000 пакетов со скоростью 1000 пакетов в секунду используя протокол TCP.
Ботнеты Правилами должны определяться события, связанные с обнаружением активности сети ботнетов (например, если локальный хост пытается установить соединение с известной сетью ботнетов). Local host on Botnet CandC List (DST) – срабатывает при обнаружении, что локальный IP адрес назначения является членом известной сети ботнетов
Нарушение политики Правилами должны определяться события, связанные с нарушением корпоративных политик безопасности или общепринятых рекомендаций по безопасности. IRC Connections – срабатывает при обнаружении превышения заданного числа IRC соединений из локальной сети в Интернет.
Соответствие стандартам Правилами должны определяться события, определяемые как нежелательные или потенциально опасные с точки зрения международных стандартов по безопасности. Traffic from Untrusted Network to Trusted Network – срабатывает при обнаружении сетевого трафика из недоверенной сети в доверенную сеть.
База данных Правилами должны определяться события, относящиеся к работе с базами данных, например, изменения прав доступа, доступ к базе данных из недоверенной сети или не в рабочее время. Concurrent Logins from Multiple Locations – срабатывает при обнаружении нескольких попыток аутентификации на сервере базы данных с нескольких удаленных IP адресов.
Эксплоит Правилами должны определяться события, связанные с попытками эксплуатации эксплоитов, переполнения буфера или атаки, использующие уязвимости web приложений. Chained Exploit Followed by Suspicious Events – срабатывает при обнаружении активности эксплоита с IP адреса источника, следующей после подозрительной активности аккаунта на стороннем хосте в течение 15 минут.
Величина регулировки Правилами должны определяться параметры значимости и достоверности событий и сетевых потоков для формирования инцидентов. Context is Local to Local - правило должно устанавливать значимость  данных о сетевых потоках и событиях при коммуникациях внутри локальной сети.
Вредоносное ПО Правилами должны определяться события, связанные с вирусными атаками или другими формами активности вредоносного программного обеспечения (трояны, шпионы, малваре). Communication with a site that is listed on a known blacklist or uses fast flux – срабатывает при обнаружении факта сетевых коммуникаций с web сайтами, которые входят в «черные списки» распространителей вредоносного ПО.
Подозрительная активность Правилами должны определяться события, связанные с обнаружением сканирования сети и другими техниками, применяемыми для поиска и определения сетевых ресурсов. Potential P2P Traffic Detected – срабатывает при обнаружении потенциального P2P трафика.
Система Правилами должны определяться события, связанные с системными изменениями, установкой ПО или информационными служебными сообщениями. Flow Source Stopped Sending Flows – срабатывает при обнаружении, что источник сетевых потоков перестает генерировать данные в течение 30 минут.

Всего было задано около 90 правил корреляции.

В случае обнаружения инцидента СУИБ формирует запись об инциденте и отправляет уведомление администратору.

Типы активов

 Сбор и анализ событий проводился для следующих активов:

  • Конроллер домена и DNS
  • Сервер приложений
  • Файловый сервер
  • База данных
  • Пограничный контроллер (TMG, ISA)
  • Веб-сервер
  • Гипервизор
  • SAN Хранилище
  • Сервер управления
  • Коммутатор (ядро, DMZ, VMware)

Роли в системе

 В ходе реализации проекта в СУИБ были созданы роли:

Имя Роль Описание
Admin Основной административный аккаунт Работоспособность системы, подключение устройств, создание пользователей и ролей. Создание правил корреляции.
SIEM_Admin Административный аккаунт Работоспособность системы, подключение устройств, создание пользователей и ролей. Создание правил корреляции.
SIEM_Operator Управление правилами и настройками Просмотр событий, выявление инцидентов. Назначение инцидентов пользователям. Закрытие инцидентов. Создание отчетов.
SIEM_Incident Управление инцидентами Просмотр событий, выявление инцидентов. Назначение инцидентов пользователям. Закрытие инцидентов. Создание отчетов.
SIEM_Viewer Только просмотр данных Просмотр инцидентов.

Взаимодействие с источниками событий

Для взаимодействия между компонентами системы использовались более 20 портов: от 22 (SSH TCP - двунаправленный трафик с IBM QRadar Core Appliance на IBM QRadar QFlow Collector, удаленное управление) до 32010 (TCP - двунаправленный трафик между компонентами СУИБ для сбора IBM QRadar Core Appliance информации с IBM QRadar QFlow Collector.)

Особенности внедрения

Для снижения количества ложных срабатываний для событий учитывался тип операционной системы.

Для определения наиболее критичных событий безопасности использовались важность ресурса, сетевая иерархия, параметры операционных систем и используемых приложений.

Согласованность времени событий обеспечивается за счет синхронизации с корпоративным сервером точного времени по протоколу NTP.

У заказчика были смонтированы и настроены аппаратные платформы:

  • IBM QRadar QFlow Collector 1201
  • IBM QRadar Core Appliance 3105

СУИБ в ходе работы применяет обновления, загружаемые с https://qmmunity.q1labs.com:

  • Обновления конфигурации, базы уязвимостей, угроз безопасности;
  • Обновления DSM описаний для источников событий;
  • Обновления ПО системы (major and minor).

Порядок проведения работ по внедрению СУИБ

  • монтаж оборудования;
  • подключение оборудования к сети электропитания и сетевой инфраструктуре;
  • маркировка оборудования и соединительных кабелей;
  • общесистемная диагностика;
  • установка и настройка ПО;
  • настройка сетевых параметров устройств;
  • установка лицензионного ключа на оборудование системы;
  • обновление ПО системы до последней работоспособной версии;
  • установка системного времени устройств на основе конфигурации сервера времени;
  • настройка автоматического обновления программного обеспечения СУИБ;
  • задание в настройках системы сетевой иерархии ЛВС заказчика;
  • настройка подключения подсистемы сбора сетевого трафика к подсистеме анализа событий;
  • настройка проверки работоспособности системы при помощи протокола SNMP;
  • настройка рассылки оповещений администратору при возникновении проблем с производительностью системы;
  • настройка резервного копирования конфигурации системы;
  • создание роле безопасности;
  • присвоение созданным ролям безопасности прав по управлению системой;
  • создание пользователей системы и назначение им роли безопасности;
  • настройка параметров аутентификации пользователей системы;
  • настройка логических модулей по сбору, нормализации и анализу данных;
  • подключение подсистемы сбора сетевого трафика к центральной точке прохождения сетевого трафика в ЛВС заказчика;
  • настройка сбора сетевого трафика и трафика приложений через span/mirror порты;
  • создание блоков сетевых и сервисных групп, которые будут учитываться при составлении правил корреляции;
  • настройка мониторинга автоматического определения источников событий на основе обнаружения протокола syslog;
  • настройка источников событий на передачу лог-файлов до логического модуля сбора данных;
  • настройка логического модуля сбора данных на получение лог-файлов от источников событий;
  • настройка автоматического обнаружения комплексом серверов и активов сети;
  • настройка подключения данных со сканеров уязвимостей;
  • настройка перечня приоритетных контролируемых объектов;
  • настройка правил корреляции событий информационной безопасности;
  • проверка работоспособности системы.

Результаты внедрения

В результате внедрения системы управления инцидентами информационной безопасности в информационной инфраструктуре заказчика были обеспечены:

  • сбор и централизованное хранение данных о событиях ИБ;
  • контроль активности пользователей, устройств, приложений;
  • корреляция и анализ событий ИБ от различных источников;
  • формирование инцидентов информационной безопасности;
  • возможности для проведения расследований инцидентов;
  • предупреждение о потенциальных угрозах безопасности;
  • оценка уязвимостей информационных систем;
  • снижение рисков возникновения инцидентов безопасности.

Цель внедрения СУИБ была успешно достигнута.