Test de intrusión en los Emiratos Árabes Unidos
Los EAU acumulan más regímenes de ciberseguridad solapados que casi cualquier otro país —federales, de emirato, sectoriales y de zona franca— y casi todos desembocan en el mismo requisito: un test de intrusión independiente, al menos anual, con evidencias. Aquí tiene cuál le aplica y qué implica la prueba.
El mapa regulatorio de los EAU, en breve
Los EAU superponen reglas federales, de emirato y sectoriales. La mayoría de las organizaciones están cubiertas por más de una, y la idea útil es que una sola prueba bien acotada puede satisfacer varias a la vez, si se planifica así deliberadamente y no por casualidad.
NESA / UAE Information Assurance Standards
La base federal, aplicable a entidades públicas y a organizaciones designadas como infraestructura de información crítica en energía, agua, transporte, telecomunicaciones, servicios financieros y sanidad. La gestión de vulnerabilidades técnicas exige que las evaluaciones y los test de intrusión se realicen y se sigan: anualmente, en la práctica. Dos requisitos pillan desprevenidas a las organizaciones: los hallazgos críticos y altos necesitan remediación documentada con evidencia de retest dentro de un plazo definido, habitualmente 90 días; y los auditores revisan las credenciales de quien prueba, siendo OSCP o equivalente la expectativa declarada. La página de NESA entra en detalle (en inglés).
Dubai ISR (DESC)
La Information Security Regulation del Dubai Electronic Security Centre obliga a las entidades públicas de Dubái y a los proveedores que las sirven. Convive con NESA en lugar de sustituirla, y las organizaciones que trabajan con el gobierno de Dubái a menudo deben evidenciar ambas. El requisito de prueba es sustancialmente similar, así que un encargo acotado para ambas produce un único conjunto de evidencias.
Servicios financieros: CBUAE, DFSA, ADGM
El banco central de los EAU fija las expectativas para bancos y financieras onshore; la DFSA regula las firmas del DIFC y la FSRA las del ADGM. Los tres esperan pruebas de seguridad independientes periódicas, y los tres miran con malos ojos un escaneo de vulnerabilidades presentado como test de intrusión. Detallado aquí (en inglés).
VARA: activos virtuales
La autoridad reguladora de activos virtuales de Dubái exige a cada proveedor con licencia un test de intrusión independiente al menos anual bajo su Technology and Information Rulebook, con pruebas dirigidas por inteligencia cuando lo considere necesario y proporcionado. El rulebook convive con requisitos sobre gestión de claves respaldada por HSM, mínimos de almacenamiento en frío y notificación de incidentes en 24 a 72 horas según gravedad.
Sanidad: ADHICS
El estándar de Abu Dabi de seguridad de la información sanitaria aplica a proveedores sanitarios y a sus proveedores tecnológicos en el emirato, con requisitos de pruebas y evidencias junto a sus controles sobre datos clínicos. Más aquí (en inglés).
Protección de datos
La PDPL federal, más las leyes separadas del DIFC y del ADGM, traen obligaciones de seguridad allí donde se traten datos personales. No nombran el test de intrusión como tal, pero el estándar es el de «medidas técnicas apropiadas», y demostrarlo tras un incidente es bastante más fácil con una prueba independiente reciente en el expediente.
Una prueba, varias obligaciones
El error caro en los EAU es comprar una evaluación distinta por regulador. En la mayoría de los casos el alcance técnico se solapa casi por completo —superficie externa, aplicaciones web y API, red interna y Active Directory, tenant cloud— y lo que cambia es la correspondencia y el formato del informe, no la prueba.
Así que el encargo se acota una vez frente a todo lo que le aplica, y el informe vincula cada hallazgo a cada control aplicable. El alcance práctico:
- Red externa - todo lo alcanzable desde Internet, incluidos los servidores que nadie recuerda haber publicado.
- Aplicaciones web y API - autenticación, autorización, lógica de negocio, inyección. La capa de cara al cliente por la que pregunta todo regulador.
- Red interna - qué alcanza un punto de apoyo y si su segmentación aguanta de verdad.
- Active Directory - abuso de ADCS, Kerberoasting, delegación y rutas de ACL hasta Domain Admin.
- Nube - escalada en Entra ID y Azure RBAC, almacenamiento expuesto, errores de configuración de identidad.
Para los proveedores de activos virtuales bajo VARA, añada la frontera de custodia: infraestructura de monederos, flujos de firma y controles operativos en torno al material de claves, que es donde ocurre la pérdida y no en la interfaz web.
El requisito de credenciales, en concreto
La mayoría de páginas de cumplimiento pasan de puntillas sobre esto, pero en los EAU es inusualmente concreto: los auditores de NESA revisan quién realizó la prueba, y OSCP o equivalente es lo esperado. Las pruebas realizadas por alguien sin una certificación ofensiva reconocida se cuestionan y a veces se rechazan en la auditoría.
Tengo OSCP+ —la forma actual y renovada de la certificación— junto con eCPPT, eWPT y eCIR en el lado ofensivo, y AZ-500, SC-200 y SC-300 en el lado de seguridad Microsoft, lo que hace creíble y no genérica la parte de Entra ID y Azure. Todas son verificables de forma independiente en el monedero de credenciales de OffSec, y ese enlace debe ir en su paquete de evidencias junto al informe.
Cómo transcurre el encargo
Alcance y presupuesto primero: usted indica la obligación, el entorno y el plazo; recibe un precio cerrado y una fecha de inicio, normalmente en una o dos semanas. Las reglas de compromiso se acuerdan por escrito, incluidas las ventanas de prueba, los contactos de escalado y cualquier limitación que imponga su regulador sobre dónde se procesan o almacenan las evidencias.
La prueba suele durar una o dos semanas según el alcance, informándole de inmediato de cualquier hallazgo crítico en lugar de guardarlo para el documento final. El informe llega en pocos días: resumen ejecutivo, hallazgos técnicos con pasos de reproducción y puntuaciones CVSS, correspondencia con los controles y remediación priorizada. Después, un retest de lo corregido y una carta de atestación, más importante de lo que se cree en los EAU, porque la evidencia de retest a 90 días es en sí misma un requisito y no un extra.
Trabajo en remoto desde Amán, una hora por detrás de Dubái, con el mismo ritmo semanal que la región, en árabe o en inglés. Sin oficina local, y no voy a afirmar lo contrario: lo que obtiene es la persona que hace el trabajo, directamente, con credenciales verificables.
Empiece aquí
Dígame ante qué regulador responde y qué entra en el alcance. Si no está seguro —algo del todo normal con tantos regímenes solapados— una llamada breve lo aclara. La visión general de cumplimiento compara los marcos, el escaneo de perímetro gratuito muestra su exposición externa actual en minutos, y el informe de muestra enseña exactamente lo que recibiría.
Escríbame: las consultas en árabe son bienvenidas, y si un plazo de presentación marca el calendario, dígalo en la primera línea.
Emiratos: preguntas frecuentes
A grandes rasgos: las entidades federales y la infraestructura de información designada crítica —energía, agua, transporte, telecomunicaciones, servicios financieros, sanidad— quedan bajo los Information Assurance Standards de NESA. Las entidades públicas de Dubái y sus proveedores, bajo la ISR del DESC. Los bancos y financieras responden ante el banco central; las firmas del DIFC ante la DFSA y las del ADGM ante la FSRA; los proveedores de servicios de activos virtuales de Dubái ante VARA. La sanidad de Abu Dabi queda bajo ADHICS. Muchas organizaciones están cubiertas por dos o tres a la vez, lo que normalmente no es problema: una prueba bien acotada puede producir evidencias para todas si se planifica así desde el principio.
Sí. La gestión de vulnerabilidades técnicas dentro de los Information Assurance Standards exige que se realicen y se sigan evaluaciones de vulnerabilidades y test de intrusión, lo que en la práctica significa al menos anualmente para las entidades cubiertas. Dos detalles importan más allá de la prueba: los hallazgos críticos y altos necesitan remediación documentada con evidencia de retest dentro de un plazo definido, típicamente 90 días —una prueba sin retest es una respuesta incompleta—. Y los auditores de NESA revisan las credenciales de quien realizó la prueba, siendo OSCP o equivalente lo esperado.
Sí. Bajo el Technology and Information Rulebook de VARA, todo proveedor de servicios de activos virtuales con licencia en Dubái necesita un test de intrusión independiente al menos una vez al año, y VARA puede además exigir pruebas dirigidas por inteligencia cuando lo considere necesario y proporcionado. El rulebook cubre también la gestión de claves con HSM, los mínimos de almacenamiento en frío y la notificación de incidentes en 24 a 72 horas según gravedad. Para estos proveedores, el alcance suele tener que ir más allá de una prueba web estándar: la infraestructura de monederos, los flujos de firma y la frontera de custodia concentran el riesgo real.
No. Las pruebas externas, de aplicaciones web, de nube y la mayor parte de las internas se entregan en remoto, que es lo estándar en la región. La red interna y Active Directory se trabajan por VPN o un equipo puente dentro de su entorno. Cuando un regulador o su propia política limita dónde se procesan los datos o se almacenan las evidencias, eso queda por escrito en las reglas de compromiso antes de empezar.
Normalmente en una o dos semanas desde el acuerdo de alcance, y antes cuando hay un plazo de presentación que lo exige. Como contrata directamente al pentester, no hay cola interna de asignación de recursos entre la firma y el inicio. Un encargo típico de externo más aplicaciones web supone una o dos semanas de pruebas, con el informe pocos días después de terminar: el calendario en detalle (en inglés).
¿Tiene un plazo con NESA, ISR o VARA?
Dígame la obligación y el alcance, y recibirá precio cerrado y fecha de inicio.