En abril, una única vulnerabilidad de VPN provocó filtraciones de datos en más de setenta instituciones financieras que operaban sobre la infraestructura de Marquis Software, según informó American Banker. El parche existía. Las entidades afectadas probablemente contaban con pruebas de penetración recientes. Nada evitó que la exposición se acumulara en todo el portafolio.
Las matemáticas son simples. Una prueba de penetración externa anual estándar dura de dos a tres semanas de pruebas activas. Esto deja aproximadamente 345 días de realidad operativa sin validar. El informe M-Trends 2026 de Mandiant sitúa la mediana de permanencia en 2025 en catorce días, revirtiendo una tendencia de varios años de descenso, con los actores de espionaje promediando 122 días.
El informe Global Threat 2026 de CrowdStrike clasifica al sector financiero en el cuarto lugar en cuanto a intrusiones interactivas dirigidas. Los adversarios no esperaron entre evaluaciones anuales. El modelo asumía que lo harían.
Los reguladores fijan un piso frente a un modelo de amenaza más lento
PCI DSS, FFIEC y NYDFS mencionan las pruebas de penetración en sus requisitos y guías. Ninguno describe la cadencia anual como suficiente. PCI DSS 4.0, requisito 11.3.1, exige pruebas de penetración externas tras cualquier actualización o modificación significativa de infraestructura o aplicación. El Manual de Examen de TI de la FFIEC describe las pruebas de penetración como parte de la gestión continua de vulnerabilidades, no como un evento anual discreto. La sección 500.05 de NYDFS exige pruebas anuales junto con obligaciones de monitoreo continuo reforzadas en las enmiendas de 2023 a 23 NYCRR 500.
Todos estos marcos ya asumen que las pruebas ocurren en respuesta a cambios. El piso regulatorio fue redactado para instituciones donde los cambios significativos ocurrían en ciclos de lanzamiento trimestrales. Esa cadencia no coincide con la infraestructura bancaria moderna. Los lanzamientos de banca digital, migraciones de cargas de trabajo en la nube, integraciones de API fintech, lanzamientos de portales de terceros y el trabajo de integración por fusiones y adquisiciones generan superficie de ataque no probada entre pruebas anuales.
La pregunta de cumplimiento ya no es si la institución realizó pruebas el año pasado. Es si la institución probó las cosas que realmente cambiaron.
Lo que produce la brecha, documentado
En un compromiso reciente en un banco regional, los evaluadores de Sprocket identificaron un hallazgo en un portal de originación hipotecaria orientado al cliente, que el banco presenta en un subdominio propio. El portal es operado por un proveedor de plataforma externo, con la marca y el nombre de host del banco presentados a los solicitantes. El activo estaba dentro del alcance de las pruebas externas.
La plataforma exponía un endpoint de API que devolvía registros de organizaciones al recibir un ID de inquilino. El endpoint no requería autenticación ni sesión de ningún tipo. La política de origen cruzado de la plataforma permitía que cualquier sitio de terceros invocara la misma solicitud desde el navegador de un visitante sin interacción del usuario.
El ID de inquilino era visible en los archivos públicos del propio portal, por lo que un llamador no autenticado no necesitaba adivinarlo. Incrementar el ID en uno devolvía los registros de la siguiente institución en la plataforma compartida. Iterar sobre el rango reveló registros de todas las instituciones financieras que operaban en la plataforma, más el inquilino interno del proveedor.
Los registros devueltos no eran genéricos. Cada uno contenía personal nombrado con direcciones de correo electrónico comerciales, números de teléfono directos, títulos de trabajo y un código interno que la plataforma usaba para atribuir envíos de prestatarios a personal específico. Ese código era significativo por sí mismo: cualquier llamador en posesión de un código válido podía enviar una solicitud de prestatario potencial en nombre de un oficial designado contra la institución de ese oficial, y la plataforma trataría el envío como ingreso legítimo en el pipeline de originación de préstamos.
El banco no introdujo esta exposición. El proveedor de la plataforma sí lo hizo. La evaluación externa anual anterior del banco puede haber cubierto el nombre de host dentro del alcance en el momento de la prueba, pero ningún escáner automatizado descubre este hallazgo. Detectarlo requirió recorrer IDs de inquilinos secuenciales contra un endpoint no documentado y validar que los registros devueltos pertenecían a otras instituciones, y tuvo que ejecutarse contra la implementación de producción.
El riesgo downstream es lo que hace que el hallazgo sea de naturaleza regulatoria, no solo técnica. Los datos de todas las demás instituciones en la plataforma compartida eran extraíbles a través del nombre de host del banco. Cualquier incidente de fraude, phishing o cumplimiento que siguiera a esa exposición se dirigiría a la institución nombrada en la URL, independientemente de qué datos del inquilino usara realmente el atacante.
Las pruebas continuas son la respuesta operativa al compromiso anterior
El hallazgo anterior pasa en gran medida desapercibido en un modelo anual. Tres razones, cada una ligada directamente al compromiso. El activo ingresó en la huella externa del banco cuando el proveedor incorporó al banco a la plataforma, no cuando se definió el alcance de la prueba de penetración del banco. Si el alcance se fijó contra una instantánea de la infraestructura de seis meses antes, es posible que el nombre de host no estuviera listado. La gestión de la superficie de ataque cierra esta brecha al tratar los nuevos hosts y servicios expuestos como desencadenantes de pruebas, no esperando a la siguiente conversación de alcance anual.
El activo también era del tipo que las instituciones excluyen rutinariamente del alcance anual. Los portales operados por proveedores presentados en subdominios propios de la institución ocupan una zona gris en las conversaciones de alcance. No son la aplicación del banco, el banco no tiene código fuente, no controla los lanzamientos y el proveedor mantiene su propio programa de seguridad. Las instituciones deciden razonablemente que el proveedor de la plataforma es responsable de probar su propio código y excluyen el nombre de host del compromiso. El reconocimiento externo continuo no respeta ese límite: si el nombre de host es accesible en Internet abierto bajo un dominio que el banco posee, es parte de la superficie de ataque externa del banco, y un atacante que enumere el perímetro del banco lo encontrará, independientemente de si el documento de alcance más reciente del banco lo listó.
El hallazgo también requirió pruebas humanas activas, no resultados de escáner. Un escáner de vulnerabilidades que recorriera el nombre de host habría informado el endpoint como responsive y la política CORS como permisiva, posiblemente marcado el encabezado de autenticación faltante, y se habría detenido allí. No habría recorrido IDs de inquilinos, validado la devolución de datos entre inquilinos, ni encadenado el código de atribución de personal en un escenario de falsificación de envío. La automatización descubre posibilidades; los evaluadores establecen qué es realmente explotable y cuál es el impacto downstream cuando lo es. Sprocket Security opera el modelo continuo sobre este principio. La atestación que sigue refleja lo que se probó contra la infraestructura que existía cuando se ejecutó la prueba, no una instantánea de doce meses antes.
La brecha es estructural, no un problema de cadencia
La brecha de 345 días no es un número de marketing. Es una característica estructural del modelo de pruebas anuales. Los reguladores redactaron los requisitos de pruebas asumiendo que las instituciones probarían las cosas que cambiaron, cuando cambiaron. La mayoría de las instituciones prueban lo que existía en el momento del compromiso, en el cronograma para el cual se definió el alcance, y tratan la atestación resultante como una descripción de la exposición actual. Esa descripción se vuelve menos precisa cada día después de que concluye la prueba. Las instituciones que cierran la brecha no son las que prueban con más frecuencia. Son aquellas cuyo programa de pruebas responde a lo que su infraestructura realmente hace.
Patrocinado y escrito por Sprocket Security.
Deja una respuesta