Кибербезопасность и информационная безопасность

QRadar Offense: как читать и расследовать Offense

6 мин чтенияОпубликовано: 5 августа 2026 г.

Профессиональная визуальная иллюстрация по расследованию Offense в QRadar в области SIEM и обнаружения

Быстрый ответ

Offense в QRadar — это приоритезированный инцидент, создаваемый, когда Custom Rules Engine связывает Events или Flows в соответствии с правилом. Профессиональное расследование не начинается и не заканчивается Magnitude: необходимо понять сработавшее правило, открыть способствующие события и потоки, проверить Source, Destination, активы, время и бизнес-контекст, а затем задокументировать решение и Closing Reason.

IBM QRadar получает Events из источников логов и Flows из источников трафика, пропускает их через Custom Rules Engine — CRE — и может создавать Offense при выполнении условий Rule. Offense собирает необходимую информацию для приоритизации и расследования, но не является доказательством того, что произошло нарушение. Это Case, который говорит: «Система обнаружения увидела паттерн, который требует проверки».

Распространенная ошибка — смотреть на Magnitude, открывать несколько последних Events и закрывать. Magnitude действительно помогает приоритизировать, но QRadar рассчитывает его из комбинации Relevance, Severity и Credibility, а также учитывает такие факторы, как количество Events и Flows, количество источников, возраст Offense, вес активов и контекст уязвимостей. Поэтому необходимо разбить инцидент на составляющие.

Что создает Offense

Rule в QRadar — это набор Tests, которые применяются к Event, Flow, серии событий, Offense или другой комбинации в зависимости от типа правила. Когда условия выполняются, Response может создать Offense, добавить данные в Reference set, отправить уведомление или выполнить другое действие. Название Rule — это только отправная точка; аналитик должен понимать Test stack и Scope данных.

Перед открытием Raw events, спросите: это Event rule или Flow rule? Это Threshold во временном окне? Условие Stateful? Основывается ли Rule на Building Block, который определяет группу, например, «почтовые серверы» или «сканеры уязвимостей»? Связан ли Offense с Source IP, Destination IP, Username или другим атрибутом?

Поле в Offense	Что оно означает	Что оно не означает
Rule(s)	Какая логика способствовала созданию	Что логика верна в текущей среде
Magnitude	Рассчитанная метрика приоритизации	Вероятность взлома
Source/Destination	Сущность, с которой QRadar связал инцидент	Обязательно злоумышленник и жертва
Event/Flow count	Объем способствующих записей	Количество уникальных действий
Start/Last event	Наблюдаемое окно в Offense	Обязательно начало и конец реального инцидента

Magnitude, Relevance, Credibility и Severity

Magnitude измеряет важность Offense в среде и используется для сортировки. Relevance относится к возможному влиянию на сеть и активы. Credibility представляет надежность сигнала и зависит, среди прочего, от надежности источника логов и подтверждения из дополнительных источников. Severity относится к уровню угрозы по отношению к готовности цели. QRadar переоценивает Magnitude при добавлении данных и по расписанию.

Не следует интерпретировать каждую оценку отдельно, не понимая данных. Высокая Credibility из одного источника не гарантирует, что событие вредоносно; возможно, Parser классифицирует легитимную активность как серьезную категорию. Высокая Relevance может быть вызвана критическим активом, но если цель — Honeypot или Lab, контекст иной. Высокая Severity может быть оправдана с точки зрения типа события, даже если действие было заблокировано.

Events и Flows: две линзы

Event обычно описывает запись лога: Authentication, Firewall deny, Process, Audit или прикладное событие. Flow описывает сетевую сессию или связь: источник, назначение, Ports, Protocol, Bytes, Packets и время. Offense может включать одно из них или оба. Соединение Event и Flow позволяет проверить не только «что сообщил продукт», но и «произошел ли трафик и каков был его объем».

При расследовании откройте список Events, отсортируйте по времени и категории, и проверьте QID, Log Source, Username, Payload и пользовательские поля. Затем перейдите к Flows: обращался ли Source к цели? Была ли двусторонняя связь? Каков был объем данных? Соответствует ли Port ожидаемой службе? Отсутствие Flow не доказывает отсутствие связи; возможно, нет покрытия NetFlow в этом Segment.

Source, Destination и Assets

QRadar связывает Offense по «Offense source», определяемому правилом и событиями. Иногда Source — это внешний адрес, иногда пользователь, внутренний Host или цель. Не предполагайте, что поле Source всегда является злоумышленником. В примере обратного вызова вредоносного ПО, внутренний Source может быть скомпрометированной станцией; в примере Scan, Source может быть авторизованным корпоративным Scanner.

Контекст Asset изменяет приоритизацию: контроллер домена, административная станция и тестовый сервер не одинаковы. Проверьте Asset weight, Owner, Network hierarchy, открытые порты, Vulnerabilities и бизнес-связи. Если QRadar не распознает актив или распознает его под старым именем, укажите это как недостаток в доказательствах.

Рабочий процесс расследования Offense

