Pruebas y ajuste de detecciones

Una detección sin ajustar que se activa ante actividad benigna es peor que no tener ninguna detección. Los analistas aprenden a ignorar las alertas ruidosas y el único ataque real queda sepultado en la cola. Esto es la fatiga por alertas y es la forma en que las intrusiones pasan inadvertidas incluso en SOC con muchos recursos.

El ajuste es el proceso disciplinado de maximizar los verdaderos positivos y reducir los falsos positivos hacia cero, sin quedar ciego ante las amenazas reales.

La calidad de una detección se evalúa con cuatro resultados:

• Verdadero positivo (TP) — se activa ante actividad maliciosa real
• Falso positivo (FP) — se activa ante actividad benigna
• Verdadero negativo (TN) — permanece correctamente inactivo ante actividad benigna
• Falso negativo (FN) — no detecta actividad maliciosa real

El ajuste implica equilibrar estas dimensiones. Relajar una regla reduce los FN, pero aumenta el riesgo de FP; endurecerla produce el efecto contrario. El objetivo es encontrar el equilibrio que el SOC pueda mantener.

No puede ajustar una regla a ciegas. Cree un corpus de muestras conocidas como maliciosas (la regla debe activarse) y muestras conocidas como legítimas (la regla no debe activarse). En Sigma DaC, estas muestras se almacenan como casos de prueba junto a la regla.

Genere telemetría real conocida como maliciosa ejecutando la técnica de forma segura. Atomic Red Team proporciona pruebas pequeñas y documentadas, asignadas a ATT&CK, que puede ejecutar en un laboratorio para confirmar que la regla realmente se activa.

Ejecute la prueba atómica, capture los registros y compruebe que la detección se active. Si no lo hace, su regla tiene una brecha de cobertura, independientemente de lo bueno que parezca el YAML.

Antes de implementar una regla para generar alertas, ejecútela en modo de auditoría sobre datos históricos y en tiempo real para saber qué la activa normalmente. Esta línea base revela los procesos, administradores y herramientas legítimos que, de otro modo, generarían FP.

Lo que parece malicioso en abstracto suele ser un trabajo de copia de seguridad, un escáner de vulnerabilidades o un agente RMM en su entorno específico. Establecer una línea base permite identificar estos casos antes de que despierten a un analista en plena noche.

El ajuste más limpio conserva intacta la lógica maliciosa y excluye las activaciones conocidas como legítimas mediante filtros explícitos. Este enfoque es auditable: un revisor puede ver exactamente qué se excluyó y por qué.

Prefiera exclusiones precisas y justificadas en lugar de ampliar la lógica principal, lo que puede crear puntos ciegos sin que nadie lo advierta.

Cada exclusión es un agujero en el que un atacante puede ocultarse. Si filtra toda la actividad de ParentImage que contenga el nombre de una herramienta, un adversario que utilice ese nombre para hacerse pasar por ella podrá evadir la detección.

Directrices:

• Filtre el atributo más específico disponible (ruta completa, editor firmado, hash)
• Documente por qué existe cada filtro
• Revise los filtros periódicamente — los entornos cambian
• Prefiera aumentar un umbral antes que eliminar una condición

Algunos comportamientos solo resultan sospechosos cuando se producen en gran cantidad. Un único inicio de sesión fallido es normal; cincuenta en un minuto desde un mismo origen no lo son. Utilice la agregación en la condición para generar alertas según la frecuencia o la cantidad, en lugar de hacerlo por cada evento.

Ajustar los umbrales reduce considerablemente el ruido en patrones de fuerza bruta, escaneo y exfiltración.

El ajuste es un proceso continuo, no una tarea puntual. Realice un seguimiento de las métricas de cada regla y vuelva a revisar las que peores resultados obtengan:

• Volumen de alertas por regla y por día
• Tasa de FP según las decisiones de los analistas
• Precisión = TP / (TP + FP)
• Impacto en el tiempo de triaje

Una regla que genere 200 alertas a la semana, todas cerradas como benignas, debe ajustarse, pasar a modo de auditoría o retirarse. Deje que los datos guíen la decisión.

No todo el ruido se resuelve mediante supresión. A menudo, una alerta es técnicamente válida, pero necesita contexto para poder clasificarla. El enriquecimiento adjunta ese contexto automáticamente para que los analistas decidan más rápido.

• Importancia y propietario del activo
• Rol del usuario y si la cuenta tiene privilegios
• Reputación según inteligencia de amenazas de IP, dominios y hashes
• Si el host se encuentra en una ventana de mantenimiento

Las alertas enriquecidas permiten asignar una puntuación de riesgo y establecer prioridades, lo que reduce el ruido efectivo aunque el volumen bruto de alertas no cambie.

Cuando ajuste una regla, vuelva a ejecutar su conjunto completo de pruebas en CI. Las pruebas con muestras conocidas como maliciosas evitan que el ajuste desactive accidentalmente detecciones reales; las pruebas con muestras conocidas como legítimas confirman que el FP se ha corregido.

Este circuito cerrado explica por qué DaC y el ajuste deben ir unidos: puede refactorizar de forma agresiva porque las pruebas detectarán cualquier cobertura que rompa.

Aplique su criterio de ajuste a una disyuntiva real.

El ajuste mantiene las detecciones fiables y accionables:

• Los FP no gestionados provocan fatiga de alertas y brechas no detectadas
• Use el marco de TP/FP/TN/FN para razonar sobre los resultados
• Construya corpus de pruebas con muestras conocidas como legítimas y maliciosas
• Use la emulación del adversario (Atomic Red Team) para demostrar que las reglas se activan
• Establezca una línea base en modo de auditoría antes de generar alertas
• Ajuste mediante filtros precisos y documentados y umbrales, no mediante exclusiones amplias
• Mida la tasa de FP y la precisión; itere sobre las peores reglas
• Vuelva a ejecutar las pruebas de regresión después de cada cambio

Ha completado el curso de ingeniería de detecciones con Sigma.