Bloque 5 — Tuning: ¿Bloquear o investigar?
Objetivo del Bloque 5
Al finalizar este bloque, el participante podrá utilizar la evidencia obtenida durante la operación de una Security Policy para decidir cuándo mantener una condición en observación, bloquearla, crear una excepción o continuar investigando.
La pregunta central será:
Nuestro modelo será:
5.1 Que funcione no significa que sea la decisión correcta
En el Bloque 4 validamos nuestras políticas comparando lo esperado contra lo observado.
Supongamos:
La política funciona exactamente como fue diseñada.
Pero después descubrimos que el dominio bloqueado es necesario para una aplicación crítica.
Tenemos:
El problema ya no es técnico.
La pregunta ahora es:
Ahí comienza el tuning.
5.2 Observation → Enforcement
No toda nueva fuente o condición necesita comenzar inmediatamente en BLOCK.
Cuando todavía desconocemos su comportamiento en nuestro entorno podemos comenzar con:
La observación nos permite obtener contexto antes de intervenir:
- ¿Qué está haciendo match?
- ¿Quién lo está consultando?
- ¿Existe una dependencia legítima?
- ¿Qué impacto tendría bloquearlo?
- ¿Tenemos suficiente evidencia?
Después decidimos:
La observación no es el destino final.
Es una forma de reducir incertidumbre antes del enforcement.
Cuando la evidencia justifica un cambio:
Y después volvemos a validar.
5.3 False Positive ≠ Business Exception
Supongamos que Threat Defense identifica un dominio como riesgoso, pero una aplicación legítima necesita acceder a él.
La reacción podría ser:
Pero no necesariamente.
False Positive
La clasificación es incorrecta. Algo legítimo fue identificado incorrectamente como amenaza.
Business Exception
La detección puede ser válida, pero existe una necesidad específica del negocio para permitir el acceso.
Por ejemplo:
Una excepción no invalida necesariamente la detección.
Y tampoco significa que debamos permitir el acceso a todos.
Si únicamente un grupo necesita la excepción:
podemos utilizar el scope para limitarla.
5.4 Tuning es un ciclo
Una política cambia conforme obtenemos nueva evidencia.
Por eso:
Cuando hacemos un ajuste debemos poder responder:
- ¿Qué cambiamos?
- ¿Por qué?
- ¿Qué evidencia justificó la decisión?
- ¿Qué resultado esperamos?
Y después:
Cuando sea posible, modificamos una cosa y validamos antes de continuar:
Esto facilita identificar la causa de un problema y revertir una decisión si fuera necesario.
Las excepciones y cambios relevantes también deben conservar contexto suficiente para que posteriormente podamos entender por qué existen.
Policy Tuning Challenge — ¿Bloquear o investigar?
El objetivo es utilizar evidencia y contexto para tomar una decisión sobre una Security Policy.
No buscamos una respuesta automática.
Caso 1 — ¿Listos para enforcement?
Una nueva fuente ha permanecido en observación:
| Classification | High Confidence |
|---|---|
| Observed clients | 3 |
| Business dependency | None identified |
| Current action | ALLOW + LOG |
¿Qué harías?
Y, más importante:
El objetivo no es responder simplemente BLOCK, sino determinar si consideramos que ya existe evidencia suficiente para pasar a enforcement.
Caso 2 — La política funciona... y rompe algo
Tenemos:
| Classification | High Confidence |
|---|---|
| Current action | BLOCK |
| Observed clients | 120 |
| Business dependency | Critical application |
| User impact | Authentication failures |
La política está haciendo exactamente lo que diseñamos.
Pero ahora debemos determinar:
Si necesitamos una excepción:
No buscamos simplemente:
Buscamos entender por qué estamos cambiando la decisión y cuál es el mínimo cambio necesario.
Caso 3 — No sabemos suficiente
Tenemos:
| Classification | Medium Confidence |
|---|---|
| Observed clients | 2 |
| Business dependency | Unknown |
| Current action | ALLOW + LOG |
¿Qué hacemos?
Aquí puede ser perfectamente válido responder:
No porque ignoremos el riesgo.
Sino porque:
Resultado del Challenge
Al terminar, el participante debería abandonar el modelo:
y sustituirlo por:
La pregunta ya no es únicamente:
¿Podemos bloquearlo?
Sino:
Cierre del Bloque 5
Ya podemos diseñar, aplicar, validar y ajustar una política utilizando evidencia.
Pero en un entorno real no tendremos tres eventos perfectamente organizados para analizarlos.
Tendremos múltiples endpoints, consultas, detecciones y señales que necesitan convertirse en contexto útil para investigar.
La siguiente pregunta será:
Eso nos lleva a Bloque 6 — Understanding Threat Defense Reports .
Detection Mode como etapa de validación
En arquitecturas basadas en DFP, Detection Mode permite observar cómo se comporta una política antes de aplicar enforcement.
Esto cambia una pregunta importante.
En lugar de preguntar inmediatamente:
podemos preguntar primero:
Podemos representar ese proceso así:
El objetivo de Detection Mode no es evitar indefinidamente el enforcement. El objetivo es reducir incertidumbre antes de aplicarlo.
Durante esta etapa, un SE debería hacerse preguntas como:
- ¿La política está haciendo MATCH donde esperábamos?
- ¿La regla correcta está ganando?
- ¿La precedencia produce el comportamiento esperado?
- ¿Estamos afectando dominios o aplicaciones legítimas?
- ¿Las excepciones son demasiado amplias?
- ¿Tenemos suficiente evidencia para pasar a enforcement?
Esto convierte el tuning en algo más que ajustar listas. Tuning significa comprobar que la política representa correctamente la intención de seguridad y de negocio antes de convertir esa intención en una acción efectiva.
Cuatro posibles decisiones
Para un SE, esa diferencia es importante. El objetivo no es demostrar que podemos bloquear algo.
El objetivo es demostrar que sabemos por qué debemos bloquearlo, qué impacto tendrá y cómo podemos probar que la decisión es correcta.
Consideración de arquitectura
Este flujo corresponde a arquitecturas que utilizan DFP, incluyendo NIOS con DFP.
Los laboratorios del curso utilizan Endpoint y, por lo tanto, no modificaremos su procedimiento para introducir Detection Mode.