Bloque 1 — Cómo se diseña una política antes de tocar el CSP

1.1 Una política comienza con una decisión

Infoblox Threat Defense puede utilizar diferentes fuentes para identificar que una consulta DNS representa algún tipo de riesgo: Threat Intelligence, Threat Insight, listas personalizadas, categorías y otros controles.

Pero identificar algo no responde automáticamente una pregunta fundamental:

Podemos permitir la resolución (ALLOW), impedirla (BLOCK) o impedir el destino original y conducir la resolución hacia un resultado controlado (REDIRECT).

Por eso debemos separar dos conceptos:

La evidencia nos ayuda a entender lo que está ocurriendo. La política determina qué queremos hacer al respecto.

Que la plataforma pueda bloquear algo no significa necesariamente que la organización deba bloquearlo.

1.2 Antes de configurar: entender el entorno

Antes de tocar el CSP necesitamos entender dónde operará la política. Las preguntas iniciales deberían ser:

• ¿Qué estamos protegiendo?
• ¿A quién debe aplicarse la política?
• ¿Cuál es la tolerancia al riesgo?
• ¿Qué impacto sobre los usuarios es aceptable?
• ¿Qué aplicaciones o servicios son críticos?
• ¿Qué no podemos permitir que la política rompa?

No es lo mismo diseñar una política para usuarios corporativos que para servidores, una universidad, una red guest, infraestructura crítica o una PoC.

La tecnología puede ser la misma. La intención de la política no.

Un control puede funcionar exactamente como fue diseñado y aun así producir un resultado incorrecto para el negocio. Por ejemplo, bloquear un dominio identificado como riesgoso puede ser técnicamente correcto, pero si ese dominio es indispensable para el sistema de autenticación de una aplicación crítica, tendremos:

Por eso el éxito de una política no puede medirse únicamente por cuánto bloquea.

1.3 Detectar no significa bloquear

Una detección y una acción son decisiones diferentes.

La simplificación Threat detected → BLOCK puede resultar apropiada en algunos casos, pero no debería ser nuestra regla de diseño.

Podemos tener una fuente en la que confiamos lo suficiente para intervenir inmediatamente y otra que preferimos observar antes de utilizar para bloquear.

Por eso una política debe considerar no sólo qué fue detectado, sino también el contexto, la confianza en la evidencia y el impacto que tendría nuestra respuesta.

Esto también explica por qué ALLOW no significa necesariamente “seguro” y BLOCK no significa necesariamente “ataque confirmado”. Son decisiones tomadas por una política.

1.4 Observation antes de Enforcement

Cuando implementamos una nueva política todavía existen cosas que desconocemos del entorno:

• comportamiento normal;
• dependencias inesperadas;
• aplicaciones críticas;
• posibles excepciones;
• falsos positivos;
• impacto sobre los usuarios.

Por eso no todos los controles necesitan comenzar inmediatamente en enforcement.

Para determinados indicadores o nuevas fuentes podemos utilizar inicialmente:

La pregunta durante la observación es: ¿Qué habría ocurrido si hubiéramos bloqueado?

Después, con suficiente evidencia, podemos preguntarnos: ¿Estamos preparados para intervenir?

1.5 Una política no es estática

El entorno cambia. Las amenazas cambian. Las aplicaciones cambian. La Threat Intelligence cambia. Y también cambia nuestra comprensión de lo que ocurre en la red.

Por eso una Security Policy debería entenderse como un ciclo:

Durante el curso recorreremos precisamente ese proceso. Diseñaremos la política, la llevaremos a los endpoints, generaremos tráfico para comprobar su comportamiento y utilizaremos la evidencia obtenida para decidir qué debemos ajustar.

Las excepciones, el tuning, las métricas y la forma de llevar una política de observación a enforcement las estudiaremos posteriormente.

1.6 Hay un problema que todavía no hemos resuelto

Supongamos que una organización necesita un dominio para una aplicación crítica.

Su decisión es:

Pero una fuente de Threat Intelligence identifica ese mismo dominio como riesgoso:

Tenemos entonces:

Las dos decisiones tienen una razón para existir. Pero DNS necesita producir un solo resultado.

Cuando una consulta coincide con múltiples reglas, Threat Defense necesita una forma determinística de decidir cuál debe aplicarse.

Ese mecanismo se llama PRECEDENCE.

No necesitamos resolverlo todavía. Es precisamente el problema que estudiaremos en Bloque 2 — Policy Anatomy & Precedence.