Bloque 4 — Infoblox Inspect como herramienta de validación

Objetivo del Bloque 4

Al finalizar este bloque, el participante podrá utilizar Infoblox Inspect para generar condiciones conocidas y validar que la Security Policy aplicada a su endpoint produce el comportamiento esperado.

La pregunta central será:

¿Cómo demostramos que una política hace realmente lo que diseñamos?

Nuestro modelo será:

PREDICT → TEST → OBSERVE → EVIDENCE

4.1 Configurar no es validar

Supongamos que configuramos:

Test Domain ↓ BLOCK

Ver la regla en el CSP demuestra que la configuración existe.

No demuestra todavía que una consulta realizada desde nuestro endpoint vaya a producir el resultado esperado.

Necesitamos comprobar:

POLICY ↓ DNS QUERY ↓ EXPECTED ACTION ↓ OBSERVED RESULT
Una política configurada no es necesariamente una política validada.

4.2 Inspect: generar una condición conocida

Podríamos intentar probar nuestras políticas utilizando amenazas reales de Internet.

Pero no necesitamos exponernos a una amenaza real para demostrar que un control funciona.

Para este curso utilizaremos Infoblox Inspect para generar condiciones conocidas que podamos reproducir y analizar.

Inspect genera la condición → nosotros validamos la decisión de la política

Durante el workshop, el instructor mostrará cómo utilizar Inspect. Nuestro interés no estará en aprender su interfaz, sino en utilizarlo como herramienta de validación.

4.3 Expected vs. Observed

Antes de realizar una prueba debemos establecer qué esperamos que ocurra.

Por ejemplo:

Condición Expected
Test A ALLOW
Test B BLOCK
Test C REDIRECT

Después ejecutamos cada prueba y registramos lo que realmente ocurrió:

PREDICT → TEST → OBSERVE → EVIDENCE

Si obtenemos:

EXPECTED = OBSERVED

tenemos evidencia de que la política produjo el comportamiento diseñado.

Pero si obtenemos:

EXPECTED ≠ OBSERVED

no debemos concluir inmediatamente que Threat Defense falló.

Debemos investigar.

4.4 Cuando el resultado no es el esperado

Supongamos:

Expected: BLOCK Observed: ALLOW

Ya tenemos el modelo necesario para investigar:

WHO → POLICY → MATCH → PRECEDENCE → ACTION → RESULT
No corregimos primero. Explicamos primero.

Una vez entendida la causa, podemos modificar la política y repetir la prueba.

4.5 La evidencia cierra la validación

Una prueba no termina cuando vemos que un dominio resolvió o fue bloqueado.

Debemos poder relacionar el resultado con la decisión que lo produjo.

Al finalizar una validación deberíamos poder decir:

“Esperábamos este comportamiento, generamos una condición conocida y obtuvimos evidencia de que la política tomó la decisión esperada.”

Ésa es la diferencia entre:

“Parece que funciona.” ≠ “Podemos demostrar que funciona.”

Siguiente paso — Lab 2

Ya podemos establecer qué esperamos que ocurra, generar una condición conocida y comparar el resultado esperado con el observado.

En el siguiente laboratorio utilizaremos Infoblox Inspect para validar ALLOW, BLOCK y REDIRECT.

También provocaremos intencionalmente un resultado inesperado para explicar su causa utilizando:

WHO → POLICY → MATCH → PRECEDENCE → ACTION → RESULT

Ir al Lab 2 — Validate the Policy with Infoblox Inspect →