Otros servicios

Objetivos: las preguntas que un test de intrusión no responde

Un test de intrusión (pentesting) responde a una pregunta muy concreta: ¿se puede entrar, y hasta dónde? No dice por qué existe el fallo, ni si el ajuste que lo hizo posible se repite en otros cincuenta servidores. De eso se ocupan los servicios reunidos en esta página. Según el caso, un proyecto persigue uno o varios de estos objetivos.

• Entender de dónde viene un hallazgo: una vulnerabilidad explotada durante un pentest casi siempre nace de una decisión de configuración, de un permiso demasiado ancho o de un control de autorización escrito con prisa.
• Reducir la superficie de exposición antes de ponerla a prueba: bastionar lo que está manifiestamente expuesto sale más barato que hacer que te lo demuestren y corregirlo con el reloj en contra.
• Decidir una cuestión de arquitectura: una migración a la nube, la apertura de una API a socios, el rediseño de la autenticación. Sale mejor hablarlo antes de subirlo a producción que después.
• Responder a una exigencia contractual: el cuestionario de seguridad que te ha mandado un cliente grande, una cláusula de un pliego o la preparación de una auditoría interna de la ISO/IEC 27001.
• Hacer que alguien lea el código de los caminos críticos: autenticación, autorización, pago, tratamiento de datos personales e integraciones con terceros.
• Poner orden después de una auditoría: ya tienes la lista de desviaciones y lo que falta es quien se siente con tu equipo a cerrarlas en un orden que la producción aguante.

Si dudas entre varios de estos servicios, cuéntanos qué ha disparado la pregunta. Te decimos cuál la responde —aunque sea el más barato— o te llevamos a una auditoría de ciberseguridad completa si lo que describes lo justifica.

Enfoques: caja negra, caja gris y caja blanca

El mercado español ordena el trabajo de seguridad ofensiva por el nivel de información que recibe quien lo ejecuta. Aquí se aplica la misma rejilla, con una particularidad: la consultoría, la auditoría de configuración, el bastionado y la revisión de código se hacen casi siempre en caja blanca, porque cegarse a uno mismo no aporta nada.

Caja negra (black box)

Sin información previa, sin cuentas y sin documentación. Mide lo que descubre por su cuenta quien ataca desde fuera. En un trabajo de consultoría o de bastionado tiene un único uso: establecer de entrada qué revela tu exposición pública, antes de mirar hacia dentro.

Caja gris (grey box)

Una cuenta, un acceso limitado, documentación parcial. Es el enfoque cuando hay que juzgar un entorno sin obtener privilegios de administración: la revisión de un tenant cloud con un rol de solo lectura, o la de un perímetro de aplicación con una cuenta de usuario corriente.

Caja blanca (white box)

Acceso completo: exportaciones de configuración, matriz de permisos, esquemas de arquitectura, código fuente y entrevistas con tu equipo. Es el modo por defecto de estos servicios. A igual presupuesto, la caja blanca cubre varias veces más terreno que la caja negra, porque el tiempo se va en analizar y no en descubrir.

El enfoque se acuerda en la planificación y no queda cerrado para siempre: una revisión de configuración en caja blanca se prolonga a menudo con una comprobación en caja gris, para confirmar que la desviación corregida ya no es explotable. Los tres enfoques están desarrollados en nuestra página de test de intrusión.

Qué obliga realmente en España

Aquí es donde el mercado más se equivoca: se venden obligaciones de NIS2 que todavía no existen en derecho español y se pasa por alto lo que sí está en vigor y es literal. Esto es lo que hoy alcanza a un trabajo de configuración, bastionado o desarrollo seguro, con el artículo delante.

El ENS: Real Decreto 311/2022

El Esquema Nacional de Seguridad es la norma que más pesa sobre el comprador español, y buena parte de lo que exige es exactamente este trabajo. En el Anexo II, [op.exp.2] Configuración de seguridad y [op.exp.3] Gestión de la configuración de seguridad son, en la práctica, la obligación de bastionar y de mantener bastionado; [mp.sw.1] Desarrollo de aplicaciones y [mp.sw.2] Aceptación y puesta en servicio son lo que sostiene el acompañamiento al desarrollo seguro.

La comprobación llega después por dos vías. El art. 31 somete los sistemas a una auditoría regular ordinaria al menos cada dos años, y el art. 38 separa los dos caminos de conformidad: autoevaluación en categoría BÁSICA y certificación en MEDIA y ALTA. Dentro del Anexo II, el refuerzo R6 del control [op.mon.3] desarrolla la supervisión continua, y su subrequisito [op.mon.3.r6.3] se titula literalmente «Pruebas de penetración» para categoría ALTA. Hay además una puerta menos conocida: op.nub.1.2 a) exige, ya desde 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.

