Bloque 2 — Policy Anatomy & Precedence
Objetivo del Bloque 2
Al finalizar este bloque, el participante comprenderá cómo una Security Policy de Infoblox Threat Defense transforma una consulta DNS en una decisión, considerando a quién se aplica la política, qué reglas coinciden, cuál tiene precedencia y qué acción determina el resultado.
Deberá poder analizar una política y responder:
2.1 De una consulta a una decisión
Retomemos el problema del bloque anterior.
Un dominio crítico para el negocio debe permitirse: ALLOW.
El mismo dominio aparece en una fuente de Threat Intelligence: BLOCK.
Tenemos dos coincidencias, pero necesitamos un solo resultado.
Para entender qué sucede debemos separar dos conceptos:
MATCH
¿La consulta coincide con esta regla?
DECISION
De todas las reglas que coinciden, ¿cuál determina el resultado?
Una consulta puede coincidir con varias reglas. La Security Policy necesita determinar cuál de ellas prevalece.
Ahí entra la precedencia.
Pero antes de analizarla debemos responder una pregunta todavía más básica:
2.2 Antes del MATCH: ¿qué política aplica?
Antes de analizar qué regla coincide o cuál tiene mayor precedencia, necesitamos saber:
Una organización no necesita aplicar las mismas decisiones a todos sus usuarios o dispositivos.
Supongamos que existen dos grupos:
El dominio consultado es exactamente el mismo, pero el resultado es diferente.
Esto no representa un conflicto.
Ambas decisiones pueden ser correctas porque pertenecen a scopes diferentes.
Un usuario de Engineering puede necesitar acceso a
example.com para realizar su trabajo, mientras que los
usuarios de Contractors no tienen esa necesidad. La política puede
reflejar esa diferencia.
Scope y Zero Trust
Este comportamiento es consistente con un principio de Zero Trust: el acceso no debería asumirse simplemente porque un recurso esté disponible para la organización.
La decisión debe considerar:
No necesitamos profundizar aquí en la arquitectura Zero Trust. Para nuestro diseño de políticas, lo importante es entender que scope permite aplicar decisiones diferentes a grupos diferentes.
Por eso nuestro modelo de decisión comienza antes del MATCH:
Primero identificamos a quién se aplica la decisión y qué política le corresponde. Después podemos analizar las reglas de esa política, sus coincidencias y su precedencia.
Este concepto será importante más adelante, cuando despleguemos BloxOne Endpoint y llevemos las políticas a los grupos que queremos proteger.
2.3 Anatomía de una regla
Una vez determinada la política que aplica, podemos analizar sus reglas.
Conceptualmente podemos simplificar una regla a tres elementos:
Por ejemplo:
MATCH identifica cuándo aplica la regla. PRECEDENCE determina su prioridad frente a otras coincidencias. ACTION establece qué hacer cuando esa regla es la que prevalece.
Infoblox Threat Defense evalúa las reglas de acuerdo con su precedencia. Un número menor representa una precedencia mayor:
Por ejemplo:
Si una consulta coincide con ambas reglas, prevalece la regla con precedencia 2.
Resultado: ALLOW.
2.4 ¿Qué puede producir un MATCH?
Una Security Policy puede tomar decisiones utilizando diferentes tipos de reglas.
Como modelo general podemos pensar en:
Default Lists representan decisiones explícitas de Allow o Block de alta prioridad.
Custom Lists permiten incorporar contexto específico de la organización.
Feeds & Threat Insights aportan información relacionada con amenazas y comportamiento malicioso.
Category Filters permiten tomar decisiones según la categoría del contenido.
Application Filters permiten controlar aplicaciones o servicios.
Infoblox utiliza este orden como recomendación general de precedencia, aunque la organización puede modificarlo según sus necesidades.
Infoblox — Precedence Rules for Security Policies
2.5 ALLOW, BLOCK y REDIRECT
En el Bloque 1 presentamos estas acciones. Ahora podemos ubicarlas dentro del motor de decisión.
ALLOW
Permite la resolución.
Pero dentro de una política basada en precedencia, ALLOW puede representar una decisión explícita de negocio.
Si un dominio coincide con ambas reglas, prevalece ALLOW.
Esto no significa que Threat Defense haya ignorado el riesgo. La política hizo exactamente lo que diseñamos: la decisión de negocio tenía mayor precedencia.
Por eso una lista de ALLOW de alta precedencia debe mantenerse cuidadosamente controlada.
BLOCK
Impide la resolución hacia el destino original.
La decisión puede provenir de Threat Intelligence, una Custom List, una categoría o una decisión organizacional.
Por eso durante una investigación no basta con preguntar: ¿Fue bloqueado?
También debemos preguntar: ¿Qué regla produjo el bloqueo y por qué?
REDIRECT
Impide que la consulta continúe hacia el destino original y proporciona un resultado controlado.
REDIRECT introduce entonces otra dimensión:
La acción indica qué hacer con la consulta. La regla que produjo el MATCH explica por qué.
2.6 Confidence, Threat Level y Precedence
Estos tres conceptos pueden confundirse fácilmente, pero responden preguntas diferentes.
| Concepto | Pregunta |
|---|---|
| Confidence | ¿Qué tan seguros estamos de la clasificación? |
| Threat Level | ¿Qué nivel de riesgo representa? |
| Precedence | ¿Qué decisión debe ganar? |
Una amenaza de alta confianza no tiene automáticamente la mayor precedencia de toda la política.
Del mismo modo, una regla ALLOW puede tener mayor precedencia que una regla asociada con una amenaza de alto riesgo.
Por eso Confidence, Threat Level y Precedence no son intercambiables. Uno describe la confianza en la información, otro el riesgo asociado y el tercero resuelve qué decisión prevalece cuando existen múltiples coincidencias.
2.7 El modelo completo
Ahora podemos representar el proceso desde la perspectiva de una consulta DNS:
O, en su versión corta:
Éste es el modelo mental que necesitamos conservar.
Cuando algo no produzca el resultado esperado, podemos recorrerlo hacia atrás:
Esto transforma el troubleshooting de:
en:
Policy Challenge — ¿Quién gana?
Este bloque no necesita todavía un laboratorio de CSP. La intención del ejercicio es comprobar que el participante puede razonar sobre el comportamiento de una política antes de construirla.
Escenario
Tenemos dos grupos:
Para Engineering Policy se han definido las siguientes reglas:
| Precedence | Regla | Acción |
|---|---|---|
| 1 | Critical Business | ALLOW |
| 3 | Custom Block | BLOCK |
| 5 | High Confidence | BLOCK |
| 7 | Medium Risk | ALLOW + LOG |
| 9 | Category Filter | BLOCK |
Caso 1
Un usuario de Engineering consulta un dominio que aparece simultáneamente en:
- Critical Business — ALLOW
- High Confidence — BLOCK
¿Qué sucede? → ALLOW
El usuario pertenece al scope de Engineering Policy y, dentro de esa política, Critical Business tiene mayor precedencia.
Caso 2
Un dominio aparece en:
- Custom Block — BLOCK
- Medium Risk — ALLOW + LOG
¿Qué sucede? → BLOCK
La decisión proviene de Custom Block porque tiene mayor precedencia.
Caso 3
Un dominio aparece en:
- Medium Risk — ALLOW + LOG
- Category Filter — BLOCK
¿Qué sucede? → ALLOW + LOG
Ahora hacemos la pregunta importante: la organización quería bloquear esa categoría. ¿Falló Threat Defense?
No.
La política hizo exactamente lo que le indicamos. El problema está en el diseño de la precedencia.
Caso 4
Ahora un usuario de Contractors consulta el mismo dominio del Caso 1.
En Contractors Policy ese dominio no se encuentra en una lista Critical Business y coincide con una regla:
High Confidence — BLOCK
El resultado ahora es: BLOCK.
Esto refuerza nuestro modelo completo:
Cierre del bloque
Ya podemos responder la pregunta que dejamos pendiente en el Bloque 1.
Cuando ALLOW y BLOCK coinciden dentro de una política, no gana BLOCK por ser más restrictivo ni ALLOW por ser más permisivo. La decisión depende de la precedencia.
Y antes de analizar esa precedencia debemos saber qué política aplica y a quién se está aplicando.
Pero hasta ahora hemos trabajado con la política de manera conceptual.
Ya sabemos qué queremos que ocurra, a quién queremos aplicarlo y cómo Threat Defense resuelve las decisiones dentro de la política.
Ahora necesitamos llevar esa política al dispositivo que queremos proteger.
Decisión de política no es lo mismo que enforcement
Hasta ahora hemos seguido el proceso mediante el cual una consulta llega a una política, hace MATCH con una regla, entra en un orden de precedencia y finalmente produce una acción.
Pero debemos introducir una distinción adicional:
En una arquitectura basada en DFP que opera en Detection Mode, podemos evaluar la lógica de una política sin asumir automáticamente que la acción definida será aplicada como enforcement sobre la consulta.
Durante análisis y troubleshooting debemos separar:
de:
Por ejemplo, encontrar una regla cuya acción configurada sea
BLOCK no es suficiente para concluir que una consulta fue
bloqueada.
También necesitamos entender:
- qué política estaba siendo evaluada;
- qué regla ganó;
- cuál era la acción esperada;
- cuál era el modo de operación;
- dónde debía ocurrir el enforcement;
- y cuál fue finalmente el resultado observado.
Este principio evita inferir el resultado únicamente a partir de la configuración.
Consideración de arquitectura
Esta separación es especialmente relevante en escenarios con DFP en Detection Mode, incluyendo NIOS utilizando DFP.
Los laboratorios de este curso utilizan Endpoint y no dependen de esta modalidad.