Прочитайте Description, Rule(s), Offense type, Source, Destination, Magnitude, Start time и Last event.
Откройте Rule или детали правила и поймите Tests, Threshold, временное окно и Building Blocks.
Просмотрите способствующие Events. Сгруппируйте по QID, Log Source, Username, Source и Destination, чтобы выявить повторяющиеся и дублирующиеся записи.
Проверьте связанные Flows, если они есть, и ищите трафик до и после центрального Event.
Проверьте Network hierarchy и Asset profile. Спросите, являются ли адреса внутренними, VPN, NAT, Proxy или Shared infrastructure.
Постройте Timeline и выполните дополнительный поиск в Log Activity и Network Activity для более широкого диапазона.
Проверьте дополнительные Offenses на тех же активах, пользователях, Domains или Rules. Связь между инцидентами может расширить Scope.
Классифицируйте, документируйте Notes, назначьте Owner и решите, эскалировать ли, закрыть или оставить для наблюдения.

Сценарий: несколько источников против критической цели

В лаборатории был создан Offense под названием «Multiple authentication failures followed by success» на критическом файловом сервере. Magnitude составляет 8, имеется 180 Events из трех Log Sources, а Offense source — это внутренний IP. Рабочая таблица может выглядеть следующим образом:

Проверка	Результат	Возможное значение	Следующий шаг
Rule	Множественные сбои, затем Success	Password spray или служба со старым паролем	Проверить пользователей и временную последовательность
Log Sources	AD, VPN, File server	Несколько слоев усиливают историю	Убедиться в синхронизации времени и NAT
Source IP	Сервер управления	Может быть инструментом автоматизации	Проверить Owner и Change window
Target	Файловый сервер Production	Высокое бизнес-влияние	Проверить Access и файловую активность
Flows	SMB после Success	Фактическая связь	Проверить Bytes, Sessions и дополнительные цели

Если Source — это сервер управления и сбои соответствуют неудачному Job после смены пароля, возможно Benign Positive. Но Success и последующий SMB к чувствительному Share все еще требуют проверки учетной записи и действия. Если нет утвержденного Change, необходимо эскалировать в IR или команду по идентификации в соответствии с Playbook.

Закрытие, Notes и Tuning

Notes должны включать гипотезу, доказательства, выполненные поиски, пробелы, Classification и действия. Closing Reason должен быть последовательным, чтобы обеспечить Metrics и Tuning. «False Positive» без объяснения недостаточно; укажите, является ли причиной авторизованный Scanner, ошибочный Parser, Threshold, Duplicate, Asset context или легитимная активность пользователя.

Tuning может включать изменение Rule, Building Block, Reference set, Network hierarchy, Log source credibility или Asset weight. Каждое изменение должно иметь Owner, документацию, Regression test и дату Review. Не исключайте весь Source IP, если можно исключить только Event name, Destination, окно обслуживания или Service account.

Checklist

Я понял, что создало Offense и какие Rules способствовали.
Я разложил Magnitude на компоненты контекста и не использовал его в качестве доказательства.
Я проверил Events, а также Flows, когда они доступны.
Я проверил Source, Destination, NAT, Proxy и Network hierarchy.
Я проверил Asset criticality и Vulnerabilities.
Я построил Timeline и искал активность до и после.
Я написал подробные Notes и Closing Reason.
Я провел целенаправленный Tuning с Owner и датой Review.

Распространенные ошибки

Закрывать по низкому Magnitude, не открывая события.
Предполагать, что Offense source является злоумышленником.
Считать Events без проверки дубликатов или Aggregation.
Игнорировать Flows или отсутствие покрытия трафика.
Полагаться на устаревший Asset profile.
Изменять Rule в Production без Baseline и Regression test.

Резюме и CTA

Выберите лабораторный Offense и напишите одностраничный лист расследования: что его создало, что говорит Magnitude, какие Events и Flows способствуют, кто Source и Destination, каков Asset context и каково решение о закрытии. Затем сравните этот лист с Ticket другого аналитика. Упражнение учит работать с QRadar как с местом расследования, а не только как с очередью предупреждений.

Вопросы и ответы

В чем разница между Event и Offense?

Event — это исходная запись или нормализованное событие. Offense — это Case, созданный после того, как CRE связал данные в соответствии с Rule и добавил приоритизацию и контекст.

Magnitude 10 всегда серьезнее, чем 8?

Он приоритизируется выше по расчету QRadar, но решение о расследовании должно включать активы, доказательства, тип правила и бизнес-контекст.

Что такое Flow в расследовании?

Суммированная запись трафика, которая показывает характеристики сессии. Она может подтвердить связь, объем и протокол, но не всегда включает Payload.

Когда Offense закрывается как False Positive?

Только после того, как есть обоснованное объяснение и доказательства того, что логика идентифицировала активность, не являющуюся предполагаемой угрозой. Иногда правильная классификация — Benign Positive или Duplicate.

Изменяет ли изменение Closing Reason правило?

Нет. Closing Reason документирует результат расследования. Tuning требует инициированного изменения в Rule, Building Block, Reference set или другом Context.