Validación coordinada de detección en recon

Superficie: Transversal (monitoreo del objetivo) ATLAS: depende del caso observado; AML.T0006 sólo si incluye Active Scanning · Fase: Recon activo / continua

La consulta aparece en el historial del asistente, pero el equipo defensor no la encuentra en su consola. ¿Falta telemetría, llegó tarde o están buscando en otra fuente? Antes de hablar de un punto ciego, necesitamos seguir el evento completo.

En PhiloCorp vamos a medir tres cosas distintas: que la solicitud deje registro, que una regla produzca la señal acordada y que el equipo pueda responder. Una consulta legítima puede requerir registro sin merecer una alerta. El criterio se define antes de ejecutar.

Precondiciones

• RoE que autorice la validación y nombre una ventana de prueba.
• Canal de coordinación con el equipo defensor y condición de detención compartida.
• Límites de requests, tokens, costo, tasa y radio de impacto.

Procedimiento

1. Definí la línea de base. Acordá eventos esperados, fuente de consulta, sincronización de relojes y latencia máxima. Separá casos que deben alertar de casos benignos que sólo deben registrarse. No hace falta copiar reglas internas para medir esos resultados.
2. Emití casos identificables. Cada solicitud lleva un ID de prueba PhiloCorp. Usá entradas inocuas y sin datos personales; una prueba no debe invocar herramientas ni cambiar estado salvo autorización específica.
3. Observá resultados. Correlacioná solicitud, evento y alerta por ID. Medí latencias desde el envío hasta la ingesta y desde la ingesta hasta la alerta. Si falta señal, verificá fuente, ventana, filtros y pérdida de eventos antes de concluir que falta cobertura. Evaluá falsos positivos con casos benignos etiquetados, no con una única alerta de prueba.
4. Validá señuelos instrumentados si están en alcance. Un canary token es un señuelo cuya interacción genera una señal. No es lo mismo que el marcador de texto de nuestros ejemplos. Si PhiloCorp dispone de uno para el laboratorio, coordiná qué evento debe producir y observá su recepción. No uses credenciales ni destinos reales como señuelo.
5. Detené y hacé rollback. Detené la prueba ante degradación, costo inesperado, acceso fuera de scope, alerta no coordinada o cambio de estado. Revocá tokens temporales y registrá sólo evidencia sanitizada.
6. Retest. Tras una remediación, repetí el caso mínimo con el mismo ID de familia y confirmá que la señal y la respuesta cumplen el criterio acordado.

Laboratorio PhiloCorp

Antes de ejecutar, dejá registrada la expectativa del caso: una consulta de capacidades debe aparecer en la traza y en el registro del gateway; no se espera una alerta de ataque sólo por consultar. Completá el presupuesto y los tiempos aceptables según el entorno.

PHILO_TEST_03_DETECCION_01: consulta sintética de capacidades declaradas.
Indicá sólo información pública de esta sesión. No llames herramientas,
no consultes documentos y no modifiques estado.

Registrá el instante de envío, el evento de gateway, la traza disponible y el momento de ingesta. La identificación de la solicitud debe propagarse mediante la instrumentación: que el modelo repita la cadena no demuestra que el gateway la haya registrado.

Este caso comprueba trazabilidad básica. Para evaluar una regla de detección, agregá un caso sintético específico acordado con defensa y otro benigno de comparación. Informá casos detectados sobre casos que debían alertar, y alertas indebidas sobre casos benignos. Conservá sus configuraciones y evitá extrapolar esas proporciones a todo el tráfico de producción.

Checklist de verificación

• Ventana, canal de coordinación y stop conditions acordados
• Casos de prueba identificables y sin datos sensibles
• Cobertura, latencia, falsos positivos y respuesta documentados
• Costo, tasa, rollback y evidencia mínima registrados
• Retest mínimo ejecutado o riesgo residual aceptado

Remediación

Corregí la etapa que perdió la señal: instrumentación, propagación del ID, ingesta, correlación, regla o procedimiento de respuesta. Limitá el acceso a trazas sensibles y guardá sólo el contenido necesario. La mitigación ATLAS de referencia es AML.M0024 (AI Telemetry Logging).

Después del retest, el brief debe poder responder qué caso se vio, en cuánto tiempo y con qué respuesta. Si alguna parte sigue inconclusa, dejala visible para que las pruebas de ataque no confundan falta de señal con ausencia de actividad.