15. Gestión de alertas: severidad, falsos positivos, correlación, priorización y escalamiento

15.1 Introducción

Los firewalls, IDS/IPS, EDR, SIEM, servidores y servicios en la nube pueden generar muchas alertas. Algunas indican incidentes reales. Otras son ruido, errores de configuración, actividad esperada o eventos de baja importancia.

El desafío no es recibir más alertas, sino gestionarlas mejor. Una organización puede tener muchas herramientas y aun así responder tarde si no sabe priorizar, correlacionar, escalar y cerrar alertas correctamente.

En este tema veremos cómo clasificar alertas, reducir falsos positivos, usar contexto, definir prioridades y establecer un proceso de escalamiento.

15.2 Qué es una alerta

Una alerta es una señal generada por un sistema cuando detecta una condición que merece atención. Puede originarse en una firma IDS, una regla SIEM, un bloqueo IPS, un cambio administrativo, una anomalía de tráfico o un evento de autenticación.

Una buena alerta debe incluir suficiente contexto para tomar una decisión inicial:

• Qué ocurrió.
• Cuándo ocurrió.
• Qué activo está involucrado.
• Qué usuario o dirección IP aparece asociada.
• Qué severidad tiene.
• Qué evidencia la respalda.
• Qué acción se recomienda o qué procedimiento aplica.

15.3 Alerta no es incidente

Una alerta no siempre significa que existe un incidente. Una alerta es una señal. Un incidente es un evento confirmado o altamente probable que afecta confidencialidad, integridad, disponibilidad o cumplimiento de la organización.

Ejemplo: un IDS alerta por un intento de explotación contra un servidor. Si el servidor no es vulnerable y el intento fue bloqueado, puede ser un evento relevante pero no necesariamente un incidente. Si el servidor era vulnerable y luego aparecen comandos sospechosos, la prioridad cambia.

15.4 Severidad

La severidad representa el impacto potencial de una alerta. No debe depender solo de la herramienta; debe considerar el contexto del entorno.

15.5 Confianza

La confianza indica qué tan probable es que la alerta represente una amenaza real. Una alerta puede ser muy severa pero tener baja confianza, o ser de baja severidad pero muy confiable.

Ejemplos:

• Alta severidad y alta confianza: malware confirmado en un servidor crítico.
• Alta severidad y baja confianza: regla genérica detecta posible explotación sin evidencia adicional.
• Baja severidad y alta confianza: escaneo externo bloqueado automáticamente.
• Media severidad y media confianza: comportamiento anómalo que requiere enriquecimiento.

Evaluar severidad y confianza juntas mejora la priorización.

15.6 Falsos positivos

Un falso positivo ocurre cuando una alerta indica actividad maliciosa o riesgosa, pero en realidad la actividad es legítima o esperada. Los falsos positivos consumen tiempo y pueden generar fatiga.

Causas comunes:

• Firmas demasiado generales.
• Falta de contexto sobre aplicaciones legítimas.
• Herramientas administrativas detectadas como sospechosas.
• Escaneos autorizados de vulnerabilidades.
• Umbrales demasiado sensibles.
• Cambios de arquitectura no reflejados en reglas.

15.7 Falsos negativos

Un falso negativo ocurre cuando una actividad maliciosa no genera alerta. Es más difícil de medir porque, por definición, el sistema no avisó.

Causas comunes:

• Firmas desactualizadas.
• Tráfico cifrado sin visibilidad suficiente.
• Sensores mal ubicados.
• Alertas deshabilitadas por ruido excesivo.
• Falta de telemetría de host.
• Ataques que imitan comportamiento legítimo.

Reducir falsos negativos requiere cobertura, actualización, pruebas y correlación.

15.8 Enriquecimiento de alertas

Enriquecer una alerta significa agregar contexto para entenderla mejor. Una alerta básica puede decir "conexión sospechosa"; una alerta enriquecida indica activo, criticidad, usuario, historial, reputación del destino y eventos relacionados.

Fuentes de enriquecimiento:

• Inventario de activos.
• Criticidad del sistema afectado.
• Usuario autenticado.
• Datos de EDR o agente de host.
• Reputación de IP, dominio o URL.
• Vulnerabilidades conocidas del activo.
• Historial de alertas previas.
• Información de cambios recientes.

15.9 Correlación

Correlacionar significa relacionar varios eventos para obtener una lectura más completa. Una señal aislada puede ser débil, pero varias señales conectadas pueden indicar un incidente.

Ejemplo de correlación:

1. Un usuario inicia sesión desde una ubicación inusual.
2. Minutos después, su equipo intenta acceder a servidores por puertos administrativos.
3. El IDS detecta un patrón de escaneo interno.
4. El EDR informa ejecución de una herramienta no autorizada.
5. El SIEM agrupa los eventos y eleva la severidad.

15.10 Priorización

Priorizar es decidir qué alertas se atienden primero. No debe basarse solo en el orden de llegada. Debe considerar impacto, confianza, criticidad del activo, exposición y actividad observada.

15.11 Cola de alertas

Una cola de alertas es el conjunto de eventos pendientes de revisión. Debe administrarse para evitar acumulación sin control.

