Ciberseguridad y seguridad de la información

Offense de QRadar: Cómo leer e investigar un Offense

6 min de lecturaPublicado: 5 de agosto de 2026

Ilustración visual profesional sobre la investigación de Offense en QRadar en el ámbito de SIEM y la detección

Respuesta rápida

Un Offense en QRadar es un caso priorizado que se genera cuando el Custom Rules Engine correlaciona Events o Flows según una regla. Una investigación profesional no comienza y termina con la Magnitud: se debe comprender la regla que disparó el Offense, abrir los eventos y los flujos que contribuyen, verificar la Fuente, el Destino, los activos, el tiempo y el contexto empresarial, y luego documentar una decisión y una Razón de cierre.

IBM QRadar recibe Events de fuentes de registro y Flows de fuentes de tráfico, los procesa a través de su Custom Rules Engine — CRE — y puede generar un Offense cuando se cumplen las condiciones de una Rule. Un Offense centraliza la información necesaria para la priorización y la investigación, pero no es prueba de que haya ocurrido un ataque. Es un caso que dice: “el sistema de detección observó un patrón que justifica una revisión”.

El error común es mirar la Magnitud, abrir algunos Events recientes y cerrar. La Magnitud ayuda a la priorización, pero QRadar la calcula a partir de una combinación de Relevancia, Severidad y Credibilidad y también considera factores como el número de Events y Flows, el número de fuentes, la antigüedad del Offense, el peso de los activos y el contexto de las Vulnerabilidades. Por lo tanto, el caso debe desglosarse en sus componentes.

Qué genera un Offense

Una Rule en QRadar es un conjunto de Tests que se aplican a un Event, Flow, serie de eventos, Offense u otra combinación, dependiendo del tipo de regla. Cuando se cumplen las condiciones, la Response puede crear un Offense, añadir datos a un Reference set, enviar una notificación o realizar otra acción. El nombre de la Rule es solo un punto de partida; el analista debe entender la pila de Tests y el Scope de los datos.

Antes de abrir Raw events, pregúntese: ¿Es una Event rule o una Flow rule? ¿Es un Threshold en una ventana de tiempo? ¿La condición es Stateful? ¿La Rule se basa en un Building Block que define un grupo, por ejemplo, “servidores de correo” o “escáneres de vulnerabilidades”? ¿El Offense está asociado a una Source IP, Destination IP, Username o alguna otra característica?

Campo en el Offense	Qué significa	Qué NO significa
Rule(s)	Qué lógica contribuyó a la creación	Que la lógica es correcta en el entorno actual
Magnitude	Métrica de priorización calculada	Probabilidad de intrusión
Source/Destination	La entidad a la que QRadar asoció el caso	Necesariamente el atacante y la víctima
Event/Flow count	Volumen de registros que contribuyen	Número de acciones únicas
Start/Last event	Ventana observada en el Offense	Necesariamente el inicio y el fin del evento real

Magnitude, Relevance, Credibility y Severity

Magnitude mide la importancia del Offense en el entorno y se utiliza para la clasificación. Relevance se refiere al impacto potencial en la red y los activos. Credibility representa la fiabilidad de la señal y está influenciada, entre otras cosas, por la fiabilidad de la fuente de registro y el refuerzo de fuentes adicionales. Severity se refiere al nivel de amenaza en relación con la preparación del objetivo. QRadar reevalúa la Magnitude cuando se añaden datos y en momentos programados.

No interprete cada puntuación por separado sin comprender los datos. Una Credibility alta de una fuente no garantiza que el evento sea malicioso; un Parser podría clasificar una actividad legítima como una categoría grave. Una Relevance alta puede deberse a un activo crítico, pero si el objetivo es un Honeypot o Lab, el contexto es diferente. Una Severity alta puede estar justificada en términos del tipo de evento, aunque la acción haya sido bloqueada.

Events y Flows: dos lentes

Un Event generalmente describe un registro de log: autenticación, denegación de Firewall, proceso, auditoría o un evento de aplicación. Un Flow describe una conversación o comunicación de red: origen, destino, Ports, Protocol, Bytes, Packets y tiempos. Un Offense puede incluir uno o ambos. Conectar un Event y un Flow permite verificar no solo “qué informó el producto”, sino también “si el tráfico ocurrió y cuál fue su alcance”.

En la investigación, abra la lista de Events, ordene por tiempo y categoría, y verifique QID, Log Source, Username, Payload y campos personalizados. Luego pase a los Flows: ¿el Source se comunicó con el destino? ¿Hubo comunicación bidireccional? ¿Cuál fue el volumen de datos? ¿El Port coincide con el servicio esperado? La ausencia de un Flow no prueba que no hubo comunicación; es posible que no haya cobertura de NetFlow en ese segmento.

Source, Destination y Assets

QRadar asocia un Offense según la “Offense source” determinada por la regla y los eventos. A veces, el Source es una dirección externa, a veces un usuario, un Host interno o un destino. No asuma que el campo Source es siempre el atacante. En el ejemplo de devolución de llamada de Malware, un Source interno puede ser una estación de trabajo comprometida; en el ejemplo de Scan, el Source puede ser un escáner organizacional autorizado.

El contexto del Asset cambia la priorización: un servidor Domain Controller, una estación de administración y un servidor de pruebas no son lo mismo. Verifique el Asset weight, Owner, Network hierarchy, aperturas, Vulnerabilities y conexiones empresariales. Si QRadar no identifica el activo o lo identifica con un nombre antiguo, señálelo como una falta de evidencia.

