Tu SIEM dispara 500 alertas de «inicio de sesión fallido» al día, casi todo ruido, y los analistas ya ignoran la regla. ¿Cuál es la decisión correcta?
Respuesta breve
Reduce los falsos positivos mediante ingeniería de detección, no cegándote. Reajusta para que las alertas disparen solo en patrones que importan — una misma contraseña probada en muchas cuentas (spraying), una cuenta atacada muchas veces (stuffing/fuerza bruta), viaje imposible — manteniendo los eventos brutos consultables en un panel. Luego mide la precisión de las alertas con el tiempo. Desactivar la regla elimina una señal real, una supresión global crea un punto ciego permanente, y contratar gente para triar puro ruido no escala y los quema.
Una regla que dispara 500 veces al día y acaba ignorándose es peor que no tener regla — entrena a los analistas a descartar precisamente la categoría de evento que importa, y el ataque real se esconde en el ruido. Esta pregunta evalúa si recurres a la ingeniería de detección en lugar de a los dos extremos perezosos: matarla, o lanzar personal al problema.
Por qué el ajuste es la respuesta
Los inicios de sesión fallidos no son intrínsecamente interesantes; lo son los patrones de fallos. Rediseña la detección para que solo alerte sobre señal:
- Password spraying — una contraseña probada en muchas cuentas en una ventana corta.
- Credential stuffing / fuerza bruta — muchos fallos contra una sola cuenta, o una ráfaga desde una IP de origen.
- Viaje imposible o un login fallido seguido de inmediato por un éxito desde una nueva geo/ASN.
Crucialmente, mantienes los eventos brutos fluyendo a un índice o panel consultable — solo que no como alertas. Eso preserva los datos para la caza y el alcance posterior al incidente mientras elimina el ruido evento por evento. Luego mides la precisión (verdaderos positivos / total de alertas) para demostrar que el ajuste funcionó y seguir refinándolo.
Por qué fallan las otras opciones
- Desactivar la regla — eliminas la señal por completo. La fuerza bruta y el spraying son técnicas de acceso inicial comunes; quedarte a oscuras ante ellas es un regalo para los atacantes.
- Suprimir todo y confiar en el EDR — el EDR vigila endpoints, no tu proveedor de identidad ni tu superficie de autenticación en la nube. Un spraying contra una VPN o un portal M365 puede no tocar nunca un host monitorizado por EDR. Eso es un punto ciego, no una estrategia.
- Contratar más analistas — pagar a humanos para descartar ruido no arregla la relación señal/ruido rota; solo reparte la fatiga y no escala con el volumen.
Qué evalúa el entrevistador
Quiere un candidato que trate el SOC como un problema de ingeniería: los falsos positivos son un defecto ajustable, no un hecho de la vida. La buena respuesta nombra los patrones de ataque a detectar, preserva los datos brutos para la investigación, y se compromete a medir la precisión con el tiempo — la diferencia entre un analista que soporta las alertas y uno que mejora la detección.
Posibles preguntas de seguimiento
- ¿Qué umbrales distinguen el password spraying del credential stuffing en tu lógica de detección?
- ¿Cómo medirías si tu ajuste mejoró la precisión sin dejar pasar un ataque real?
- ¿Cómo mantienes los datos brutos disponibles para la caza sin que generen alertas?