Ciberseguridad y seguridad de la información

False Positive en SOC: cómo identificarlos, documentarlos y reducirlos

6 min de lecturaPublicado: 5 de agosto de 2026

Ilustración visual profesional sobre False Positive en SOC en el ámbito de SOC y operaciones

Respuesta rápida

Un False Positive en SOC es un caso en el que se generó una alerta debido a una lógica errónea o datos imprecisos, aunque no se produjo el comportamiento peligroso que la regla pretendía detectar. Para cerrar correctamente, es necesario demostrar la causa, distinguirla de una actividad sospechosa pero autorizada, documentar la Causa Raíz y proporcionar retroalimentación que reduzca alertas similares sin crear un Blind Spot.

Las falsas alarmas no son solo una molestia. Cuando se repiten en gran cantidad, generan Fatiga de Alerta, alargan los tiempos de respuesta y enseñan a los analistas a ignorar patrones que podrían ser peligrosos. Sin embargo, un filtrado demasiado agresivo es igualmente peligroso: una excepción amplia puede ocultar actividad maliciosa que explota un usuario, herramienta o dirección que se consideraba “conocida”.

El primer paso es usar un lenguaje preciso. Microsoft Sentinel y Splunk distinguen entre True Positive, Benign Positive y False Positive. La actividad de un escáner autorizado puede ser un Benign Positive: la regla detectó correctamente un comportamiento sospechoso, pero es esperado. Por el contrario, si la regla interpretó un campo incorrecto o la fuente envió datos imprecisos, se trata de un False Positive.

El objetivo no es llegar a cero falsas alarmas. Una regla sensible puede generar cierto ruido para no pasar por alto un ataque. El objetivo es gestionar el equilibrio de forma medible, controlada y reversible.

Qué es un False Positive y qué no

Un False Positive se produce cuando el mecanismo determina que se ha producido un comportamiento peligroso, pero en realidad las condiciones fundamentales no son correctas. Ejemplo: una regla identifica un proceso llamado powershell.exe como una ejecución sospechosa, pero el dato proviene de un campo que describe un archivo de destino y no un proceso en ejecución. Otro ejemplo es una ubicación geográfica incorrecta debido a una base de datos de IP desactualizada.

Un Benign Positive es una situación diferente: el comportamiento realmente ocurrió y la regla lo detectó correctamente, pero se realizó con autorización. El escaneo de puertos por parte del equipo de PT, la creación de un usuario durante la instalación o PowerShell por parte de un sistema de administración son posibles ejemplos. La clasificación es importante porque la solución es diferente: un False Positive puede requerir la corrección de una regla o datos; un Benign Positive puede requerir una excepción limitada y gestionada.

“No encontré pruebas de ataque” tampoco es un False Positive. Es posible que el evento no sea concluyente, que la telemetría sea insuficiente o que la actividad se detuviera antes de que se generaran señales adicionales.

Qué pruebas se requieren para el cierre

Antes de cerrar, examine el evento original, no solo la descripción de la alerta. Asegúrese de que los campos muestren lo que cree que muestran, verifique el proceso padre, la firma, el hash, el usuario, la fuente de red, la hora y las acciones relacionadas. Si la razón es una actividad autorizada, encuentre una Solicitud de Cambio, un propietario del sistema, una ventana de mantenimiento, una lista de escáneres o un documento que la autorice.

Una buena prueba permite que otra persona llegue a la misma conclusión. Una frase como “la IP es conocida” es débil; una frase como “la dirección pertenece al escáner Tenable corporativo según el CMDB, el escaneo se realizó en la ventana autorizada CR-4821 y los objetivos coinciden con la lista” es verificable.

Al cerrar, elija una clasificación precisa y añada un Comentario. Microsoft Sentinel exige una clasificación al cerrar un Incidente y ofrece, entre otros, False Positive debido a lógica errónea, False Positive debido a datos imprecisos y Benign Positive.

Causa Raíz de las falsas alarmas

Las causas se pueden dividir en cinco familias: lógica demasiado amplia, datos de baja calidad, normalización incorrecta, falta de contexto organizacional y cambio en el entorno. Una regla que busca una herramienta legítima sin comportamiento adicional será amplia; las direcciones IP que han pasado por NAT pueden crear una asociación de usuario incorrecta; un campo process.name mapeado de una fuente inapropiada crea una normalización problemática; y una regla que no reconoce una cuenta de servicio verá la actividad automática como anómala.

Los cambios operativos son una fuente común: una nueva herramienta, un script de distribución, una migración de VPN o un cambio de infraestructura pueden aumentar las alertas de una sola vez. Por lo tanto, es importante verificar cuándo comenzó el ruido y qué cambió en ese momento.

No se conforme con una lista de entidades para excluir. Pregunte por qué la entidad activa la regla y si el comportamiento en sí puede ser refinado: proceso + proceso padre + destino de red + permiso, en lugar de solo el nombre del proceso.

Documentación y retroalimentación para la Ingeniería de Detección