Buenas prácticas:

• Separar alertas por severidad.
• Asignar responsables.
• Definir tiempos esperados de revisión.
• Cerrar alertas con motivo claro.
• Escalar alertas que superan cierto umbral de riesgo.
• Revisar tendencias de acumulación.

15.12 Estados de una alerta

Definir estados ayuda a ordenar el trabajo y medir avance.

15.13 Escalamiento

Escalar una alerta significa derivarla a otra persona, equipo o nivel de respuesta porque requiere más autoridad, conocimiento o acción.

Puede escalarse a:

• Equipo de redes, si requiere bloqueo o revisión de firewall.
• Equipo de sistemas, si afecta servidores.
• Equipo de endpoints, si requiere aislamiento de una estación.
• Equipo de aplicaciones, si hay indicios de explotación web.
• Responsables de negocio, si hay impacto operativo.
• Equipo de respuesta a incidentes, si se confirma compromiso.

15.14 Criterios de escalamiento

Los criterios de escalamiento deben definirse antes de la emergencia. Si cada analista decide solo por intuición, la respuesta será inconsistente.

Ejemplos de criterios:

• Activo crítico involucrado.
• Cuenta privilegiada afectada.
• Evidencia de explotación exitosa.
• Movimiento lateral detectado.
• Posible exfiltración de datos.
• Repetición de alertas desde el mismo origen.
• Impacto en disponibilidad.
• Necesidad de acción fuera del equipo de monitoreo.

15.15 Playbooks

Un playbook es una guía de respuesta para un tipo de alerta o incidente. Define pasos, responsables, evidencias a recolectar y criterios de decisión.

Un playbook básico puede incluir:

• Descripción de la alerta.
• Datos a validar.
• Fuentes de logs a consultar.
• Preguntas de triage.
• Acciones de contención posibles.
• Criterios de escalamiento.
• Criterios de cierre.

15.16 Métricas de gestión de alertas

Medir ayuda a mejorar. Algunas métricas permiten detectar si el proceso está saturado, si hay demasiado ruido o si las alertas importantes tardan en atenderse.

15.17 Ejemplo práctico: alerta de IPS

Un IPS alerta y bloquea un intento de explotación contra una aplicación web pública.

Proceso recomendado:

1. Confirmar severidad y firma disparada.
2. Identificar origen, destino, hora y regla aplicada.
3. Verificar si la aplicación es vulnerable.
4. Correlacionar con logs del WAF, servidor web y firewall.
5. Buscar intentos similares desde otros orígenes.
6. Confirmar si hubo tráfico permitido relacionado.
7. Escalar a equipo de aplicaciones si hay riesgo real.
8. Documentar cierre o abrir incidente.

15.18 Ejemplo práctico: muchos falsos positivos

Un IDS genera cientos de alertas diarias por una herramienta interna de administración. El equipo deja de revisarlas porque siempre parecen legítimas.

Corrección recomendada:

• Validar qué herramienta genera las alertas.
• Confirmar orígenes autorizados.
• Ajustar regla para esos orígenes conocidos.
• Mantener alerta si aparece desde otros segmentos.
• Documentar excepción y responsable.
• Revisar periódicamente que la excepción siga siendo válida.

15.19 Errores frecuentes

• Tratar todas las alertas igual: consume tiempo y retrasa lo crítico.
• No enriquecer alertas: obliga a investigar sin contexto.
• Cerrar sin documentar: impide aprender y medir.
• Ignorar falsos positivos: produce fatiga de alertas.
• No definir escalamiento: las alertas importantes quedan detenidas.
• No medir el proceso: no se sabe si mejora o empeora.
• Automatizar sin criterio: puede bloquear o escalar eventos incorrectos.

15.20 Lista de verificación inicial

• Definir severidades y criterios de prioridad.
• Agregar contexto de activo, usuario, zona y criticidad.
• Separar alertas nuevas, en análisis, escaladas y cerradas.
• Crear criterios de escalamiento claros.
• Diseñar playbooks para alertas frecuentes.
• Medir falsos positivos y ajustar reglas.
• Correlacionar IDS/IPS con firewall, EDR, identidad y logs de aplicación.
• Documentar motivo de cierre.
• Revisar alertas repetidas y buscar causa raíz.
• Probar que las alertas críticas lleguen a responsables reales.

15.21 Ideas clave para recordar

• Una alerta es una señal, no necesariamente un incidente confirmado.
• Severidad y confianza deben evaluarse juntas.
• El enriquecimiento y la correlación reducen ruido y mejoran decisiones.
• Los falsos positivos deben gestionarse, no ignorarse.
• El escalamiento debe tener criterios claros y responsables definidos.
• Los playbooks ayudan a responder con consistencia.

15.22 Conclusión

La gestión de alertas es el puente entre detección y respuesta. Sin priorización, contexto y escalamiento, incluso las mejores herramientas pueden producir ruido. Con un proceso ordenado, las alertas se convierten en acciones concretas de defensa.

En el próximo tema estudiaremos integración con SIEM, SOAR, EDR, NetFlow y análisis de paquetes.