В KUMA действует режим мультитенантности, при котором один экземпляр программы KUMA, установленный в инфраструктуре основной организации (далее "главный тенант"), позволяет ее изолированным филиалам (далее "тенантам") получать и обрабатывать свои события.

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

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

По умолчанию в KUMA созданы два тенанта:

Главный (или Main) – в нем содержатся ресурсы и сервисы, относящиеся к главному тенанту. Эти ресурсы доступны только главному администратору.
Общий – в этот тенант главный администратор может поместить ресурсы, категории активов и политики мониторинга, которые смогут задействовать пользователи всех тенантов. Доступ к общему тенанту можно ограничить для отдельных пользователей.
Если в параметрах пользователя установлен флажок Скрывать ресурсы из общего тенанта, этому пользователю становится недоступна принадлежащая общему тенанту папка Shared в веб-интерфейсе KUMA в разделе Ресурсы → <Тип ресурсов>. Это означает, что пользователь не сможет просмотреть, отредактировать или еще как-то использовать общие ресурсы. Пользователь также не сможет экспортировать общие ресурсы и наборы ресурсов, в состав которых входят ресурсы из общего тенанта: ни через веб-интерфейс, ни через REST API.

При этом, если какие-то из доступных пользователю сервисов используют общие ресурсы, пользователь будет видеть название этих ресурсов в параметрах сервиса, но не сможет их просмотреть или изменить. Содержимое активных листов пользователю будет доступно, даже если ресурс этого активного листа является общим.

Ограничение не распространяется на общие категории активов. Также общие ресурсы всегда доступны пользователям с ролью главного администратора.

В начало

О событиях

События – это события информационной безопасности, зарегистрированные на контролируемых элементах IT-инфраструктуры организации. Например, события включают попытки входа в систему, взаимодействия с базой данных и рассылку информации с датчиков. Каждое отдельное событие может показаться бессмысленным, но если рассматривать их вместе, они формируют более широкую картину сетевой активности, помогающую идентифицировать угрозы безопасности. Это основная функциональность KUMA.

KUMA получает события из журналов и реструктурирует их, приводя данные из разнородных источников к единому формату (этот процесс называется нормализацией). После этого события фильтруются, агрегируются и отправляются в сервис коррелятора для анализа и в сервис хранилища для хранения. Когда KUMA распознает заданное событие или последовательность событий, создаются корреляционные события, которые также анализируются и сохраняются. Если событие или последовательность событий указывают на возможную угрозу безопасности, KUMA создает алерт: это оповещение об угрозе, к которому привязываются все относящиеся к нему данные и которое требует внимания специалиста по безопасности. Если характер поступающих в KUMA данных, создаваемых корреляционных событий и алертов указывает на возможную атаку или уязвимость, признаки такого происшествия можно объединить в инцидент.

Для обеспечения удобства расследования алертов и обработки инцидентов убедитесь, что на всех устройствах, связанных с жизненным циклом обработки событий (источники событий, серверы KUMA, клиентские хосты) время синхронизируется при помощи серверов Network Time Protocol (NTP).

На протяжении своего жизненного цикла события претерпевают изменения и могут называться по-разному. Так выглядит жизненный цикл типичного события:

Первые шаги выполняются в коллекторе.

Сырое событие. Исходное сообщение, полученное KUMA от источника событий с помощью коннектора, называется сырым событием. Это необработанное сообщение, и KUMA пока не может использовать его. Чтобы с таким событием можно было работать, его требуется нормализовать, то есть привести к модели данных KUMA. Это происходит на следующем этапе.
Нормализованное событие. Нормализатор преобразует данные сырого события так, чтобы они соответствовали модели данных KUMA. После этой трансформации исходное сообщение становится нормализованным событием и может быть проанализировано в KUMA. С этого момента KUMA работает только с нормализованными событиями. Необработанные, сырые события больше не используются, но их можно сохранить как часть нормализованных событий внутри поля Raw.
В программе представлены следующие нормализаторы:
- JSON
- CEF
- Regexp
- Syslog (как для RFC3164 и RFC5424)
- CSV/TSV
- Ключ-значение
- XML
- Netflow v5, v9, IPFIX (v10), sFlow v5
- SQL
По завершении этого этапа нормализованные события можно использовать для анализа.
Точка назначения. После обработки события коллектором оно готово к пересылке в другие сервисы KUMA: в коррелятор и/или хранилище KUMA.

Следующие этапы жизненного цикла события проходят в корреляторе.

Типы событий:

Базовое событие. Событие, которое было нормализовано.
Агрегированное событие. Чтобы не тратить время и ресурсы на обработку большого количества однотипных сообщений, похожие события можно объединять в одно событие. Такие события ведут себя и обрабатываются так же, как и базовые события, но в дополнение ко всем параметрам родительских событий (событий, которые были объединены) агрегированные события имеют счетчик, показывающий количество родительских событий, которые они представляют. Агрегированные события также хранят время, когда были получены первое и последнее родительские события.
Корреляционное событие. При обнаружении последовательности событий, удовлетворяющих условиям правила корреляции, программа создает корреляционное событие. Эти события можно фильтровать, обогащать и агрегировать. Их также можно отправить на хранение или в коррелятор на анализ.
Событие аудита. События аудита создаются при выполнении в KUMA определенных действий, связанных с безопасностью, и используются для обеспечения целостности системы. Они автоматически размещаются в отдельном пространстве хранилища и хранятся не менее 365 дней.
Событие мониторинга. Такие события используются для отслеживания изменений в количестве данных, поступающих в KUMA.

