Pentesting: tests de intrusión

Objetivos de un test de intrusión

Un test de intrusión responde a una pregunta que ni una herramienta automatizada ni una revisión documental resuelven: ¿hasta dónde llegaría hoy un atacante en tu perímetro? Según el contexto, un proyecto persigue uno o varios de estos objetivos.

• Medir la exposición real: las vulnerabilidades que de verdad se pueden explotar, no el listado teórico de parches pendientes.
• Demostrar el impacto: acceso a datos personales, control de una cuenta con privilegios, caída de un servicio que facturas.
• Priorizar la remediación por el riesgo que tiene en tu contexto y no solo por una puntuación genérica.
• Comprobar que los controles funcionan: WAF, segmentación de red, doble factor, registro y detección.
• Aportar evidencia ante un tercero: un cliente grande, una aseguradora o la entidad que audita tu ISO 27001 o tu conformidad con el ENS.
• Sostener una decisión técnica: validar una arquitectura antes de pasar a producción, elegir entre dos diseños.

Un test de intrusión fotografía en profundidad un alcance concreto en un momento dado; no sustituye a un análisis de vulnerabilidades recurrente, que cubre mucha más superficie pero sin explotación. Se complementan, y la diferencia está desarrollada en análisis de vulnerabilidades o pentest.

Enfoques: caja negra, caja gris y caja blanca

El enfoque define qué sabe el equipo antes de empezar. No cambia el realismo de la prueba, sino la profundidad que compras con el mismo presupuesto: una hora dedicada a redescubrir lo que ya sabes es una hora que no se dedica a buscar una vulnerabilidad.

Caja negra

Sin información previa: partimos de un nombre de dominio o de un rango de direcciones IP, igual que un atacante externo. Responde a la pregunta «¿qué aspecto tengo visto desde internet?» y saca a la luz activos olvidados y entornos de preproducción expuestos. Su límite es mecánico: lo que no se descubre, no se prueba.

Caja gris

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 proyectos, porque reproduce el escenario más frecuente —alguien que ya tiene credenciales, obtenidas por phishing o por reutilización de contraseñas— y cubre todos los roles dentro del tiempo contratado.

Caja blanca

Cuentas, documentación de arquitectura y código fuente. Nos permite remontar de un síntoma a su causa en el código, alcanzar rutas difíciles de provocar desde fuera y revisar la lógica de negocio. Indicado para una aplicación crítica o antes de un cambio estructural en producción.

Los tres se combinan: empezar en caja negra sobre el perímetro externo y pasar a caja gris una vez levantado el mapa. El enfoque elegido queda escrito en el presupuesto.

Alcance y planificación

La planificación determina el valor de un test mucho más que el número de jornadas vendidas. Ocupa aproximadamente una hora y deja cerrado lo siguiente.

• Los objetivos: direcciones URL, rangos de IP, cuentas por rol, suscripciones cloud y, si procede, repositorios de código.
• Las exclusiones: sistemas de terceros, entornos fuera de alcance, denegación de servicio y cualquier acción destructiva.
• La ventana de ejecución y una persona de contacto localizable por tu parte mientras dure el proyecto.
• Las reglas de enfrentamiento: hasta dónde se autoriza explotar, cómo se tratan los datos reales y qué hacemos ante un hallazgo crítico —te avisamos en el momento, sin esperar al informe—.
• El entorno: preproducción equivalente a producción cuando existe y, si no existe, producción con precauciones reforzadas.

Trabajamos con frecuencia sobre producción. La explotación se detiene en cuanto el impacto queda demostrado y no va más allá, y te comunicamos nuestras direcciones de origen; o nos las guardamos, si el ejercicio también debe medir tu capacidad de detección.

El presupuesto sale de esa planificación: jornadas, consultor asignado, fecha de entrega y plazo de retest. Y si el alcance que nos describes no justifica un test de intrusión, te lo decimos antes de cifrarlo.

Entregables: informe, sesión de resultados y retest

Lo que compras no es una semana de pruebas, sino lo que queda después. Tres entregables, ninguno opcional y todos en español.

El informe

Un resumen ejecutivo de dos páginas para la dirección: nivel de riesgo, hallazgos principales y decisiones que hay que tomar, sin jerga. Después, una ficha por vulnerabilidad con la descripción, la criticidad CVSS y la criticidad de negocio, la evidencia de explotación reproducible, la corrección recomendada y el esfuerzo estimado. Los anexos recogen el alcance, la metodología y la lista de pruebas realizadas, incluidas las que no dieron resultado: suele ser la parte más útil delante de quien audita. Se entrega en PDF, con una tabla de seguimiento importable.

La sesión de presentación de resultados

Una hora por videoconferencia o presencial, dirigida por la persona que ha hecho las pruebas y no por un comercial. Tu equipo de desarrollo pregunta, reproducimos en pantalla la explotación que haga falta y priorizamos juntos el plan de corrección.

El retest

Después de tus 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 adicional, dentro de los 90 días siguientes a la entrega del informe inicial: es una partida que el mercado suele facturar por jornadas.

Qué obliga realmente en España

El mercado repite dos errores: dar por hecho que NIS2 ya es ley aquí y anunciar sanciones que todavía no existen. Esto es lo que está en vigor y lo que dice literalmente sobre pruebas de seguridad.

El ENS: Real Decreto 311/2022

El Esquema Nacional de Seguridad es la norma que más pesa sobre el comprador español, y es explícito. El art. 31 somete los sistemas de categoría MEDIA y ALTA a una auditoría regular ordinaria al menos cada dos años, y el art. 38 separa los dos caminos de conformidad: autoevaluación para categoría BÁSICA y certificación para MEDIA y ALTA.

