Bloque 6 — FRAME: Explaining Threat Defense Reports

Objetivo del Bloque 6

Desarrollar en los SEs la capacidad de interpretar y explicar los resultados de Infoblox Threat Defense con base en evidencia, adaptando el mensaje a distintas audiencias y determinando el siguiente paso apropiado.

Al finalizar este bloque, el participante deberá poder responder:

¿Qué ocurrió, qué significa realmente, cómo se lo explico al cliente y qué debemos hacer después?

Para interpretar y explicar los resultados utilizaremos una metodología llamada FRAME.

F — FRAME THE CONTEXT → R — READ THE SIGNAL → A — ASSESS THE MEANING → M — MATCH THE AUDIENCE → E — END WITH ACTION

6.1 Un reporte no es una conclusión

Durante todo el bloque trabajaremos con un mismo caso tomado del tenant de demostración.

En los reportes de Threat Defense observamos actividad relacionada con indicadores de seguridad. Al bajar al detalle encontramos eventos donde una política de Grupo Dice clasificó actividad como sospechosa y aplicó una acción de Block, produciendo una respuesta DNS como NXDOMAIN.

También disponemos de:

Executive Summary;
Comprehensive Security Report;
Industry Vertical Analysis;
Security Events;
DNS Activity.

Security Indicator Summary del Executive Summary de Infoblox Threat Defense — El Executive Summary concentra múltiples métricas. El trabajo del SE comienza cuando transforma esos datos en una explicación sustentada.

Podríamos mirar inmediatamente los números y decir:

“Threat Defense detuvo varios ataques.”

Pero todavía no tenemos evidencia suficiente para afirmar eso. Tenemos datos. Ahora necesitamos construir una explicación.

DATA → FRAME → EXPLANATION

6.2 FRAME — Construir la explicación

F — Frame the Context

La primera pregunta no es:

“¿Cuál es la amenaza?”

La primera pregunta es:

¿Qué estoy observando?

Antes de interpretar el reporte establecemos el contexto:

TIME · SCOPE · POPULATION · ENVIRONMENT · POLICY

Preguntamos:

¿qué periodo cubre el reporte?;
¿qué tenant o ambiente estamos observando?;
¿qué dispositivos están incluidos?;
¿qué política estaba aplicada?;
¿estamos viendo tráfico normal, una PoC o tráfico generado durante una validación?

Cien eventos en treinta días y cien eventos en diez minutos no significan lo mismo. Tampoco podemos comparar directamente organizaciones con diferentes cantidades de usuarios, tráfico o exposición.

Antes de explicar una anomalía, entiende su contexto.

R — Read the Signal

Ahora buscamos el hallazgo principal. No intentamos interpretarlo todavía. Primero identificamos qué mide realmente el reporte.

EVENTS · QUERIES · INDICATORS · DOMAINS · DEVICES · POLICY ACTIONS

EVENT COUNT ≠ ATTACK COUNT

Si encontramos una gran cantidad de Security Events, no podemos convertir automáticamente cada evento en un ataque. Un único dispositivo puede generar repetidamente consultas relacionadas con el mismo indicador.

Por eso nuestra pregunta cambia de:

“¿Cuántos ataques hubo?”

¿Qué representa realmente esta métrica?

En nuestro caso, el reporte nos lleva hacia actividad relacionada con determinados indicadores y, al revisar Security Events, podemos observar información como:

Query	`noas.mtrtb.com.`
Threat level	Medium
Class	Suspicious
Property	TDS
Indicator	`mtrtb.com`
Policy	Grupo Dice
Action	Block
Response	NXDOMAIN
Device IP	`172.16.20.197`

A — Assess the Meaning

Éste es probablemente el paso más importante de FRAME. Preguntamos:

¿Qué puedo concluir legítimamente a partir de esta evidencia?

Para hacerlo utilizamos una disciplina sencilla:

WHAT I KNOW → WHAT I INFER → WHAT I STILL NEED

WHAT I KNOW

un dispositivo realizó una consulta DNS;
el indicador recibió una clasificación de seguridad;
una política determinada fue aplicada;
la acción registrada fue Block;
la respuesta DNS registrada fue NXDOMAIN.

WHAT I INFER

Podemos razonablemente interpretar que la política evitó que esa consulta obtuviera una resolución DNS normal.

WHAT I STILL NEED

Todavía no sabemos necesariamente:

por qué se produjo la consulta;
qué proceso la generó;
si provino de publicidad o contenido embebido;
si fue resultado de un redirect;
si la originó una aplicación;
si fue tráfico de prueba;
o si existe actividad realmente maliciosa en el endpoint.

OBSERVATION ≠ CONCLUSION

MALICIOUS INDICATOR ≠ COMPROMISED DEVICE

Threat Breakdown del Executive Summary de Infoblox Threat Defense — El Threat Breakdown describe actividad observada. La clasificación agrega contexto, pero no reemplaza la investigación.

6.3 M — Match the Audience

Ahora ya entendemos razonablemente qué ocurrió. El siguiente problema es comunicarlo.

La misma evidencia no se presenta igual a todas las audiencias.

Explicándolo a un CISO

El CISO necesita entender principalmente:

RISK → IMPACT → PROTECTION → TREND → DECISION

Podríamos explicar nuestro caso así:

