Test de intrusión impulsado por cumplimiento
La mayoría de los test de intrusión se compran porque una normativa los exige. El marco determina el alcance, la frecuencia y —la parte que se subestima— las evidencias que deberá poder presentar después. Esta página compara los regímenes contra los que pruebo, para que identifique cuál le aplica realmente.
Los marcos comparados
Cada uno de estos regímenes exige pruebas de seguridad independientes o las requiere en la práctica. Las diferencias que importan: a quién obliga, con qué frecuencia y qué debe poder demostrar después.
Arabia Saudí
- NCA Essential Cybersecurity Controls (en inglés) - la base nacional para entidades públicas, sus contratistas e infraestructuras críticas. El control 2-11 cubre el test de intrusión: definido, documentado, aprobado e implantado, con un alcance que cubra al menos los servicios expuestos a Internet y la infraestructura técnica que hay detrás. De forma periódica.
- NCA Critical Systems Cybersecurity Controls - cuando los sistemas se clasifican como críticos, la frecuencia pasa a al menos cada seis meses. Ese cambio de ritmo es lo que suele romper la previsión presupuestaria.
- SAMA Cyber Security Framework (en inglés) - bancos, aseguradoras, financieras y proveedores de pagos supervisados por el banco central saudí. Pruebas externas independientes al menos anuales, cubriendo sistemas expuestos a Internet, aplicaciones web e infraestructura de red.
Emiratos Árabes Unidos
- NESA / UAE Information Assurance Standards (en inglés) - entidades federales e infraestructura de información designada crítica. Las evaluaciones de vulnerabilidades y los test de intrusión se realizan y se hace seguimiento, anualmente en la práctica, con remediación documentada y evidencia de retest para hallazgos críticos y altos dentro de un plazo definido. Los auditores revisan las credenciales de quien prueba.
- Dubai ISR (DESC) - entidades públicas de Dubái y sus proveedores. Convive con NESA; un mismo encargo puede evidenciar ambos.
- CBUAE, DFSA y ADGM (en inglés) - bancos y financieras onshore, firmas del DIFC, firmas del ADGM. En los tres casos se esperan pruebas independientes periódicas.
- VARA - proveedores de servicios de activos virtuales de Dubái. Test de intrusión independiente al menos anual bajo el Technology and Information Rulebook, con pruebas dirigidas por inteligencia cuando VARA lo considere proporcionado.
- ADHICS (en inglés) - proveedores sanitarios de Abu Dabi y sus proveedores tecnológicos.
Internacional
- PCI DSS - para quien almacene, procese o transmita datos de titulares de tarjeta. El requisito 11.4 obliga a test de intrusión internos y externos al menos anuales y tras cambios significativos, además de pruebas de segmentación cuando esta se usa para reducir el alcance.
- SOC 2 - no es una obligación prescriptiva, pero el test de intrusión es la evidencia que la mayoría de auditores espera para CC4.1 y CC7.1, y los clientes corporativos lo exigen cada vez más en el informe.
- ISO 27001 - gestión de vulnerabilidades técnicas del Anexo A, donde la prueba es la forma práctica de demostrar que el control opera.
Qué piden realmente los auditores
El informe es necesario y no suficiente. Cuatro artefactos componen un paquete de evidencias completo, y la mayoría de organizaciones llega solo con el segundo:
- Un documento de alcance - qué se probó, qué no, y por qué ese alcance era adecuado al control. Una prueba que excluyó justo los sistemas que importan al control falla por buena que fuera.
- El informe - hallazgos, severidades, detalle de reproducción y correspondencia con los controles implicados.
- Remediación documentada - qué corrigió y cuándo, y qué aceptó como riesgo con su motivo. Aceptar un riesgo está permitido; no registrar la decisión, no.
- Evidencia de retest - la confirmación de que los hallazgos críticos y altos están realmente cerrados, dentro del plazo que marque su marco. La expectativa de 90 días de NESA es la que pilla a la gente: un test en el mes once no deja margen para un retest antes de cerrar el ciclo.
Una carta de atestación —quién probó, qué alcance, qué fechas— une el paquete y suele ser lo que se archiva o se remite a un cliente. Cada encargo aquí incluye una.
La independencia es el requisito que se malinterpreta
Varios de estos marcos usan la palabra independiente, y tiene un significado concreto: la prueba no puede realizarla quien construyó u opera el sistema evaluado. Un equipo de seguridad interno probando la infraestructura de su propia organización satisface algunos marcos y otros no; el equipo que escribió la aplicación y luego la prueba no satisface ninguno.
Esa es buena parte de la razón de ser de los consultores externos en este mercado, y conviene contrastarlo con su obligación concreta antes de dar por hecho que su capacidad interna lo cubre. Equivocarse aquí sale caro, porque se descubre en la auditoría y no en el alcance.
Cómo acoto un encargo de cumplimiento
La primera conversación trata de la obligación, no de la tecnología: qué marco, qué control, qué plazo y si algo ha cambiado de forma material desde la última prueba. Con eso suelo poder decirle en una llamada si un solo encargo cubre todo lo que le aplica y qué debe incluir el alcance para producir evidencias que resistan una auditoría.
Lo que obtiene: precio cerrado antes de empezar, pruebas realizadas por la persona con la que habló, aviso inmediato de cualquier hallazgo crítico en lugar de una sorpresa en el documento final, un informe escrito para la dirección y para los ingenieros a la vez, acompañamiento durante la remediación, un retest y la carta de atestación. Hay un informe de muestra si quiere ver el formato primero (en inglés), y la página de precios para los órdenes de magnitud.
Por región
Si está en el Golfo, las páginas regionales profundizan en qué regímenes aplican y cómo interactúan: test de intrusión en Arabia Saudí y test de intrusión en los Emiratos. Para el resto, las páginas de servicios cubren la prueba en sí, y escribirme es la vía más rápida a una respuesta clara.
Preguntas sobre pruebas de cumplimiento
Normalmente sí, y resulta mucho más barato que la alternativa. El alcance técnico se solapa en gran medida —superficie externa, aplicaciones web y API, red interna, Active Directory, nube—, por lo que lo que cambia es la correspondencia con los controles y el formato del informe, no la prueba en sí. La condición es definirlo así desde el principio: un test acotado solo para PCI no producirá las evidencias que pide NESA, aunque el trabajo subyacente sea casi idéntico. Indíqueme en el alcance todos los regímenes que le aplican y el informe vinculará los hallazgos a cada uno.
No, y es el motivo más habitual de rechazo de evidencias. Un escaneo compara firmas conocidas con versiones conocidas y produce una lista; un test de intrusión encadena hallazgos para mostrar qué podría conseguir alguien con ellos. Los marcos lo dicen cada vez de forma más explícita, y los auditores detectan ya con soltura un informe de escaneo con portada de pentest: la señal es que cada hallazgo es un CVE y ninguno se conecta con otro. La diferencia en detalle (en inglés).
Cuatro cosas, y la mayoría de las organizaciones solo conserva la segunda. Un documento de alcance que muestre qué se probó y por qué ese alcance era adecuado. El informe en sí, con hallazgos, severidades y detalle de reproducción. La remediación documentada de los hallazgos críticos y altos. Y la prueba de un retest que confirme que las correcciones funcionaron, dentro del plazo que fije su marco: 90 días es lo habitual. Una carta de atestación que indique quién probó, con qué alcance y en qué fechas une todo, y suele ser la página que acaba archivada.
Anualmente es la base habitual: SAMA, NESA, VARA y PCI DSS coinciden ahí. Dos cosas acortan ese plazo: la clasificación como sistema crítico bajo los CSCC saudíes, que exige pruebas al menos cada seis meses, y los cambios significativos. Casi todos los marcos exigen volver a probar tras cambios materiales en el entorno, con independencia de cuándo fue la última prueba anual, de modo que una migración importante o una nueva aplicación expuesta a Internet reinicia el contador.
Normalmente sí, y las causas son previsibles: alcance demasiado estrecho para lo que exigía el control; prueba realizada por el equipo que construyó el sistema, por lo que no era independiente; ausencia de evidencia de retest; o un escaneo presentado como test de intrusión. Las cuatro son subsanables, y la solución suele ser un único encargo bien acotado, no un programa. Envíeme la observación del auditor y el informe anterior y le diré cuál de los cuatro casos fue antes de que gaste nada.
¿No sabe qué marco le aplica?
Una llamada breve suele bastar, y le dirá si un solo test puede cubrirlos todos.