Flujo de trabajo de investigación de un Offense

Lea la Description, Rule(s), Offense type, Source, Destination, Magnitude, Start time y Last event.
Abra la Rule o los detalles de la regla y comprenda los Tests, Threshold, la ventana de tiempo y los Building Blocks.
Revise los Events que contribuyen. Agrupe por QID, Log Source, Username, Source y Destination para identificar repeticiones y duplicidades.
Verifique los Flows relacionados, si existen, y busque comunicaciones antes y después del Event principal.
Valide la Network hierarchy y el Asset profile. Pregunte si las direcciones son internas, VPN, NAT, Proxy o Shared infrastructure.
Construya un Timeline y una búsqueda complementaria en Log Activity y Network Activity para un rango más amplio.
Verifique otros Offenses en los mismos activos, usuarios, Domains o Rules. La correlación entre casos puede ampliar el Scope.
Clasifique, documente Notes, asigne un Owner y decida si escalar, cerrar o mantener en seguimiento.

Escenario: Múltiples fuentes frente a un destino crítico

En el laboratorio se generó un Offense llamado “Multiple authentication failures followed by success” en un servidor de archivos crítico. La Magnitude es 8, existen 180 Events de tres Log Sources, y el Offense source es una IP interna. La tabla de trabajo podría verse así:

Verificación	Hallazgo	Posible significado	Siguiente paso
Rule	Muchos fallos y luego éxito	Password spray o servicio con contraseña antigua	Verificar usuarios y orden cronológico
Log Sources	AD, VPN, File server	Varias capas refuerzan la historia	Verificar Time sync y NAT
Source IP	Servidor de administración	Puede ser una herramienta de automatización	Verificar Owner y Change window
Target	Servidor de archivos de Producción	Alto impacto empresarial	Verificar Access y actividad de archivos
Flows	SMB después del éxito	Comunicación real	Verificar Bytes, Sessions y destinos adicionales

Si el Source es un servidor de administración y los fallos corresponden a un Job que falló después de un cambio de contraseña, podría ser un Benign Positive. Pero un Success seguido de SMB a un Share sensible aún requiere la verificación de la cuenta y la acción. Si no hay un Change aprobado, se debe escalar a IR o al equipo de identidades según el Playbook.

Cierre, Notes y Tuning

Las Notes deben incluir la hipótesis, evidencia, búsquedas realizadas, deficiencias, Classification y acciones. La Closing Reason debe ser consistente para permitir Metrics y Tuning. “False Positive” sin explicación no es suficiente; especifique si la causa raíz es un escáner autorizado, un Parser incorrecto, un Threshold, un Duplicate, un Asset context o una actividad de usuario legítima.

El Tuning puede incluir la modificación de la Rule, Building Block, Reference set, Network hierarchy, Log source credibility o Asset weight. Cada cambio debe tener un Owner, documentación, prueba de Regression y una fecha de Review. No excluya una Source IP completa si solo se puede excluir un Event name, Destination, ventana de mantenimiento o Service account.

Checklist

Comprendí qué generó el Offense y qué Rules contribuyeron.
Descompuse la Magnitude en sus componentes de contexto y no la usé como prueba.
Verifiqué Events y también Flows cuando existían.
Validé Source, Destination, NAT, Proxy y Network hierarchy.
Verifiqué la Asset criticality y Vulnerabilities.
Construí un Timeline y busqué actividad antes y después.
Escribí Notes y Closing Reason detalladas.
Implementé un Tuning enfocado con Owner y fecha de Review.

Errores comunes

Cerrar por Magnitude baja sin abrir los eventos.
Asumir que el Offense source es el atacante.
Contar Events sin verificar duplicidades o Aggregation.
Ignorar Flows o la falta de cobertura de tráfico.
Confiar en un Asset profile desactualizado.
Modificar una Rule en producción sin una Baseline y Regression test.

Resumen y CTA

Elija un Offense de laboratorio y escriba una página de investigación: qué lo generó, qué significa la Magnitude, qué Events y Flows contribuyen, quién es el Source y el Destination, cuál es el Asset context y cuál es la decisión de cierre. Luego compare su página con un Ticket de otro analista. Este ejercicio enseña a trabajar con QRadar como una plataforma de investigación y no solo como una cola de alertas.

Preguntas frecuentes

¿Cuál es la diferencia entre Event y Offense?

Un Event es un registro de origen o un evento normalizado. Un Offense es un caso que se genera después de que el CRE correlaciona datos según una Rule y añade priorización y contexto.

¿Es Magnitude 10 siempre más grave que 8?

Se prioriza más alto según el cálculo de QRadar, pero la decisión de la investigación debe incluir activos, evidencia, tipo de regla y contexto empresarial.

¿Qué es un Flow en la investigación?

Un registro de tráfico resumido que muestra las características de una conversación. Puede confirmar la comunicación, el volumen y el protocolo, pero no siempre incluye el Payload.

¿Cuándo se cierra un Offense como False Positive?

Solo después de tener una explicación fundada y evidencia de que la lógica identificó una actividad que no es la amenaza prevista. A veces, la clasificación correcta es Benign Positive o Duplicate.

¿Un cambio en la Closing Reason modifica la Rule?

No. La Closing Reason documenta el resultado de la investigación. El Tuning requiere un cambio proactivo en la Rule, Building Block, Reference set u otro Contexto.