Metodologías de testing

Objetivos: qué aporta un marco de referencia a tu test

Un marco de testing no es papeleo. Es la herramienta que convierte una semana de trabajo ofensivo en un resultado verificable por alguien que no estuvo en la sala. Sea cual sea el alcance, lo usamos para cinco cosas.

• Fijar la cobertura antes de empezar: la lista de puntos a comprobar es pública y queda cerrada en la planificación. Sabes qué estás comprando y qué no.
• Hacer comparable el resultado: de un año a otro y de un proveedor a otro. Un informe alineado con el WSTG lo relee sin traducción el equipo que venga después.
• Dar valor a la ausencia de hallazgo: «no hay inyección SQL» solo vale algo si se puede enseñar qué comprobaciones se ejecutaron para afirmarlo.
• Sostener el informe ante un tercero: la entidad que audita tu ISO 27001, un cliente grande o tu aseguradora preguntan por el método, no solo por la conclusión.
• Cerrar el presupuesto con criterio: las jornadas salen del número de puntos que hay que cubrir y del tamaño del alcance, no de una impresión comercial.

Un marco no sustituye al criterio de quien prueba: ninguna lista pública contiene tus reglas de negocio, y ahí es donde suelen esconderse las vulnerabilidades más caras. Lo que garantiza es que el terreno conocido se ha recorrido antes de llegar a los casos particulares. Aplicamos esa combinación tanto en nuestros tests de intrusión como en la auditoría de ciberseguridad.

Cómo encajan entre sí

Estos nombres circulan juntos, como si fueran intercambiables. No lo son: cada uno responde a una pregunta distinta, y es la combinación la que cubre a la vez la superficie y la profundidad.

OWASP Top 10: una lista de riesgos, no un plan de pruebas

El Top 10 ordena las categorías de riesgo aplicativo más extendidas —control de acceso roto, fallos criptográficos, inyección, diseño inseguro— y sirve de idioma común entre tu equipo de desarrollo, tu dirección y nosotros. Su límite está en su propia naturaleza: diez categorías no son un procedimiento, y un informe que anuncia «cubre el Top 10» no dice nada sobre qué se intentó. Nuestra página de OWASP desglosa cada categoría.

OWASP WSTG: el procedimiento, comprobación por comprobación

El Web Security Testing Guide es el manual operativo que hay detrás de un test aplicativo completo: cientos de comprobaciones ordenadas por tema —configuración, autenticación, gestión de sesión, autorización, validación de entradas, lógica de negocio, lado cliente—. Es lo que estructura la fase de pruebas de un pentesting de aplicaciones web, y el informe recoge los identificadores de las comprobaciones ejecutadas. Ver el detalle del WSTG.

OWASP ASVS: la medida, por nivel de exigencia

El Application Security Verification Standard le da la vuelta a la lógica: en lugar de buscar vulnerabilidades, enumera requisitos verificables repartidos en tres niveles de garantía. La cobertura se vuelve una cifra —tantos requisitos de nivel 2 verificados, tantos incumplimientos— y deja de ser una apreciación. Es el marco al que recurrir cuando un cliente o la entidad que audita pide una prueba de seguridad aplicativa, o cuando quieres escribir un objetivo exigible en un pliego. Ver los niveles del ASVS.

MASVS y MASTG: los equivalentes móviles

El Mobile Application Security Verification Standard y el Mobile Application Security Testing Guide son, para iOS y Android, lo que el ASVS y el WSTG son para web: almacenamiento local, fijación de certificado, criptografía, autenticación y resistencia a la ingeniería inversa. Los aplicamos en cada pentesting de aplicaciones móviles, probando juntos el binario y la API.

PTES y NIST SP 800-115: el recorrido del proyecto

El Penetration Testing Execution Standard y la publicación NIST SP 800-115 no describen qué buscar, sino cómo conducir un proyecto de principio a fin: planificación, reconocimiento, modelado de amenazas, análisis de vulnerabilidades, explotación, postexplotación e informe. Son los que estructuran nuestra auditoría de infraestructura interna y externa y los ejercicios de Red Team, donde ningún catálogo aplicativo resulta aplicable.

MITRE ATT&CK: la lectura defensiva

ATT&CK es el catálogo de tácticas y técnicas observadas en atacantes reales. Enganchamos a él cada acción ofensiva de un ejercicio de Red Team, y de ahí sale una matriz de lo que tu supervisión detectó, lo que registró sin alertar y lo que no llegó a ver: para un equipo de detección, eso es una lista de reglas por escribir.

