Lab 2 — Validate the Policy with Infoblox Inspect

Objetivo

Utilizar Infoblox Inspect para generar condiciones conocidas y comprobar que la Security Policy asignada al endpoint del participante produce las acciones esperadas.

Validaremos:

ALLOW · BLOCK · REDIRECT

También provocaremos intencionalmente un resultado inesperado para analizarlo utilizando nuestro modelo de decisión.

PREDICT → TEST → OBSERVE → EVIDENCE

Preparación

Cada participante ya dispone de:

Participant ↓ Endpoint ↓ Own Scope ↓ Own Security Policy

Antes de comenzar deberá confirmar que está trabajando sobre su propia política y endpoint.

Endpoint correcto → Scope correcto → Policy correcta

Parte 1 — Predecir

Antes de ejecutar Inspect, completa la siguiente tabla:

Test Expected Observed
ALLOW ALLOW —
BLOCK BLOCK —
REDIRECT REDIRECT —
La columna Observed permanece vacía.

Primero predecimos. Después probamos.

Parte 2 — Preparar la política

Configurar en la Security Policy las condiciones necesarias para producir:

Test A → ALLOW Test B → BLOCK Test C → REDIRECT

Antes de continuar:

Endpoint correcto → Scope correcto → Policy correcta

Parte 3 — Probar con Inspect

Utilizar Infoblox Inspect para generar cada condición una por una.

Para cada prueba:

PREDICT → TEST → OBSERVE → RECORD

Registrar:

Expected ____________________________
Observed ____________________________
Matching rule ____________________________
Action ____________________________
Evidence ____________________________

Al terminar debemos poder explicar por qué cada prueba produjo ALLOW, BLOCK o REDIRECT.

Parte 4 — Provocar un resultado inesperado

Ahora modificaremos deliberadamente la precedencia para crear un conflicto.

Por ejemplo:

Precedence Regla Action
1 Test Allow ALLOW
5 Test Block BLOCK

Una condición hará match con ambas reglas.

Podríamos esperar intuitivamente BLOCK, pero obtenemos:

RESULT → ALLOW

La pregunta es:

¿Falló Threat Defense?

No.

Regresamos a nuestro modelo:

WHO → POLICY → MATCH → PRECEDENCE → ACTION → RESULT

Identificamos la causa, corregimos la política y repetimos la prueba.

Ahora debemos obtener:

EXPECTED = OBSERVED

Checkpoint

Al finalizar el laboratorio:

El participante deberá poder demostrar:

PREDICT → TEST → OBSERVE → EVIDENCE

Preguntas de análisis

  1. ¿Por qué utilizamos una condición conocida en lugar de depender de una amenaza real?
  2. ¿Qué diferencia existe entre comprobar que una regla está configurada y demostrar que está siendo aplicada?
  3. Si esperamos BLOCK y obtenemos ALLOW, ¿qué debemos investigar antes de modificar la política?
  4. ¿Por qué saber únicamente que una consulta fue bloqueada no es suficiente para validar correctamente la política?

Cierre del Lab 2

Ya podemos diseñar una decisión y demostrar mediante evidencia que se está ejecutando como esperamos.

Pero aparece una nueva situación:

Expected: BLOCK Observed: BLOCK

La política funciona perfectamente.

Sin embargo, descubrimos que el bloqueo está afectando una aplicación legítima del negocio.

¿Qué hacemos cuando la política funciona como fue diseñada, pero la decisión necesita cambiar?

Ese es el problema que abordaremos en Bloque 5 — Tuning: ¿Bloquear o investigar?