Alerta, Evento, Incidente y Ofensa: las diferencias que todo analista debe conocer

Evento: La observación básica

Un Evento es un registro de una acción, estado o cambio. Ejemplos: inicio de sesión exitoso, falla de autenticación, creación de Proceso, consulta DNS, cambio de Política o conexión de red. La mayoría de los Eventos son legítimos; su valor proviene de los campos y el contexto.

Un Evento puede provenir de un Log Raw, Telemetría de EDR, Audit Log en la nube o Flujo en la red. El SIEM realiza Parsing y normalización para mostrar campos uniformes, pero el registro aún no afirma que haya ocurrido un ataque.

La calidad del Evento depende de la fuente: Timestamp, Host, User, Action, Result y un identificador único. Un Evento faltante o erróneo puede causar una Alerta engañosa, por lo que una investigación profesional a veces vuelve a los Raw Data.

Alerta: Señal generada por la lógica

Una Alerta se crea cuando una regla, modelo, firma o Analytics identifica una coincidencia. Puede basarse en un único Evento, una secuencia, un Umbral, una Anomalía o un IOC. Una Alerta dice “es conveniente investigar”, no “el evento es malicioso”.

Una Alerta generalmente incluye Título, Gravedad, hora, Entidades, Evidencia y nombre de Detección. Puede ser un True Positive, Benign Positive o False Positive. El papel del Triage es determinar si hay suficiente contexto para abrir una investigación, cerrar o enriquecer.

En diferentes sistemas, una Alerta puede denominarse Detección, Hallazgo o Señal. Es importante verificar en la documentación del producto si se trata de un resultado sin procesar, una agregación o ya un objeto de investigación.

Incidente: Historia de investigación y respuesta

Un Incidente centraliza Alertas, Entidades, Evidencia, Línea de tiempo y acciones en torno a un escenario. En Microsoft Defender XDR, las Alertas relacionadas se agrupan para presentar la historia del ataque en Endpoint, Identidad, Correo electrónico y Nube. Un Incidente puede actualizarse a medida que llega nueva información.

A nivel organizacional, un Incidente no es solo un objeto técnico. Incluye Propietario, Estado, Gravedad, Clasificación, Tareas, Comentarios y respuesta. Es posible que una Alerta real no se convierta en Incidente si tiene un impacto insignificante y se gestiona automáticamente; y es posible que se abra un Incidente manualmente debido a un informe de usuario, incluso sin una Alerta automática.

El término debe estar relacionado con los criterios de la organización: cuándo un hallazgo se convierte en un evento que requiere Respuesta, quién está autorizado para declararlo y cómo se cierra.

Ofensa en QRadar

QRadar recopila Eventos y Flujos y ejecuta un Custom Rule Engine. Cuando se cumplen las condiciones, una Regla puede contribuir a la creación de una Ofensa. Una Ofensa agrupa los Eventos y Flujos relacionados y presenta el Contexto para la investigación.

Una Ofensa no es una palabra genérica para cualquier Incidente. Es un objeto específico del modelo de QRadar. Incluye Magnitud calculada según la Gravedad, Relevancia, Credibilidad y otros factores. El analista abre la Ofensa, verifica Reglas, Eventos, Origen/Destino, Activos, Notas y Línea de tiempo.

A veces, una Ofensa representa una sospecha de política o ataque, pero aún debe clasificarse. Puede cerrarse como False Positive, Non-Issue, Policy Violation o según la taxonomía local.

Hallazgo, Caso y Detección

Un Hallazgo es un descubrimiento que requiere atención, común en las herramientas de Nube y Vulnerabilidad. Una Detección puede ser la lógica de detección o su resultado, según el producto. Un Caso es una envoltura de trabajo amplia que agrupa varios Incidentes o una investigación entre sistemas.

En lugar de discutir sobre “la palabra correcta”, construya un glosario organizacional: el nombre del término, la fuente, qué representa, quién es el Propietario, qué Estados existen y qué lo crea o lo cierra. El glosario es especialmente importante cuando se conectan varios productos a un SOAR.

Cadena de ejemplo de Log a Incidente

1. Un Domain Controller registra un Evento de cincuenta fallos de inicio de sesión desde una dirección. 2. Una SIEM Rule cuenta los eventos en una ventana de cinco minutos y crea una Alerta de Password Spray. 3. Otra Alerta muestra un inicio de sesión exitoso para uno de los usuarios. 4. Un motor de correlación unifica las dos Alertas en un Incidente. 5. El analista verifica el Alcance, invalida las Sesiones y clasifica el Incidente como True Positive.

En QRadar, los mismos Eventos y Flujos pueden activar Reglas y crear una Ofensa que muestra el origen del ataque, los usuarios, la Magnitud y los Eventos contribuyentes. La información es similar, pero los nombres y las relaciones entre los objetos son diferentes.

Tabla comparativa

Ejercicio de clasificación

Lista de verificación práctica

• ✓He comprobado la definición del término en la documentación del producto.
• ✓Conozco el origen y el Trigger de cada objeto.
• ✓No he tratado la Alerta como prueba de un ataque.
• ✓He vinculado Eventos a Alertas e Incidentes mediante identificadores.
• ✓He documentado la Clasificación y el Propietario.
• ✓He construido un glosario de términos para el equipo y el SOAR.

Errores comunes

• Llamar a cada línea de log “Incidente”.
• Usar Ofensa fuera del contexto de QRadar como si fuera un estándar general.
• Contar Eventos e Incidentes con la misma métrica.
• Cerrar una Alerta sin verificar si es parte de un Incidente más amplio.
• Asumir que los términos son idénticos entre Sentinel, Defender, QRadar y Elastic.
• No mantener la conexión entre los objetos en el sistema de Ticketing.

Resumen y CTA

Abra un SIEM o un escenario de laboratorio y elija diez elementos. Marque para cada uno si es un Evento, Alerta, Incidente, Ofensa o Hallazgo y explique quién lo creó. Luego, vaya al artículo “Qué es un SIEM y cómo funciona” para comprender el flujo de datos completo. En el curso HPI, se practican los términos dentro de las herramientas de investigación y no solo como definiciones.

Preguntas frecuentes