Según el alcance se suman los CIS Benchmarks y las guías de arquitectura del proveedor en una auditoría de cloud, el OWASP Top 10 for LLM Applications en el pentesting de integraciones de IA y LLM y el OWASP IoT Top 10 junto al análisis de hardware y radio en OT, ICS e IoT.

Enfoques: caja negra, caja gris y caja blanca

El marco dice qué se comprueba; el enfoque dice con cuánta información. Son dos decisiones independientes: el WSTG se puede recorrer en caja negra igual que en caja blanca, pero no con la misma profundidad por el mismo presupuesto.

Caja negra (black box)

Sin información previa: un nombre de dominio o un rango de direcciones IP, como un atacante desde fuera. Responde a la pregunta «¿qué aspecto tengo visto desde internet?» y saca a la luz los activos olvidados, los entornos de preproducción expuestos y los servicios que quedaron abiertos. Su límite es mecánico: lo que no se descubre no se prueba, y el tiempo dedicado a descubrir no se dedica a probar.

Caja gris (grey box)

Una cuenta por cada rol de la aplicación y documentación funcional básica. Es el enfoque que recomendamos en la mayoría de los proyectos: reproduce el escenario más frecuente —alguien que ya dispone de una cuenta, obtenida por phishing o por reutilización de contraseñas— y permite cubrir todos los roles, es decir, el grueso de los controles de acceso, dentro del tiempo contratado.

Caja blanca (white box)

Cuentas, documentación de arquitectura y acceso al código fuente. El WSTG y el ASVS rinden entonces al máximo: remontamos de un síntoma a su causa en el código, alcanzamos rutas de ejecución difíciles de disparar desde fuera y revisamos la lógica de negocio. Indicada para una aplicación crítica, una revisión de diseño o una verificación ASVS de nivel 2 o 3.

Ninguno es más «realista» que los otros: lo que mueven es el equilibrio entre descubrimiento y profundidad. La tabla comparativa está en la página de pentesting y test de intrusión.

Qué obliga realmente en España

Conviene separar lo que está en vigor de lo que se anuncia. Hoy, en España, ninguna norma te obliga a contratar a un proveedor autorizado para hacer un test ni certifica ninguna metodología. Lo que las normas piden es otra cosa: que las pruebas estén documentadas, con un alcance justificado por el riesgo y con una metodología y unos resultados que se puedan enseñar. Justo eso es lo que esta página describe.

NIS2 todavía no es ley española

La Directiva (UE) 2022/2555 no está transpuesta. El Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad solo ha tenido una primera lectura en el Consejo de Ministros, el 14 de enero de 2025, y no ha llegado a las Cortes; el 9 de julio de 2026 la Comisión Europea llevó a España ante el Tribunal de Justicia de la Unión Europea por ese retraso, en el procedimiento INFR(2024)0270. Lo que sí está en vigor es el régimen anterior: el Real Decreto-ley 12/2018 y el Real Decreto 43/2021 que lo desarrolla.

Hay además una pieza que no necesita transposición y que se cita muy poco. El Reglamento de Ejecución (UE) 2024/2690 es directamente aplicable y, en el punto 6.5 «Pruebas de seguridad» de su anexo, exige a las entidades digitales que enumera una política de pruebas documentada, un alcance y una frecuencia determinados en función del riesgo, una metodología y unos resultados documentados y la corrección de los hallazgos críticos. Es el texto europeo que más de cerca describe lo que hay en esta página. Ampliado en pentesting para NIS2 y en NIS2 en España: qué obliga hoy y qué no.

ENS: la auditoría es periódica y la metodología se nombra

El Real Decreto 311/2022 fija en el art. 31 una auditoría ordinaria regular al menos cada dos años, y el art. 38 separa los dos caminos de conformidad: autoevaluación en categoría BÁSICA, certificación en MEDIA y ALTA. En el Anexo II, el refuerzo R6 del control [op.mon.3] incluye un subrequisito cuyo título es literalmente «Pruebas de penetración» —[op.mon.3.r6.3], exigible en categoría ALTA—, y el requisito op.nub.1.2 a) pide una auditoría de pentesting sobre los servicios en la nube de terceros que no sean conformes al ENS, ya desde la categoría BÁSICA.