Lo que aportamos es el trabajo técnico que alimenta esa auditoría y las evidencias con las que se sostiene. La conformidad la declara o la certifica quien corresponde: no somos entidad de certificación acreditada por ENAC y no expedimos certificados de conformidad con el ENS ni el Distintivo de Conformidad. El desarrollo completo está 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, nunca ha llegado a las Cortes, y 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 esa falta de transposición (procedimiento INFR(2024)0270). Quien hoy te facture un bastionado «para cumplir NIS2 en España» te está facturando un texto que aún no existe.

Lo que sí obliga ahora mismo es el Real Decreto-ley 12/2018 con su reglamento de desarrollo, el Real Decreto 43/2021, para operadores de servicios esenciales y proveedores de servicios digitales. Y 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, cuyo Anexo, en el punto 6.5 «Pruebas de seguridad», exige una política de pruebas documentada, un alcance y una frecuencia fijados en función del riesgo, una metodología y unos resultados documentados y la corrección de los hallazgos críticos. Ese punto vive dentro del bloque del Anexo dedicado a la seguridad en la adquisición, el desarrollo y el mantenimiento de los sistemas, que es justo el terreno de esta página. 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». Una revisión periódica de configuración, documentada y con fecha, es exactamente un proceso de ese tipo; y el art. 32.1.b), que pide confidencialidad, integridad, disponibilidad y resiliencia permanentes, es el que respalda el bastionado. Por eso el informe recoge alcance, fechas, método, hallazgos y qué se volvió a comprobar después de corregir: es el expediente que se enseña ante la AEPD o ante quien te audite.

ISO/IEC 27001

En el Anexo A de la versión de 2022, el control A.8.9 Gestión de la configuración es el bastionado; A.8.25 Ciclo de vida de desarrollo seguro y A.8.28 Codificación segura son el acompañamiento al desarrollo. Podemos realizar la auditoría interna de la cláusula 9.2 o la revisión previa al paso ante el organismo de certificación, y contrastamos los controles del Anexo A uno a uno. El certificado, en cambio, lo expide siempre una entidad de certificación acreditada —AENOR, Bureau Veritas o EQA, entre otras—, y las reglas de imparcialidad impiden que quien asesora certifique a su propio cliente. Cómo encaja con nuestro trabajo está en pentesting para ISO 27001.

DORA y el sector financiero

El Reglamento (UE) 2022/2554 se aplica desde el 17 de enero de 2025. Obliga a un programa de pruebas de resiliencia digital y, en su art. 26, añade ejercicios TLPT al menos cada tres años para las entidades que designe la autoridad competente. Esos ejercicios exigen proveedores que cumplan el art. 27 y no son un servicio que prestemos; lo decimos más abajo con todas las letras.

Última revisión de las referencias normativas citadas: 12 de septiembre de 2026.

Alcance y planificación

Lo que decide el valor de este tipo de proyecto es la planificación, mucho más que el número de jornadas vendidas. Ocupa alrededor de una hora y deja cerrado lo siguiente, por escrito, antes de tocar nada.

• Los objetivos: qué sistemas entran —servidores, dominios, suscripciones cloud, tenant de Microsoft 365, repositorios de código, componentes concretos de una aplicación— y con qué versión o rama se trabaja.
• Las exclusiones: sistemas de terceros, entornos fuera de alcance y todo aquello que no se va a tocar. Lo que queda fuera se escribe, no se sobreentiende.
• La ventana de trabajo: cuándo se aplican los cambios de bastionado, en qué franja de mantenimiento y con qué plan de vuelta atrás si algo deja de funcionar.
• Las reglas del encargo: qué comprobaciones se ejecutan contra sistemas vivos, cómo se tratan los datos reales que aparezcan, quién autoriza cada cambio y qué hacemos ante un hallazgo crítico, que es avisarte en el momento y no esperar al informe.
• El entorno: preproducción o producción, con accesos nominales y trazables, y una persona de contacto localizable por tu parte mientras dure el proyecto.
• La autorización por escrito: el mandato firmado que delimita el alcance. Es lo que hace lícita la intervención frente al art. 197 bis del Código Penal, y ningún trabajo empieza sin él.

