Informe de muestra de TLPT | Vista previa del PDF de 68 páginas

Proyecto Meridian: ejercicio ficticio de Megabank AG que abarca tres funciones críticas, tres escenarios y doce hallazgos. Todos los sistemas, participantes y resultados son inventados.

El equipo consigue ejecutar comandos sin privilegios de root en un host de diagnóstico expuesto a Internet, accede a CI y utiliza un token de servicio para modificar un pago canario. El resumen diferencia esa cadena de ataque sin asistencia de los resultados obtenidos con ayuda en CRM y recuperación, e identifica los controles de firma, datos esenciales y copias inmutables que se mantuvieron eficaces.

La arquitectura conecta los canales de clientes, la identidad y los proveedores con las zonas perimetrales, operativas y de soporte. Los pagos, las cuentas digitales y la tesorería dependen de los datos centrales, la detección y la recuperación. Las flechas representan dependencias lógicas, no acceso irrestricto a la red.

El equipo envía una prueba literal de inyección de comandos y recibe un 403 del WAF. Una variante con escape Unicode recibe un 200 y devuelve la salida de id, hostname y pwd como svc_diag en mb-diag-01. Ambos intercambios HTTP, los ID de solicitud y las horas UTC se muestran como evidencias sintéticas.

F-03 muestra una solicitud PATCH con la identidad svc_pay_orch obtenida, el cambio aceptado del beneficiario en MER-PAY-0042 y una lectura de verificación independiente. El servicio modifica el borrador canary, mientras que una autorización de firma independiente impide la liquidación.

F-06 especifica una repetición desde la solicitud WAF aceptada, pasando por CI, hasta la API de pagos. Un caso debe vincular el host, la solicitud, el artefacto, la identidad principal y el pago, con un objetivo de triaje de 15 minutos. El procedimiento se marca expresamente como no ejecutado todavía; una validación futura no se presenta como una repetición de pruebas superada.

Tres hallazgos tienen comprobaciones de cierre registradas: inyección de comandos, revocación de sesiones y limpieza. Quedan nueve abiertos, con fechas para las credenciales, la autoridad sobre pagos y recuperación, la vinculación de aprobaciones, la segmentación, la detección y los controles de apoyo. Son objetivos ficticios para bancos, no plazos legales de subsanación.

La correspondencia vincula los requisitos del anexo V de las RTS con el informe técnico y distingue el informe del equipo azul, el resumen de pruebas depurado y la certificación de la autoridad conforme a los anexos VI a VIII. Un ejemplo no puede demostrar el cumplimiento normativo.