Мониторинг событий

Мониторинг событий использует логическую шину для транспортировки информации о событиях от источников к подписчикам, где источники событий сигнализируют о наступлении события всем подписчикам, а подписчики событий принимают эти сообщения. Шина событий может быть распределена между множеством физических узлов, такими как отдельные компьютерные системы. Типичные примеры шин событий встречаются в графических интерфейсах, например, Microsoft Windows. В качестве современных распределённых шин событий применяются Apache Kafka, NATS и AWS EventBridge^[5][6], а для распределённой трассировки используются инструменты Jaeger и Honeycomb^[7].

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

Объект, подлежащий мониторингу, называют мониторируемым объектом; например, приложение, операционная система, база данных или аппаратное обеспечение. Чтобы объект мог быть мониторируемым, его необходимо оснастить датчиками событий, иначе говоря, провести инструментирование объекта для мониторинга событий. Датчики событий — это компоненты, которые генерируют сигналы при наступлении события. При мониторинге важно учитывать и управлять эффектом зонда.

Как отмечал Дж. Гейт^[8], при мониторинге объекта его поведение может измениться. Особенно актуально это в конкурентных системах, где процессы могут выполняться параллельно. Появление датчиков в системе приводит к возможности изменения порядка выполнения процессов. Такая ситуация может стать проблемой, если, например, ведётся поиск дефекта: само наблюдение (мониторинг) способно изменить поведение системы так, что дефект больше не приведёт к сбою, то есть будет замаскирован мониторингом. Эффект зонда — это разница в поведении между мониторируемым (инструментированным) объектом и эквивалентным без инструментирования.

По мнению В. Шюца^[9], эффект зонда можно избежать, компенсировать или проигнорировать. В критичных реально-временных системах, где временные ограничения (сроки исполнения) жизненно важны, допустима только стратегия избежания эффекта зонда. Если же система инструментируется для тестирования, а затем инструментирование снимается перед внедрением — это делает недействительными итоги тестирования всей системы. В менее критичных реально-временных системах (например, мультимедийные системы) возможна компенсация, например, при тестировании производительности. В неконкурентных (последовательных) системах эффект зонда можно игнорировать, поскольку порядок выполнения не изменяется.

Современным стандартом мониторинга стали технологии OpenTelemetry и eBPF, позволяющие собирать телеметрию на уровне ядра без модификации исходного кода приложений. Это минимизирует накладные расходы и эффект зонда, так как обработка событий происходит непосредственно в ядре и не влияет на производительность самих приложений^[10].^[11].

Анализ журнала событий известен также как композиция событий в активных базах данных, распознавание хроник в искусственном интеллекте, а также как вычисление логики времени реального времени в соответствующих системах. Такой анализ используется для поиска шаблонов (pattern matching), фильтрации и агрегации событий в составные события. Часто применяются стратегии из динамического программирования, позволяющие сохранять результаты прошлых анализов для повторного использования, ведь одна и та же последовательность событий может встречаться несколько раз в ходе обработки. В отличие от обработки правил в общем виде (как в инференс-машинах) с применением техники возврата (backtracking), алгоритмы анализа событий, как правило, являются жадными: объявленные составные события не отменяются, что допустимо при backtracking.

Для анализа журнала событий предлагаются различные механизмы: конечный автомат, сети Петри, процедурные решения (на базе императивных или объектно-ориентированных языков), модификации алгоритма Бойера — Мура, простые темпоральные сети, а также современные реализации темпоральной логики (например, интеграция LTL-мониторинга в Apache Spark).

В современных системах активно применяются нейросетевые архитектуры (такие как Transformer и LSTM) для прогнозирования аномалий и распознавания хроник событий^[12][13]. Решения на базе AIOps используются для интеллектуальной фильтрации и снижения избыточности уведомлений (Alert Fatigue) путём объединения разрозненных сигналов в единые инциденты^[14]. Кроме того, для поиска первопричин сбоев (Root Cause Analysis) применяется причинно-следственный ИИ (Causal AI), который реконструирует цепочки зависимостей в момент возникновения инцидента^[15].

Интеграция мониторинга событий с системами информационной безопасности образует единый контур для обнаружения киберугроз и реагирования на них. В этой связке SIEM-системы выполняют централизованный сбор и анализ журналов событий, а системы SOAR автоматизируют процессы реагирования. Для автоматизации применяются плейбуки (playbooks) — заранее заданные сценарии, которые инициируются при поступлении оповещений от SIEM или других средств защиты. Плейбуки позволяют автоматически выполнять такие действия, как проверка индикаторов компрометации, блокировка вредоносного программного обеспечения и изоляция скомпрометированных узлов сети^[16].^[17][18]

Для точной идентификации угроз и выявления отклонений от нормального поведения применяется поведенческий анализ пользователей и сущностей (UEBA)^[19][17]. В отличие от классической корреляции событий, UEBA использует методы машинного обучения для формирования профилей нормального поведения. Среди применяемых алгоритмов — робастный метод главных компонент (RPCA) для поиска аномалий времени и количества, цепи Маркова для выявления нестандартных последовательностей событий, а также изолирующие леса (Isolation Forests) для обнаружения комплексных аномалий^[20][21]. При фиксации подозрительных отклонений система автоматически передает предупреждение в SIEM или SOAR для инициации ответных мер.

Для российских систем мониторинга важным аспектом является соответствие требованиям ФСТЭК. Сертифицированные SIEM-системы должны обеспечивать централизованный сбор событий, выявление угроз с использованием механизмов корреляции и матриц атак, а также автоматическую интеграцию с ГосСОПКА для передачи данных об инцидентах^[22].