Del alcance sale el presupuesto: jornadas, persona asignada, fecha de entrega y plazo del retest. Y si lo que nos describes no justifica este servicio —porque lo que necesitas es un análisis de vulnerabilidades recurrente, un test de intrusión en toda regla o una concienciación en ciberseguridad para tu plantilla—, te lo decimos antes de cifrarlo.

Entregables: informe, sesión de resultados y retest

Lo que compras no es un PDF, sino con qué decidir y con qué corregir. Cuatro entregables, todos en español y ninguno opcional.

El informe

Abre con un resumen ejecutivo de dos páginas para la dirección, sin jerga: situación observada, riesgos principales y decisiones que hay que tomar. Después va una ficha por hallazgo con descripción, evidencia, causa, valoración del riesgo en tu contexto, esfuerzo estimado y la corrección concreta —el parámetro, la directiva o el comando, no un «revísese la configuración»—. Los anexos recogen el alcance revisado, el método seguido y los puntos comprobados sin desviación, que suele ser la parte más útil delante de quien te audita después. Se entrega en PDF, con una tabla de seguimiento importable a tu gestor de incidencias.

El plan de acción

Los hallazgos se ordenan en tres olas: lo que se corrige en unos días, lo que pide un proyecto trimestral y lo que es una decisión de inversión. Cada línea lleva su riesgo y su esfuerzo estimado, de modo que el documento se lleva tal cual al comité de dirección sin que nadie tenga que rehacerlo en una hoja de cálculo.

La sesión de presentación de resultados

Una hora por videoconferencia, o presencial si lo prefieres, dirigida por la persona que ha hecho el trabajo y no por un comercial. Tu equipo pregunta, justificamos cada valoración y corregimos el informe si se nos había escapado un dato de contexto que cambia la criticidad.

El retest, incluido

Cuando hayas desplegado las correcciones volvemos a comprobar los hallazgos registrados y emitimos un informe de retest —la contraauditoría— que acredita qué está cerrado y qué sigue abierto. Va incluido en el precio, sin coste adicional, dentro de los 90 días siguientes a la entrega del informe inicial. Es justo la partida que el mercado suele facturar aparte por jornadas, y es el documento que nuestros clientes acaban enviando a su cliente final o a su aseguradora.

Antes de firmar te damos un informe de ejemplo anonimizado: sabes exactamente qué vas a recibir y sobre qué estás comparando presupuestos.

Lo que no hacemos

En un catálogo abierto, la frontera importa tanto como el servicio. Decirla en voz alta es lo que hace creíble el resto de la página, y hay cinco cosas que en España no podemos ofrecerte.

• Revisamos y bastionamos, 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 el certificado de la norma ISO/IEC 27001. Producimos los hallazgos técnicos y el expediente de evidencias en los que se apoya quien sí certifica.
• No realizamos TLPT. Los ejercicios guiados por amenazas del marco TIBER-ES, coordinado por el Banco de España, exigen proveedores que cumplan el art. 27 del Reglamento (UE) 2022/2554. 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 exige 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 a partir de fuentes abiertas se limita a la superficie de exposición de la organización, dentro del alcance contratado y sin indagar sobre personas concretas.
• No auditamos como terceros lo que hemos bastionado nosotros. Si aplicamos los cambios, quien los revise después con valor de auditoría independiente tiene que ser otro. Es la misma regla de imparcialidad que impide a un consultor certificar a su cliente, y la aplicamos contra nuestro propio interés comercial.

Tampoco revendemos equipos, licencias ni herramientas de nadie. En esta página no hay ninguna recomendación escrita para venderte después un producto, que es lo único que hace que el informe valga algo delante de un tercero.

Tratamiento de datos y soberanía

Este trabajo toca material especialmente sensible: exportaciones de configuración, matrices de permisos, esquemas de red y, a menudo, código fuente propietario. Conviene saber dónde acaba todo eso. Haxoris es una empresa establecida en la Unión Europea, con oficinas en Bratislava y Praga. El equipo trabaja desde la Unión Europea y lo que se genera durante el proyecto se almacena y se respalda en la Unión Europea.

La consecuencia 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 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, tampoco nos alcanza la CLOUD Act.

Con el código fuente somos más estrictos todavía. Si prefieres que no salga de tus sistemas, la revisión se hace dentro de tu propio entorno, con accesos nominales y de solo lectura, bajo acuerdo de confidencialidad y sin copia local. Cuando el repositorio sí se nos entrega, viaja cifrado, solo acceden a él las personas asignadas a tu proyecto y se borra en el plazo pactado, por defecto al vencer el plazo del retest. El informe es tuyo: no lo reutilizamos y no citamos tu nombre sin tu autorización por escrito.

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