В начало

Об алертах

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

KUMA автоматически присваивает уровень важности каждому алерту. Этот параметр показывает, насколько важны или многочисленны процессы, запустившие правило корреляции. В первую очередь следует обрабатывать алерты с более высоким уровнем важности. Значение уровня важности автоматически обновляется при получении новых корреляционных событий, но сотрудник службы безопасности также может задать его вручную. В этом случае уровень важности алерта больше не обновляется автоматически.

К алертам привязаны относящиеся к ним события, благодаря чему происходит обогащение алертов данными из событий. В KUMA также можно детально анализировать алерты.

На основании обнаружений можно создать инциденты.

Работа с алертами в KUMA описана в этом разделе.

В начало

Об инцидентах

Если характер поступающих в KUMA данных, создаваемых корреляционных событий и алертов указывает на возможную атаку или уязвимость, признаки такого происшествия можно объединить в инцидент. Это позволяет специалистам службы безопасности анализировать проявления угрозы комплексно и облегчает реагирование.

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

Инциденты можно экспортировать в НКЦКИ.

В начало

Об активах

Активы – это сетевые устройства, зарегистрированные в KUMA. Активы генерируют сетевой трафик при отправке и получении данных. Программа KUMA может быть настроена для отслеживания этой активности и создания базовых событий с четким указанием того, откуда исходит трафик и куда он направляется. В событии могут быть записаны исходные и целевые IP-адреса, а также DNS-имена. Если вы регистрируете актив с определенными параметрами (например, конкретным IP-адресом), формируется связь между этим активом и всеми событиями, в которых указаны эти параметры (в нашем случае IP-адрес).

Активы можно разделить на логические группы. Это позволяет создать прозрачную структуру вашей сети, а также дает дополнительные возможности при работе с правилами корреляции. Когда обрабатывается событие, к которому привязан актив, категория этого актива также принимается во внимание. Например, если вы присвоите высокий уровень важности определенной категории активов, то связанные с этими активами базовые события породят корреляционные события с более высоким уровнем важности. Это, в свою очередь, приведет к появлению обнаружений с более высоким уровнем важности и, следовательно, более быстрой реакцией на такой алерт.

Рекомендуется регистрировать сетевые активы в KUMA, поскольку их использование позволяет формулировать четкие и универсальные правила корреляции для более эффективного анализа событий.

Работа с активами в KUMA описана в этом разделе.

В начало

О ресурсах

Ресурсы – это компоненты KUMA, которые содержат параметры для реализации различных функций: например, установления связи с заданным веб-адресом или преобразования данных по определенным правилам. Из этих компонентов, как из частей конструктора, собираются наборы ресурсов для сервисов, на основе которых в свою очередь создаются сервисы KUMA.

В начало

О сервисах

Сервисы – это основные компоненты KUMA, с помощью которых осуществляется работа с событиями: получение, обработка, анализ и хранение. Каждый сервис состоит из двух частей, работающих вместе:

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

Между собой части сервисов соединены с помощью идентификатора сервисов.

В начало

Об агентах

Агенты KUMA – это сервисы, которые используются для пересылки необработанных событий с серверов и рабочих станций в точки назначения KUMA.

Типы агентов:

wmi – используются для получения данных с удаленных устройств Windows с помощью Windows Management Instrumentation. Устанавливается на устройства Windows.
wec – используются для получения журналов Windows с локального устройства с помощью Windows Event Collector. Устанавливается на устройства Windows.
tcp – используются для получения данных по протоколу TCP. Устанавливается на устройства Linux и Windows.
udp – используются для получения данных по протоколу UDP. Устанавливается на устройства Linux и Windows.
nats-jetstream – используются для коммуникации через NATS. Устанавливается на устройства Linux и Windows.
kafka – используются для коммуникации с помощью kafka. Устанавливается на устройства Linux и Windows.
http – используются для связи по протоколу HTTP. Устанавливается на устройства Linux и Windows.
file – используются для получения данных из файла. Устанавливается на устройства Linux.
ftp – используются для получения данных по протоколу File Transfer Protocol. Устанавливается на устройства Linux и Windows.
nfs – используются для получения данных по протоколу Network File System. Устанавливается на устройства Linux и Windows.
snmp – используются для получения данных с помощью Simple Network Management Protocol. Устанавливается на устройства Linux и Windows.
diode – используются вместе с диодами данных для получения событий из изолированных сегментов сети. Устанавливается на устройства Linux и Windows.

В начало

Об уровне важности

Параметр Уровень важности отражает, насколько чувствительны для безопасности происшествия, обнаруженные коррелятором KUMA. Он показывает порядок, в котором следует обрабатывать алерты, а также указывает, требуется ли участие старших специалистов по безопасности.

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

Уровень важности алерта можно изменить вручную. Измененный вручную уровень важности перестает автоматически обновляться правилами корреляции.

Возможные значения уровня важности:

Низкий
Средний
Высокий
Критический

В начало