Attack Intelligence Brief y reporte
- Parte
- 02
- Estado
- Revisado
- Edición
- v2 / 01.09.2026
- Tiempo estimado de lectura
- 3 min
Edición del 1 de septiembre de 2026
Las fuentes conservan sus fechas de consulta. El laboratorio identifica la simulación determinística y la integración con modelo por separado.
Tipo: Proceso / artefacto · Fase: Todas → Reporte
Llegás a la reunión de seguimiento con una prueba interesante: el agente propuso una acción inducida, pero el servidor la rechazó. Si el resumen dice «comprometimos el agente», PhiloCorp va a entender algo distinto de lo que observaste. Si sólo dice «el control funcionó», se pierde la desviación que sí ocurrió.
El Attack Intelligence Brief guarda esas diferencias mientras trabajás. Es un entregable versionado que conecta evidencia con decisiones: qué sabemos, qué falta confirmar y por qué conviene seguir o cerrar una ruta. El reporte final toma ese historial y lo convierte en acciones para el cliente.
El Attack Intelligence Brief
Un documento versionado que en cada iteración captura:
- Resumen del objetivo
- Ranking de crown jewels (con alcanzabilidad actual)
- Registro de supuestos, con estado de las hipótesis críticas y enlaces a la evidencia
- Restricciones de scope
- Límites de costo, tasa, impacto, rollback y stop conditions
- Rutas de escalada, con decisión de avanzar, pausar o cerrar y su motivo
- Resultados observados, controles que contuvieron la prueba y límites pendientes
- Próximas acciones
El historial permite reconstruir una decisión. Si una hipótesis se invalida, muestra qué rutas dependían de ella y qué cambió en el plan. Guardá fecha, motivo, evidencia y responsable de esa actualización; un conteo de hipótesis no alcanza para explicar el cambio.
Patrones de reporte
Diagrama de cadena de ataque. Una figura que conecta entrada, comportamiento y efecto, anotando la frontera y la evidencia de cada paso. Distinguí visualmente los saltos demostrados, los bloqueados y los hipotéticos. No unas dos pasos con una flecha de éxito si falta verificar la precondición que los conecta.
Tabla de hallazgos y controles. Para cada hallazgo: técnica, frontera afectada, activo,
efecto observado y control que debería reducir el riesgo. Evitá prometer que una mitigación
«lo habría bloqueado» hasta validarla. La tabla conecta con el plan de
remediación del cliente. Ver tabla finding a control.
Para el control, preferí IDs verificables de OWASP AISVS 1.0 (formato v1.0-C<capítulo>.<sección>.<requisito>; los capítulos cubren desde datos de entrenamiento hasta MCP y agentes), o del mapeo
de controles de la Parte 10.
Sumá severidad basada en impacto, explotabilidad, alcance, autonomía, éxitos sobre intentos, reversibilidad y exposición de datos. Etiquetá la evidencia con sensibilidad y retené únicamente lo necesario para reproducir el finding dentro de la RoE.
El mapeo de MITRE ATLAS
Usá ATLAS para nombrar la técnica que la evidencia permite sostener. Por ejemplo, si una instrucción en un documento sintético de la KB cambia la conducta del agente, puede corresponder AML.T0051.001 (Indirect Prompt Injection). Eso no prueba por sí solo que la herramienta se ejecutó: la descripción del resultado debe conservar esa diferencia.
Si la cadena cruza hacia infraestructura, agregá ATT&CK sólo para las acciones observadas. Una credencial potencialmente alcanzable no demuestra uso de Cloud Accounts, ni una herramienta con capacidad de shell demuestra ejecución de Unix Shell. Dejá los pasos no probados como hipótesis.
En los mappings OWASP, declará la edición. Por ejemplo, LLM06 corresponde a Excessive Agency en 2025 y a Unbounded Consumption en 2026; ver taxonomías. Un ID incorrecto puede mandar al equipo a revisar el control equivocado.
Una fila que conserva lo que pasó
Este ejemplo es una plantilla ficticia de redacción, no un resultado ejecutado:
| Observación del caso | Conclusión permitida | Lo que falta demostrar | Decisión |
|---|---|---|---|
| Una instrucción de la KB induce una llamada sobre un ticket sintético; la traza del servidor registra denegación | Influencia sobre la propuesta del agente y rechazo en la capa de autorización para ese caso | Cualquier efecto posterior o acceso efectivo a otro recurso | Reportar la desviación y el control observado; retest con la misma identidad y configuración |
Incluí entrada mínima, configuración disponible, versión, identidad de laboratorio, cantidad de intentos y referencias sanitizadas a las trazas. Si el resultado no se repite, conservá la observación original y explicá ese límite. Si no hay trazas suficientes, marcá el paso como inconcluso.
Checklist
- Brief actualizado en cada iteración con historial de versiones
- Attack chain diagram por cada cadena relevante
- Tabla findings-vs-controls completa
- Técnicas mapeadas según evidencia, con versión de ATLAS y edición OWASP
- Impacto observado separado de hipótesis y criterios de retest definidos