Dos precisiones que ahorran malentendidos. La primera es de vocabulario: el ENS usa «intrusión» en otro sitio, el control [op.mon.1] Detección de intrusión, que es un IDS/IPS y no tiene relación con esto. La segunda es de reparto de papeles: nosotros aportamos la prueba técnica y el informe; la certificación la expide una entidad de certificación acreditada por ENAC, y Haxoris no lo es. Está desarrollado en qué exige realmente el ENS sobre pentesting y en quién puede auditar el ENS.

RGPD y DORA

El art. 32.1.d) del RGPD exige «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas». Regulares, y con la eficacia comprobada: un informe que nombra el marco aplicado y enumera las comprobaciones ejecutadas es la forma habitual de acreditar ese proceso ante la AEPD o ante quien te audite.

En el sector financiero, el Reglamento (UE) 2022/2554 (DORA) se aplica desde el 17 de enero de 2025 y su art. 26 impone a las entidades designadas pruebas guiadas por amenazas (TLPT) al menos cada tres años. Ese ejercicio exige proveedores que cumplan el art. 27 y en España se coordina a través del marco TIBER-ES del Banco de España: no lo prestamos, y lo decimos con todas las letras más abajo.

Última revisión de las referencias normativas de esta página: 12 de septiembre de 2026. Son normas en evolución; si alguna cambia, se corrige aquí.

Alcance y planificación: lo que se acuerda antes de empezar

La metodología dice qué se comprueba; el alcance dice sobre qué. Se cierra por escrito antes de la primera petición, porque un test improvisado no es comparable ni defendible, y porque esa firma es exactamente lo que convierte la misma acción técnica en un servicio contratado y no en un delito.

• Los objetivos: dominios, direcciones IP, aplicaciones, API, cuentas, instalaciones o perfiles de personas, enumerados uno a uno. Lo que no está en la lista no se toca.
• Las exclusiones: sistemas de terceros sin autorización de quien los titulariza, ventanas críticas de negocio, tipos de prueba que descartas —la denegación de servicio, por defecto— y cualquier otra restricción. Todo lo excluido se escribe también en el informe, para que la cobertura se lea sin sorpresas.
• El entorno: producción o preproducción. La preproducción elimina riesgo operativo, pero solo sirve si es equivalente; si no lo es, lo decimos y queda reflejado en la cobertura.
• El enfoque y los accesos: caja negra, gris o blanca, con lo que cada una exige —una cuenta por rol, documentación funcional y, en caja blanca, el código fuente—.
• La ventana de ejecución: fechas, franja horaria, si se prueba fuera de horario laboral y a quién se avisa. En un ejercicio de Red Team, la lista de personas informadas es deliberadamente corta.
• Las reglas de enfrentamiento: hasta dónde llega la explotación, qué se hace ante un hallazgo crítico, cómo se detiene el ejercicio y por qué canal se contacta fuera de hora.
• Los contactos y la autorización: quién firma por tu parte, quién responde durante la ejecución y, cuando el sistema está alojado en un proveedor, la autorización por escrito de ese proveedor.

De ese documento sale el cálculo de jornadas, que es la parte que casi nadie enseña: número de puntos de control del marco aplicable por tamaño del alcance, y no una impresión comercial. Si el alcance cambia a mitad de proyecto, se documenta y se recalcula; no se absorbe en silencio a costa de la cobertura. El desglose de precios está en cuánto cuesta un pentest en España.

Entregables: informe, sesión de resultados y retest

Una metodología solo se ve en los entregables. Los nuestros están hechos para que la cobertura se pueda comprobar y no solo declarar.

El informe

Dos páginas de resumen ejecutivo sin jerga y, a continuación, una ficha por hallazgo: descripción, criticidad CVSS y criticidad para tu negocio, evidencia de explotación reproducible, corrección recomendada y esfuerzo estimado. Los anexos recogen el alcance, el marco aplicado y la lista de comprobaciones ejecutadas, incluidas las que no dieron resultado, que suele ser la parte más útil delante de quien audita. En español, en PDF y con una tabla de seguimiento que puedes importar a tu herramienta de tickets.

La sesión de presentación de resultados

Una hora por videoconferencia, dirigida por la persona que ha hecho las pruebas y no por alguien de ventas. Tu equipo de desarrollo pregunta, repetimos en pantalla la explotación que haga falta y priorizamos juntos el plan de remediación.

El retest

