Requisitos de pruebas de penetración de SAMA
Si el Banco Central Saudí le supervisa, las pruebas de penetración son una obligación recurrente anual, no un proyecto. El marco es específico en dos puntos que deciden si sus evidencias superan la revisión: las pruebas deben ser independientes y el alcance debe llegar a los sistemas que sus clientes pueden tocar.
El requisito, dicho con claridad
Se espera que las entidades supervisadas por el Banco Central Saudí realicen pruebas de penetración externas e independientes como mínimo anuales, con un alcance que cubra los sistemas expuestos al exterior, las aplicaciones web y la infraestructura de red.
Tres palabras de esa frase cargan con todo el peso, y cada una es un punto donde las evidencias fallan habitualmente en la revisión:
- Independientes: no realizadas por el equipo que construye u opera los sistemas sometidos a prueba.
- Anuales, como mínimo: el ciclo anual es un suelo, y un cambio material en los sistemas expuestos a internet es un disparador aparte.
- Prueba de penetración: no un escaneo de vulnerabilidades con otra portada. Los evaluadores se han vuelto buenos distinguiéndolos.
Dónde fallan realmente las evidencias de SAMA
Cuatro modos de fallo explican la mayor parte de lo que se cuestiona, y los cuatro son más baratos de evitar que de remediar.
Un escaneo presentado como prueba de penetración
La señal es estructural: cada hallazgo es un CVE con una descripción suministrada por el fabricante, nada está encadenado y no hay narrativa que explique qué podría lograr un atacante. Una prueba de penetración demuestra impacto: este servicio expuesto entrega una credencial, esa credencial alcanza este sistema interno, que contiene estos datos. Si su informe es una lista ordenada de versiones, es un escaneo. La distinción, al completo.
Una independencia que no se sostiene
Pruebas realizadas por el equipo de ingeniería, por el proveedor de servicios gestionados que además opera la infraestructura, o por un fabricante evaluando su propio producto. Cada uno de estos casos incumple el requisito de independencia por muy competentes que fueran las pruebas.
Un alcance que se deja la capa de cara al cliente
Backends de banca móvil, APIs de socios, la nueva integración fintech lanzada después de firmar el alcance. Los sistemas expuestos a internet y las aplicaciones web están nombrados explícitamente en el marco, así que una laguna aquí es un incumplimiento directo y no una cuestión de criterio.
Sin retest
Un informe con doce hallazgos de severidad alta y ninguna evidencia de que se cerrara alguno es, desde la perspectiva de un revisor, la documentación de un problema sin resolver. El ciclo de remediación y retest es lo que convierte una prueba en evidencia de cumplimiento.
Qué cubre el encargo
La línea base regulatoria, todos los años:
- Pruebas de red externa: todo el parque expuesto a internet: banca en línea, interfaces de pago, VPN y acceso remoto, infraestructura de correo y los hosts que se publicaron para un proyecto y nunca se retiraron.
- Pruebas de aplicaciones web y APIs: autenticación y gestión de sesiones, autorización y control de acceso entre clientes, lógica de negocio en los flujos de transacción, inyección y las APIs que hay detrás de las aplicaciones móviles. En una entidad financiera, los hallazgos de lógica de negocio suelen ser los que más importan y los que la automatización nunca encuentra.
Recomendado junto a lo anterior, e incluido por la mayoría de entidades en un ciclo anual o alterno:
- Pruebas de red interna: hasta dónde llega realmente un punto de apoyo y si aguanta la segmentación entre el entorno corporativo y el de pagos.
- Active Directory: abuso de ADCS, Kerberoasting, delegación y rutas de ACL hasta Domain Admin. Así es como un punto de apoyo modesto se convierte en un compromiso de todo el banco, y es invisible para las pruebas externas.
- Nube: escalada en Entra ID y Azure RBAC, almacenamiento expuesto y configuración incorrecta de identidades, allí donde se han trasladado las cargas de trabajo.
- Brecha asumida: partir de un punto de apoyo en lugar del perímetro, lo que responde a la pregunta que un consejo realmente formula: ¿hasta dónde podría llegar alguien?
Cuando además maneja datos de tarjeta, el requisito 11.4 de PCI DSS se aplica en paralelo y se solapa de forma sustancial: dimensionados conjuntamente son un solo encargo, no dos.
El entregable
Un informe construido para la forma en que las entidades financieras lo consumen realmente: un resumen ejecutivo que su consejo y su regulador puedan leer sin traducción, un cuerpo técnico con pasos de reproducción, evidencias y valoraciones CVSS para sus ingenieros, y un mapeo explícito de cada hallazgo al control del marco que le afecta, para que su equipo de cumplimiento no tenga que construir ese mapeo por su cuenta.
Después, las partes que convierten un informe en evidencia: soporte de remediación mientras corrige, un retest de los hallazgos cerrados y una carta de atestación que declare que la prueba se realizó, por quién, contra qué alcance y en qué fechas. Todo incluido. Un informe de muestra enseña el formato.
Quién la realiza
Trata directamente con quien hace las pruebas: sin gestor de cuentas, sin un júnior ejecutando herramientas bajo el nombre de un sénior en la factura, sin tres semanas de espera entre las pruebas y el informe. Para un plazo regulatorio, esa inmediatez suele ser lo que permite llegar a la fecha.
Credenciales, ya que esto se pregunta siempre en las compras del sector financiero: OSCP+, eCPPT, eWPT, eCIR, más AZ-500, SC-200 y SC-300 para la parte Microsoft y Azure, todas verificables a través de la credential wallet de OffSec. Antes de dedicarme a tiempo completo al trabajo ofensivo fui ingeniero de detección y analista de CTI, un bagaje útil en este sector en concreto: el informe le indica no solo cómo funciona una ruta de ataque, sino qué aspecto habría tenido en su SIEM y si su monitorización la habría detectado.
Trabajo en remoto desde Ammán en GMT+3, el mismo horario y la misma semana laboral que Riad, en árabe o inglés.
Cómo empezar
Dígame su tipo de licencia, qué entra en el alcance y cuándo debe estar completada la prueba. Recibirá un presupuesto cerrado y una fecha de inicio. Si se acerca su ciclo anual y quiere ver antes su exposición externa actual, el escaneo de perímetro gratuito lleva unos minutos.
Relacionado: pruebas de penetración en Arabia Saudí para ver cómo SAMA convive con NCA ECC, el control 2-11 de ECC si además arrastra una obligación gubernamental, y la visión general de cumplimiento para todo lo demás. Póngase en contacto: el árabe es bienvenido.
Preguntas sobre SAMA
A las organizaciones miembro supervisadas por el Banco Central Saudí: bancos, compañías de seguros y reaseguros, entidades de financiación, burós de crédito y proveedores de servicios de pago, incluidas las fintech que operan con licencia de SAMA o en su sandbox regulatorio. Si su licencia procede de SAMA, el marco se le aplica. Las fintech suelen sorprenderse con esto: la obligación llega con la licencia, en un momento en que el programa de seguridad a menudo aún se está formando.
Pruebas de penetración externas e independientes, como mínimo anuales. El «como mínimo» hace un trabajo real en esa frase: por lo general se espera que un cambio material en los sistemas expuestos a internet dispare pruebas con independencia del punto del ciclo anual en que se encuentre, y una entidad que lanzó una nueva plataforma de cara al cliente seis meses después de su prueba anual y no la probó tendrá una conversación difícil. Trate la prueba anual como el suelo y el cambio significativo como un disparador aparte.
Que las pruebas no pueden realizarlas las personas que construyen u operan los sistemas sometidos a prueba. Una función de seguridad interna que reporte de forma separada a ingeniería se acerca más, pero la respuesta más limpia y comúnmente aceptada es un tercero externo sin ningún papel en la construcción ni en la operación del entorno. Este es el requisito que las entidades incumplen con más frecuencia, y lo descubren en la revisión y no en el dimensionamiento, que es el orden caro.
El alcance nombrado explícitamente son los sistemas expuestos a internet, las aplicaciones web y la infraestructura de red. La mayoría de entidades va más allá, y con razón: una prueba que demuestra que un atacante puede alcanzar el perímetro pero nunca pregunta qué ocurre después responde a la mitad de la pregunta. El patrón que funciona bien es una evaluación externa y de aplicaciones web completa cada año como línea base regulatoria, incorporando pruebas de red interna y Active Directory al menos en años alternos o siempre que el parque cambie de forma material.
Sí, y es el caso habitual. Normalmente usted ya dispone del mapeo del marco, de una función GRC y de una relación con auditoría interna; lo que necesita son las pruebas y las evidencias que encajen en todo ello. Dimensiono contra el control que usted debe satisfacer, mapeo los hallazgos a ese control en el informe y entrego el retest y la atestación que su equipo de cumplimiento necesita archivar. No soy una consultora GRC y no intentaré venderle un programa de marco: las pruebas son la parte que yo hago.
¿Le toca la prueba anual de SAMA?
Independiente, con el alcance del marco, y con el retest y la atestación que archiva su equipo de cumplimiento.