En el Anexo II, el refuerzo R6 del control [op.mon.3] desarrolla el ciclo de supervisión continua, y su subrequisito [op.mon.3.r6.3] se titula literalmente «Pruebas de penetración» para categoría ALTA. Hay una segunda puerta menos conocida: op.nub.1.2 a) exige, ya desde categoría BÁSICA, una «Auditoría de pruebas de penetración (pentesting)» cuando el servicio en la nube lo presta un tercero que no acredita conformidad con el ENS. Es decir, tu proveedor cloud puede obligarte a encargar un pentest aunque tu propio sistema sea BÁSICA.

Lo que aportamos es la prueba técnica que alimenta esa auditoría. La conformidad la declara o la certifica quien corresponde: Haxoris no está acreditada por ENAC, no es entidad de certificación y no expide ni el certificado de conformidad con el ENS ni el Distintivo de Conformidad. Lo desarrollamos en qué exige realmente el ENS sobre pentesting y en quién puede auditar el ENS.

NIS2 todavía no es derecho español

La Directiva (UE) 2022/2555 debía estar transpuesta el 17 de octubre de 2024. En España el Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad tuvo su 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 UE por esa falta de transposición (procedimiento INFR(2024)0270). Quien te venda hoy «obligaciones NIS2 en España» te está vendiendo un texto que no existe.

Lo que sí obliga ahora mismo es lo anterior: el Real Decreto-ley 12/2018 y su reglamento de desarrollo, el Real Decreto 43/2021, para operadores de servicios esenciales y proveedores de servicios digitales.

Y hay una pieza que no depende de ninguna ley española, porque es un reglamento y se aplica de forma directa: el Reglamento de Ejecución (UE) 2024/2690, que fija las medidas técnicas para proveedores de servicios en la nube, centros de datos, redes de distribución de contenidos, proveedores de servicios gestionados y de seguridad gestionados, mercados en línea, motores de búsqueda, plataformas de redes sociales y prestadores de servicios de confianza. Su Anexo, punto 6.5 «Pruebas de seguridad», exige una política de pruebas documentada, un alcance y una frecuencia establecidos en función del riesgo, una metodología y unos resultados documentados, y la corrección de los hallazgos críticos. Si tu entidad está en esa lista, ya tienes una obligación de pruebas aunque la ley de transposición siga sin publicarse. Más detalle en pentesting para NIS2 y en NIS2 en España: qué obliga hoy y qué no.

RGPD

El art. 32.1.d) del Reglamento (UE) 2016/679 incluye entre las medidas apropiadas «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento». Es la base jurídica más directa de un test de intrusión periódico, y por eso documentamos cada proyecto de modo que el informe aguante delante de la AEPD o de quien te audite: alcance, fechas, hallazgos y qué se volvió a probar después de corregir.

DORA y el sector financiero

El Reglamento (UE) 2022/2554 se aplica desde el 17 de enero de 2025. Sus arts. 24 y 25 obligan a un programa de pruebas de resiliencia digital, y el art. 26 añade, para las entidades que designe la autoridad competente, ejercicios TLPT al menos cada tres años. Esos ejercicios los ejecutan proveedores que cumplen el art. 27 y no son un servicio que prestemos: lo decimos en la sección siguiente.

PCI DSS

Si tratas datos de tarjeta, el requisito 11.4 de PCI DSS 4.0.1 exige tests de intrusión externos e internos anuales y después de cualquier cambio significativo, más pruebas de segmentación. Entregamos el informe con el nivel de detalle que espera tu QSA.

Lo que no hacemos

Decirlo en voz alta es lo que hace creíble el resto de la página. Hay cuatro cosas que en España no podemos ofrecerte, y ninguna se arregla con una frase ambigua.

• No certificamos. No somos entidad de certificación acreditada por ENAC y no expedimos certificados de conformidad con el ENS, 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 con la entidad auditora que elijas.
• No realizamos TLPT. Los ejercicios de pruebas guiadas por amenazas del marco TIBER-ES, coordinado por el Banco de España, exigen proveedores que cumplan el art. 27 de DORA. 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.
• No somos una empresa de seguridad privada. Prestamos servicios de seguridad informática; esta actividad no figura entre las reservadas del art. 5.1 de la Ley 5/2014 y no requiere autorización del Ministerio del Interior. Nuestro reconocimiento OSINT se limita a la superficie de exposición de la organización a partir de fuentes abiertas, dentro del alcance contratado y sin investigar a personas concretas.

Y una quinta, menos jurídica: no prometemos que un test de intrusión deje tus sistemas sin vulnerabilidades. Deja una lista priorizada, unas evidencias y una fecha; lo demás depende de que las correcciones se desplieguen, que es exactamente lo que el retest comprueba.

Tratamiento de datos y soberanía

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 —capturas, extractos de registros, notas de prueba, informes— se almacena y se respalda en la Unión Europea.

La consecuencia práctica se nota en cuanto tu departamento jurídico revisa 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 sus países se te comunica antes de firmar y cualquier cambio se te notifica. Al no estar sujetos a la jurisdicción de Estados Unidos, no nos alcanza la CLOUD Act.

Los datos de prueba van cifrados en reposo y en tránsito, solo acceden a ellos las personas asignadas a tu proyecto y se borran en el plazo pactado en el contrato, por defecto al vencer el plazo de retest. El informe es tuyo: no lo reutilizamos y no mencionamos tu nombre sin tu autorización por escrito.

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