Cuando hayas desplegado las correcciones repetimos las pruebas sobre las vulnerabilidades identificadas y emitimos un informe de retest que acredita su cierre. Va incluido en el precio, sin coste añadido, dentro de los 90 días siguientes a la entrega del informe inicial. Es una de las pocas partidas que el mercado factura aparte, por jornadas.

Si prefieres juzgar el entregable antes que el argumento, pídenos un informe de ejemplo anonimizado.

Lo que no hacemos

Decirlo es lo que hace creíble todo lo anterior. Hay cuatro cosas que esta página no te está ofreciendo, y ninguna se arregla con una frase ambigua.

• No certificamos, ni el ENS ni la ISO 27001. Haxoris no está acreditada por ENAC y no expide certificados de conformidad con el ENS, ni el Distintivo de Conformidad, ni certificados ISO 27001. Emitimos un informe técnico de resultados que te sirve de evidencia ante el organismo que sí certifica, y trabajamos junto a la entidad auditora que elijas.
• OWASP no acredita a nadie, y no lo aparentamos. No existe una «metodología OWASP certificada» ni un sello de proveedor OWASP: el Top 10, el WSTG, el ASVS y el MASTG son documentos públicos y gratuitos que cualquiera puede aplicar. Lo que sí puedes exigir a un proveedor no es un sello, sino que el informe diga qué identificadores de comprobación se ejecutaron.
• No realizamos TLPT. Las pruebas guiadas por amenazas del art. 26 de DORA, coordinadas en España a través del marco TIBER-ES del Banco de España, exigen proveedores que cumplan el art. 27. Un ejercicio de Red Team nuestro puede servirte de preparación previa, pero no lo sustituye.
• No trabajamos con información clasificada. El acceso a esa información requiere habilitación de seguridad de la Oficina Nacional de Seguridad; no la tenemos y no nos presentamos a esos pliegos. Nuestros informes sí citan por número las guías CCN-STIC públicas que resulten aplicables, lo cual no supone relación alguna con el Centro Criptológico Nacional ni figurar en el catálogo CPSTIC.

Y una quinta, menos jurídica: ninguna metodología garantiza que no quede nada. Lo que garantiza un marco publicado es que el terreno conocido se ha recorrido antes de llegar a los casos particulares, y que puedes comprobar cuál era ese terreno.

Tratamiento de datos y soberanía

Un test conducido con método genera material sensible antes que un informe: capturas, extractos de registros, volcados parciales, la traza de cada comprobación ejecutada y, al final, un documento que es literalmente el mapa de tus puntos débiles. Dónde vive ese material es una pregunta de metodología tanto como de contrato, y por eso va en esta página y no solo en el anexo jurídico.

Haxoris es una empresa establecida en la Unión Europea, con oficinas en Bratislava y Praga. El equipo interviene desde la Unión Europea y todo lo que se genera durante un proyecto se almacena y se respalda en la Unión Europea. La consecuencia práctica se nota en cuanto tu departamento jurídico abre el contrato: el RGPD se nos aplica de forma directa, así que no hay transferencia internacional del capítulo V que justificar, ni cláusulas contractuales tipo que negociar, ni evaluación de impacto de transferencias que redactar. Actuamos como encargado del tratamiento en el sentido del art. 28 y el contrato lo recoge; la relación de subencargados y los países en los que operan se te comunica antes de firmar. Al no estar sujetos a la jurisdicción de Estados Unidos, tampoco nos alcanza la CLOUD Act.

El material de prueba viaja y se guarda cifrado, solo accede a él el personal asignado a tu proyecto y se borra en el plazo pactado, por defecto al vencer la ventana de retest. El informe es tuyo: no lo reutilizamos y no citamos tu nombre sin autorización por escrito.

Si la duda de fondo es si tiene sentido contratar pentesting a una empresa que no está establecida en España, la respondemos con derecho aplicable y con números en contratar una empresa de pentesting no española.

Para seguir leyendo

Cuatro lecturas que prolongan esta página, por el lado del método y por el del marco normativo español.

• Qué es el pentesting — la definición y el recorrido de un proyecto, sin jerga.
• Análisis de vulnerabilidades o pentest — qué demuestra cada uno y cuándo basta con el primero.
• Qué exige realmente el ENS sobre pentesting — el art. 31, el art. 38 y el subrequisito [op.mon.3.r6.3], leídos del Real Decreto 311/2022.
• Cómo elegir una empresa de pentesting — las preguntas que conviene hacer antes de firmar.