Durante el periodo analizado, Threat Defense identificó actividad relacionada con indicadores de seguridad y aplicó las políticas configuradas para bloquear parte de esa actividad. La distribución de los eventos permite identificar dónde se concentra la actividad y determinar si existe alguna tendencia o conjunto de activos que requiera atención adicional.

La conversación continúa con preguntas como:

¿estamos protegidos?;
¿qué tipo de riesgo estamos observando?;
¿la actividad está aumentando?;
¿se concentra en determinados dispositivos?;
¿hay algo que requiera una decisión?

El reporte se convierte en una conversación sobre riesgo y protección.

Explicándolo a un SOC

El SOC probablemente responderá:

“¿Qué dispositivos?”

Ahora necesitamos profundidad operacional:

WHICH EVENT? → WHICH INDICATOR? → WHICH DEVICE? → HOW OFTEN? → SINCE WHEN? → WHICH ACTION?

Hacemos drill-down:

REPORT → SECURITY EVENT → INDICATOR → ASSET → DNS ACTIVITY

En este punto regresamos a algo que los participantes ya conocen del Curso 1:

WHO → WHAT → WHERE → RESPONSE → RESULT → TIME

Así, el mismo hallazgo puede generar dos conversaciones completamente diferentes:

Audiencia	Pregunta principal
CISO	¿Qué significa esto para la organización?
SOC	¿Qué ocurrió exactamente y dónde?

SAME DATA + DIFFERENT AUDIENCE = DIFFERENT EXPLANATION

Industry Vertical Analysis: contexto, no sentencia

Industry Vertical Analysis de la demo comparando la organización, su industria y todos los clientes — La vista compara la organización con empresas de su industria y con el conjunto de clientes. La diferencia genera preguntas; no constituye por sí sola una calificación de seguridad.

En la demo observamos métricas del tenant junto con valores comparativos de organizaciones de la misma industria y del conjunto de clientes.

ABOVE PEERS ≠ WORSE SECURITY

Una diferencia puede explicarse por múltiples variables:

cantidad de usuarios;
volumen DNS;
aplicaciones utilizadas;
exposición;
modelo de negocio;
cobertura de telemetría;
configuración de políticas.

La comparación sirve para generar preguntas. No reemplaza el contexto.

6.4 E — End with Action

Una buena explicación no termina diciendo:

“Eso es lo que muestra el reporte.”

Debe terminar respondiendo:

¿Qué hacemos ahora?

Antes de decidir necesitamos distinguir:

DETECTION ≠ ENFORCEMENT

Debemos comprobar:

WHAT WAS DETECTED? → WHICH POLICY APPLIED? → WHAT ACTION WAS TAKEN? → WAS THAT EXPECTED?

En nuestro caso observamos una acción Block. Si esa acción era la esperada y la evidencia no muestra nada adicional preocupante, la decisión podría ser:

NO ACTION · MONITOR

Pero si encontramos un indicador sospechoso con una acción inesperada de Allow, revisamos:

POLICY · SCOPE · PRECEDENCE · EXCEPTION · CONFIGURATION

y probablemente nuestro camino sea:

VALIDATE → TUNE

Eso pertenece al Curso 2.

¿Y cuándo investigamos?

Supongamos ahora que al seguir nuestro caso encontramos:

SAME ASSET + REPEATED ACTIVITY + MULTIPLE RELATED INDICATORS + ACTIVITY OVER TIME

La pregunta deja de ser:

“¿Funcionó correctamente la política?”

y se convierte en:

¿Qué está ocurriendo realmente alrededor de este activo?

INVESTIGATE

Ése es el límite de este curso. No hacemos todavía el Threat Hunting. Reconocemos cuándo debemos hacerlo.

Práctica — Explain the Same Report Twice

Los participantes utilizarán uno de los reportes reales disponibles en el tenant. No necesitan preparar una presentación extensa: aplicarán FRAME al mismo conjunto de evidencia.

F — FRAME

Definir:

TIME · SCOPE · POPULATION

R — READ

¿Cuál es el hallazgo principal?

A — ASSESS

WHAT I KNOW → WHAT I INFER → WHAT I STILL NEED

M — MATCH

Explicar el hallazgo en aproximadamente un minuto como si estuvieran frente a:

un CISO;
un analista SOC.

La información de origen será la misma. La explicación deberá cambiar.

E — END

Seleccionar una acción y justificarla utilizando la evidencia disponible:

NO ACTION · MONITOR · VALIDATE · TUNE · INVESTIGATE

Cierre del Bloque 6

Un reporte no es solamente una colección de métricas. Es el inicio de una conversación.

DATA → CONTEXT → MEANING → COMMUNICATION → ACTION

El participante sólo necesita recordar cinco pasos:

F — FRAME THE CONTEXT → R — READ THE SIGNAL → A — ASSESS THE MEANING → M — MATCH THE AUDIENCE → E — END WITH ACTION

Y dentro de esos pasos aparecen, exactamente donde hacen falta, nuestras tres precauciones:

Etapa	Control de calidad
READ	EVENT COUNT ≠ ATTACK COUNT
ASSESS	OBSERVATION ≠ CONCLUSION
END	DETECTION ≠ ENFORCEMENT

A good SE does not present a report. A good SE explains what the report means — and explains it differently depending on who is listening.

En el siguiente bloque utilizaremos Infoblox IQ para pasar de eventos y telemetría a preguntas, contexto e hipótesis útiles para una investigación.