О событиях
События – это события информационной безопасности, зарегистрированные на контролируемых элементах 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.
В начало