Empresa de servicios, alrededor de 400 empleados. Su firewall perimetral producía un flujo constante de alertas de nivel alto, todas con la misma severidad y ninguna con contexto suficiente para decidir qué hacer. Este es el análisis que las separó, con los números en bruto.
El equipo del cliente describía el problema con una frase que hemos oído muchas veces: «los avisos no suman valor». No era una queja sobre la cantidad. Era que todas las alertas se veían iguales, así que ninguna significaba nada.
En una ventana de siete días, la plataforma había registrado 163 alertas de nivel 7 o superior —el umbral a partir del cual un evento merece atención humana—. Al agruparlas por regla apareció lo que en realidad ocurría:
| Regla | Qué reporta | Alertas en 7 días |
|---|---|---|
| 81628 | Ataque detectado por el firewall | 162 |
| Resto del conjunto | Otros eventos de nivel alto | 1 |
Una sola regla concentraba el 99% del volumen de nivel alto. Un tablero donde el 99% de lo crítico dice lo mismo no es un tablero de seguridad: es un ruido de fondo con logotipo.
El primer instinto ante esto es subir el umbral o silenciar la regla. Ambos son errores, y el análisis explicó por qué.
El firewall sí asignaba severidades distintas a cada evento: no es lo mismo un escaneo automatizado que un intento de ejecución remota de código, y el dispositivo lo distinguía correctamente. El problema estaba en la traducción: la plataforma que recibía los registros probaba primero el campo de severidad del fabricante, pero su tabla de equivalencias sólo contenía el vocabulario de syslog clásico y no el que usan los módulos de inspección del firewall. Al no encontrar el valor, caía a un valor por defecto — y ese valor por defecto aplanaba las 163 alertas al mismo nivel.
El firewall no estaba exagerando. La información para priorizar existía, viajaba en el registro y se perdía en el camino. Silenciar la regla habría eliminado el ruido y también el intento de intrusión real, que llegaba por esa misma regla. Por eso la respuesta correcta casi nunca es apagar la fuente.
Recuperado el vocabulario de severidad del fabricante, se aplicó el criterio sobre las 163 alertas de esa semana —no sobre una muestra ni sobre un supuesto— y se revisó qué caía de cada lado.
| Firma | Qué es en realidad | Cantidad |
|---|---|---|
| Marca de tiempo TCP fuera de rango | Anomalía de protocolo, ruido de red | 96 |
| Escaneo tipo Nmap | Rastreo automatizado de puertos | 18 |
| Censys | Motor público de indexación de internet | 13 |
| ZGrab | Recolector automatizado de banners | 7 |
Todo esto le llega a cualquier dirección IP pública, cada día, sin que nadie tenga interés específico en la empresa. Es meteorología de internet. Registrarlo tiene sentido; despertar a alguien por ello, no.
Entre ellas, 18 intentos de ejecución remota de código contra un componente de aplicación web, dos de path traversal y un bypass de autenticación en un dispositivo expuesto a internet. Es decir: exactamente lo que justifica tener un SOC, y lo que estaba enterrado bajo las otras 134.
Cuatro tickets diarios los revisa una persona con calma. Veintitrés no los revisa nadie, y ese es el estado en el que se pierden los incidentes: no por falta de detección, sino por exceso de detecciones indistinguibles entre sí.
Durante el mismo trabajo surgió una petición razonable: bajar el umbral de nivel 7 a nivel 5 «para ver más». Se midió antes de hacerlo, y el resultado desaconsejó el cambio.
| Umbral | Alertas en la misma semana |
|---|---|
| Nivel 7 o superior | 163 |
| Nivel 5 o superior | 1,568 |
El multiplicador venía casi todo de una sola regla nueva —1,386 eventos de «URL bloqueada por política de categoría»—, es decir, tráfico que el firewall ya había bloqueado. Eso es cumplimiento de política, no un incidente.
Y el daño no habría sido sólo de volumen. Cuando muchas reglas de una misma familia caen en un mismo caso correlacionado, el incidente se rotula con el último evento que entró: un intento de ejecución remota de código real puede terminar presentado como «URL bloqueada». Más alertas no siempre es más visibilidad. A veces es menos.
Tres criterios que aplican aunque tu proveedor sea otro:
Está anonimizado a propósito: no publicamos nombres de clientes, direcciones IP, usuarios ni identificadores de tickets. Las cifras —163, 162, 134, 29, 4.1— son las del análisis real, medidas sobre la telemetría de una ventana de siete días. Los identificadores de regla citados pertenecen al conjunto público de reglas de la plataforma, de modo que cualquiera con un entorno equivalente puede reproducir el ejercicio.
Si la respuesta es «no sé» o «demasiadas para revisarlas», es el mismo punto de partida. Cuéntanos qué tienes conectado y te decimos qué se puede separar.
Solicitar cotización