Una tarjeta de retroalimentación debe incluir: nombre y versión de la regla, ejemplo de evento, clasificación, Causa Raíz, frecuencia, usuarios/activos afectados, riesgo de exclusión y propuesta de cambio. El Ingeniero de Detección también debe entender qué no cambiar. Si una regla capturó una actividad legítima de administrador, excluir a todo el grupo de administradores podría crear un Blind Spot; puede ser preferible limitar a una cuenta, herramienta firmada, ruta, dispositivo de administración y ventana de tiempo.

Microsoft Sentinel permite manejar algunos False Positives mediante Reglas de Automatización, que conservan un registro de auditoría y pueden estar limitadas en el tiempo, o mediante la modificación de Reglas de Análisis, que permiten expresiones avanzadas y Watchlists. Elastic permite Excepciones de Regla para procesos o actividad de red confiables. En cualquier caso, una Excepción debe tener un propietario, una razón, una fecha de revisión y una validez.

Después del cambio, se debe realizar un Backtest sobre datos históricos y verificar que la regla aún detecte ejemplos peligrosos. Es recomendable mantener Casos de Prueba positivos y negativos como parte de la gestión de versiones.

Medición de la mejora a lo largo del tiempo

Mida al menos: cantidad de alertas por regla, tasa de True/Benign/False Positive, tiempo promedio de Triage, número de Excepciones, antigüedad de las Excepciones y cantidad de eventos cerrados automáticamente. Los indicadores no están destinados a castigar una regla sensible, sino a identificar dónde los analistas invierten tiempo sin valor.

La tasa de False Positive por sí sola puede ser engañosa. Una regla rara que identifica una técnica peligrosa puede justificar algunas falsas alarmas. Por otro lado, una regla con una alta tasa de precisión pero cientos de alertas al día aún puede ser una carga. Por lo tanto, se combinan precisión, volumen, gravedad y costo de investigación.

Establezca un ciclo de revisión: semanal para reglas ruidosas, mensual para reglas clave y trimestral para Excepciones. Las Excepciones sin propietario o validez son una deuda de seguridad.

Tres casos de ejemplo

Caso 1 — Actividad de administrador: PsExec se ejecutó desde un servidor de administración autorizado por una cuenta Tier 0 como parte de un cambio documentado. El comportamiento es inherentemente sospechoso pero autorizado; una clasificación adecuada podría ser Benign Positive. La exclusión debe ser estrecha y basarse en el origen, la cuenta, la firma y la ventana.

Caso 2 — Escaneo autorizado: un IDS detecta un Port Scan desde una dirección que pertenece a un escáner de vulnerabilidades. Si la regla está diseñada para detectar escaneos no autorizados, el comportamiento es real pero esperado. Se puede agregar una lista de escáneres gestionada, manteniendo las alertas si el escáner opera fuera de la ventana o contra un objetivo no autorizado.

Caso 3 — Herramienta legítima: una regla alerta sobre certutil.exe en cualquier uso. Un equipo de desarrollo lo utiliza para la conversión de codificación local sin conexión de red. En lugar de excluir la herramienta, se cambia la regla para que busque el uso con descarga, URL, ruta inusual o proceso padre sospechoso.

Lista de verificación práctica

Clasifiqué False Positive versus Benign Positive.
Encontré pruebas positivas para la explicación y no solo la ausencia de pruebas.
Identifiqué la Causa Raíz.
Documenté la regla, la versión y un ejemplo de evento.
Evalué el riesgo de la exclusión.
Definí el Propietario y la validez para la Excepción.
Probé el cambio contra eventos históricos.

Errores comunes

Excluir un usuario o una herramienta completa en lugar de una condición limitada.
Cerrar todos los casos poco claros como False Positive.
Cambiar una regla sin Backtest.
No distinguir entre un problema de datos y un problema de lógica.
Medir el éxito solo por la disminución en la cantidad de alertas.

Resumen y CTA

Elija una regla que genere ruido en un turno, recopile las últimas diez alertas y clasifique la Causa Raíz antes de proponer una exclusión. Luego, continúe con el artículo sobre cómo construir un Playbook para SOC para que el proceso de cierre y retroalimentación sea consistente.

Preguntas frecuentes

¿Es posible alcanzar cero False Positives?

Generalmente no, y tampoco siempre es deseable. La detección de seguridad es un equilibrio entre sensibilidad y precisión, y el objetivo es un ruido controlado con una cobertura de riesgo adecuada.

¿Qué es mejor: Excepción o cambio de regla?

Una Excepción es adecuada para una entidad o situación definida, especialmente si es temporal. Un cambio de regla es adecuado cuando el problema está en la lógica o el contexto general. La decisión depende del alcance y el riesgo.

¿Cuál es la diferencia entre False Positive y Benign Positive?

Un False Positive es una detección errónea; un Benign Positive es una detección correcta de actividad sospechosa pero autorizada y esperada.

¿Quién debe aprobar una exclusión?

Según la gobernanza de la organización: generalmente el Ingeniero de Detección o el propietario de la regla, y a veces el propietario del sistema o el gerente de SOC. Las exclusiones de alto riesgo requieren una revisión más amplia.

¿Cuándo eliminar una Excepción?

Cuando la razón ha terminado, la herramienta ha sido eliminada, la regla ha sido mejorada o ha caducado. Las Excepciones deben revisarse periódicamente y no dejarse permanentemente por defecto.