Qué es el pentesting y cuándo lo necesita una empresa

Un escaneo, una auditoría y unas pruebas de penetración son tres trabajos con tres precios. Cuál responde a su pregunta, y qué exige de verdad el derecho español.

Usted pide un presupuesto para la seguridad de su sitio web y recibe tres que se diferencian por un factor de diez, y en uno pone «escaneo de seguridad», en el segundo «auditoría de seguridad», en el tercero «prueba de penetración», que es el pentesting, pero en los tres está la misma palabra «seguridad», que no dice nada de lo que realmente los diferencia. No son un mismo trabajo en tres grados ni tres precios por lo mismo, sino tres trabajos distintos que responden a tres preguntas distintas, así que el primer paso no es comparar precios, sino entender a cuál de esas tres preguntas quiere usted realmente una respuesta.

Este artículo responde a dos: que es el pentesting y si lo necesita precisamente su empresa. La segunda pregunta es la más importante, porque para la mayoría de las pequeñas y medianas empresas españolas ninguna norma nombra unas pruebas de penetración como obligación, y un presupuesto que lo silencia le vende el servicio correcto en el momento equivocado.

Lo escribimos vendiendo una auditoría de seguridad web, y no hay contradicción, porque una auditoría en la que hay sitio para una comprobación manual no es el mismo trabajo que unas pruebas de penetración que exige una norma, y la empresa que compra las segundas cuando necesitaba la primera paga más y se entera de menos.

Que es el pentesting: tres trabajos con nombres parecidos

La terminología del sector está sucia aquí, pero debajo hay un límite claro que nombra mejor una autoridad de estándares: NIST SP 800-115 define las pruebas de penetración como una comprobación de seguridad en la que los evaluadores imitan ataques reales para encontrar caminos alrededor de la protección del sistema, y señala que buscan combinaciones de vulnerabilidades, no hallazgos sueltos. Esa misma publicación describe el escaneo de vulnerabilidades como una técnica con la que se identifican recursos y las vulnerabilidades conocidas que les corresponden.

En la práctica eso son cuatro trabajos distintos, y conviene nombrar cada uno por separado. El escaneo es automático, y en él una herramienta compara su sistema con una base de datos de vulnerabilidades conocidas y devuelve una lista. La evaluación de vulnerabilidades es esa misma lista, que una persona ha comprobado y ordenado, por lo general sin explotar ninguna de las vulnerabilidades encontradas. Las pruebas de penetración son un trabajo dirigido por una persona, en el que los puntos débiles encontrados se explotan y se encadenan para averiguar hasta dónde llega de verdad un atacante. Una auditoría de cumplimiento responde a una pregunta del todo distinta: si el sistema se ajusta a un estándar o a una norma nombrados.

El límite entre los tres primeros lo formula con más claridad el estándar de tarjetas de pago, y no lo hace con una definición, sino con el objetivo: las directrices del PCI Security Standards Council distinguen las pruebas de penetración del escaneo por la finalidad: el escaneo identifica, ordena e informa de las vulnerabilidades; la prueba busca modos de explotarlas para eludir la protección del sistema. El mismo consejo añade en su estándar los dos bordes: el escaneo por sí solo no es una prueba de penetración, y un trabajo que solo intenta explotar los hallazgos del escáner tampoco es suficiente.

Por eso la pregunta «¿necesita usted una prueba de penetración?» no es una pregunta de presupuesto, sino de a qué quiere una respuesta: si en su sistema hay puntos débiles conocidos, o si alguien puede hacer de verdad algo con ellos.

Qué responde cada uno y qué no dice

El escaneo responde rápido y barato, y su punto débil es el contexto, porque la herramienta no sabe cuál de las cien filas marcadas está en su formulario de pago y cuál en un entorno de ensayo al que nadie llega desde internet, y tampoco sabe que dos fallos inofensivos por separado dan juntos acceso a la base de datos — así que la lista es el comienzo del trabajo, no el resultado del trabajo.

Las pruebas de penetración responden más despacio y más caras, y su valor está precisamente en la cadena, porque el evaluador no busca «si hay aquí una vulnerabilidad», sino «qué puedo hacer con ella» — si desde un formulario público se puede llegar a derechos de administrador, si desde la cuenta de un cliente se pueden ver los datos de otro, si desde el entorno de ensayo se puede alcanzar la base de datos de producción. La respuesta a esa pregunta es la que un director entiende sin traducción.

Una auditoría de cumplimiento no hace ni lo uno ni lo otro, porque comprueba si el sistema se ajusta a una norma, y su resultado es un dictamen sobre la conformidad, no una lista de debilidades técnicas; exactamente por eso una empresa puede superar una auditoría de cumplimiento y ser atacada esa misma semana, y no hay contradicción, porque dos documentos responden a dos preguntas distintas.

Ninguno de estos trabajos sustituye a los demás y ninguno es «mejor» que los otros, así que la única pregunta con sentido es cuál de ellos responde ahora a lo que usted necesita saber de verdad.

La confusión de nombres no es un problema solo de un idioma, y se ve al comparar mercados: en Finlandia, Suecia y Noruega el mercado vende dos trabajos —el escaneo y las pruebas de penetración— y la variante intermedia no tiene nombre; se considera resultado del escaneo, no un servicio aparte. En Alemania es al revés, porque allí una sola palabra suele designar los tres trabajos, incluido el propio pentesting, y por eso, al comparar presupuestos, el nombre es la brújula más débil posible, y la única pregunta segura sigue siendo si las vulnerabilidades encontradas se van a explotar.

Si la ley se lo exige precisamente a usted

Aquí conviene ser precisos, porque esta es la parte en la que los presupuestos exageran con más frecuencia: en España ninguna norma nombra unas pruebas de penetración como obligación de toda empresa que tiene un sitio web.

El Real Decreto-ley 12/2018, de seguridad de las redes y sistemas de información, que entró en vigor el 9 de septiembre de 2018 y transpone la Directiva (UE) 2016/1148, fija obligaciones para los operadores de servicios esenciales y los proveedores de servicios digitales: gestionar los riesgos, designar un responsable de la seguridad de la información y notificar incidentes. Las pruebas de penetración no se mencionan por su nombre en ningún artículo del propio real decreto-ley.

Lo que nombra una comprobación periódica es el Real Decreto 311/2022, por el que se regula el Esquema Nacional de Seguridad, en vigor desde el 5 de mayo de 2022. Su artículo 31 exige una auditoría de la seguridad al menos cada dos años y, con carácter extraordinario, cuando haya modificaciones sustanciales, pero solo si usted está en el ámbito de aplicación y el sistema concreto es de categoría MEDIA o ALTA. Esa auditoría es un dictamen de conformidad, no unas pruebas de penetración. El Real Decreto 43/2021, que desarrolla el Real Decreto-ley 12/2018 y no el ENS, prevé que la autoridad competente pueda inspeccionar y exigir una auditoría también en otros casos.

Son dos condiciones juntas, no una: la empresa que no está en el ámbito de aplicación no obtiene de este punto ninguna obligación, y el sujeto cuyo sistema no es de categoría MEDIA o ALTA tampoco, así que el primer paso no es pedir un presupuesto, sino una autoevaluación de si usted es sujeto en absoluto.

Cómo saber si está usted en el ámbito de aplicación

El Real Decreto-ley 12/2018 no enumera empresas por nombre, sino que describe sectores y tamaño, y la identificación de operadores de servicios esenciales se hace por los procedimientos de la Ley 8/2011; el ENS, por su parte, obliga a la propia entidad a categorizar sus sistemas. En la práctica son dos preguntas: si su actividad entra en alguno de los sectores estratégicos nombrados, y si el tamaño o la categoría del sistema alcanza el umbral previsto. A las dos hay que responder uno mismo, y la respuesta hay que documentarla — por eso el primer gasto en este terreno suele ser un asesoramiento jurídico, no un servicio técnico.

Si la respuesta es «no», los puntos siguientes sobre categorías de sistemas no le aplican en absoluto, y si la respuesta es «sí», viene la segunda pregunta sobre a qué categoría pertenece el sistema concreto. La exigencia de una auditoría formal se ata a la categoría MEDIA o ALTA, no a la condición de sujeto como tal, y una empresa puede ser sujeto sin que esa exigencia recaiga sobre ninguno de sus sistemas.

Hay también un tercer camino, que no exige una categoría MEDIA o ALTA: la autoridad competente del Real Decreto-ley 12/2018 puede inspeccionar a un operador de servicios esenciales y exigirle una auditoría por una entidad externa en un caso concreto. No es una obligación planificable, pero es un motivo para saber quién de su lado respondería a un requerimiento así.

Los demás umbrales nombran comprobaciones, no un pentesting

El artículo 32 del Reglamento general de protección de datos exige verificar, evaluar y valorar con regularidad la eficacia de las medidas de seguridad, y el alcance de la exigencia va unido al riesgo. No es lo mismo que la obligación de encargar unas pruebas de penetración una vez al año, y un presupuesto que presenta el artículo 32 como tal parafrasea el reglamento con más holgura de la que está escrito. La obligación de demostrar que las comprobaciones existen es real; la de elegir precisamente este tipo no se deriva del artículo 32.

El estándar de tarjetas de pago PCI DSS, en el requisito 11.4, nombra las pruebas de penetración de forma expresa, una vez cada doce meses y después de cambios sustanciales, pero es una obligación contractual y atañe a cómo usted acepta tarjetas. Una tienda online que desvía los pagos por completo a un proveedor de servicios de pago y no trata ella misma datos de tarjeta, y las demás en cuyo entorno sí llegan datos de tarjeta, responden a este requisito de forma distinta. Es una pregunta a la que responde su entidad adquirente, no un artículo.

En el sector financiero el Reglamento (UE) 2022/2554 exige comprobaciones periódicas, y las pruebas de penetración basadas en amenazas (TLPT) las prevé solo para aquellas entidades que el supervisor haya señalado de forma específica. La norma ISO/IEC 27001 exige gestión de vulnerabilidades y comprobaciones de seguridad, sin nombrar las pruebas de penetración; la afirmación de que sin ellas no se entrega la certificación es frecuente y en la norma no está.

Si ninguno de estos umbrales le aplica, entonces no tiene usted una obligación normativa de encargar unas pruebas de penetración, y eso no significa que no haya nada que hacer, sino que lo que hay que hacer es otra cosa.

Si no se ha cruzado ningún umbral

Para una empresa que no es sujeto, no trata datos de tarjeta y no opera en el sector financiero, el trabajo con más sentido suele ser el que ocurre con regularidad, no una vez cada dos años. Son las actualizaciones, que tienen un responsable y un plazo; las copias de seguridad, que alguien ha restaurado alguna vez y se ha convencido de que de verdad se restauran; la autenticación multifactor (MFA) para las cuentas de administrador, que el Esquema Nacional de Seguridad nombra por separado para los sujetos y que para los demás es igual de útil; y un escaneo regular cuyos resultados alguien lee de verdad.

Esto no es una variante menor de la respuesta, sino otro tipo de trabajo. La mayor parte de las intrusiones con las que trabajamos no empiezan con un ataque sofisticado, sino con un componente sin actualizar o con una contraseña que también valía en otro sitio, y unas pruebas de penetración que ocurren una vez cada dos años no protegen de eso. Si su sitio web ya ha sufrido un incidente, la secuencia es otra y la describe un artículo aparte sobre cómo recuperar una web hackeada.

Las pruebas de penetración se justifican cuando hay algo que se puede perder, y cuando el volumen de la pérdida es mayor que el precio del pentesting: un sistema en el que hay datos de otras personas, una integración que toca dinero, o un cliente que exige un dictamen. Hasta ese momento es el trabajo correcto en el orden incorrecto.

Qué ocurre durante el pentesting

El trabajo empieza por fijar el alcance y termina con un informe, y entre ambos hay tres fases que conviene entender antes de comparar presupuestos, porque precisamente ellas explican por qué un encargo cuesta lo que cuesta, y por qué otro sobre el mismo sistema cuesta diez veces menos.

La primera fase es el reconocimiento, en la que el evaluador reúne todo lo que se puede saber del sistema desde fuera —qué direcciones son públicas, qué tecnologías y versiones se ven, dónde hay formularios de acceso, qué archivos están disponibles sin autorización. En esta fase todavía no se explota nada, pero precisamente aquí suelen estar los hallazgos que nadie esperaba: un entorno de ensayo olvidado, un listado abierto de directorios, una copia de seguridad que duerme bajo una dirección previsible.

La segunda fase es la comprobación misma, en la que se lanzan las herramientas automáticas para no dejar pasar lo conocido, pero las decisiones las toma una persona, que comprueba si el hallazgo es real, intenta explotarlo y mira qué gana con ello. Aquí nace la cadena —acceso a una cuenta, de ahí a una función que no debería ser alcanzable, de ahí a los datos. Por separado ninguno de los pasos es dramático; juntos son una historia.

La tercera fase es demostrar y dejar constancia, porque de cada hallazgo tiene que quedar una evidencia que se pueda repetir: qué petición se envió, cuál fue la respuesta, qué cambió. Sin eso el informe es una opinión, y el desarrollador que lo recibe se pasa un día intentando entender qué vio exactamente quien probó.

Por eso también los plazos son los que son: el pentesting de un sitio pequeño es unos días, pero un sistema con varios roles, integraciones y pagos es semanas, y un presupuesto que promete unas pruebas de penetración completas en un solo día no describe un pentesting, sino un escaneo.

Por qué los presupuestos se diferencian por un factor de diez

Cuando dos presupuestos sobre el mismo sitio web se diferencian por diez, la diferencia casi nunca está en el margen, y casi siempre está en el alcance y en el método: uno ofrece un escaneo automático con una herramienta que se lanza en una hora y cuyo informe genera la misma herramienta, y el otro ofrece una semana de trabajo de una persona, en la que las herramientas son solo el comienzo, y precisamente esa diferencia es la que el nombre «comprobación de seguridad» oculta en los dos casos.

El segundo factor que forma el precio es la complejidad del sistema, y se puede valorar antes de que empiece la conversación: un sitio web público sin cuentas de usuario es un trabajo, pero un sistema con varios roles, pagos, una integración externa y datos que pertenecen a clientes es otro del todo, porque cada rol es una frontera distinta que hay que comprobar y cada integración es un lugar en el que dos sistemas se fían el uno del otro más de lo que deberían.

El tercero es lo que usted recibe después del pentesting y cuánto tiempo permanece quien la ejecuta: un informe sin prioridades, sin evidencias y sin una comprobación de nuevo cuesta menos porque es menos trabajo, y para la empresa que después tiene que corregir los hallazgos, precisamente estas tres cosas deciden si el documento se convierte en una lista de tareas o en una carpeta que ya nadie abre.

Por eso comparar presupuestos por el precio solo es posible cuando el alcance está escrito igual, y el modo más simple de lograrlo es escribir el alcance uno mismo y pedir a todos que oferten sobre ese, no dejar que cada ejecutor defina el suyo.

Cuándo envejece el pentesting

El resultado de unas pruebas de penetración describe un sistema concreto en una fecha concreta, lo cual es evidente, y sin embargo precisamente aquí nace la mayor parte del malentendido entre quien ejecuta y quien encarga, porque un informe que tiene un año describe un código que desde entonces ha cambiado decenas de veces.

Los plazos normativos lo reconocen ellos mismos: en el Esquema Nacional de Seguridad, junto al intervalo de dos años, está la exigencia de auditar cuando hay modificaciones sustanciales, y en el estándar de tarjetas de pago, junto al intervalo anual, está «después de cambios sustanciales», de modo que en ambos casos el calendario es solo un mínimo, y el motivo de verdad para probar es un cambio.

En la práctica eso significa que un motivo nuevo para probar es un cambio que cambia la superficie de ataque: una función pública nueva, una integración nueva con un sistema externo, un cambio de autenticación, el paso a otro alojamiento, un rol de usuario nuevo con derechos más amplios. Un cambio de color o una corrección de texto no se convierten en un motivo así, por visible que sea.

El otro motivo es que ha cambiado el entorno, no su código: una vulnerabilidad en un marco que usted usa se revela después del pentesting, y el trabajo que no la mencionó no se equivocó, porque entonces todavía no existía. Por eso el escaneo regular y el proceso de actualizaciones son lo que ocurre entre un pentesting y el siguiente, y el pentesting no los sustituye.

Sin autorización del titular, las mismas acciones son ilícitas

Una prueba de penetración no se diferencia técnicamente de un ataque, y lo único que las distingue es un documento: la autorización del titular, en la que se nombran el alcance, el tiempo y los límites, y que conviene dejar por escrito incluso cuando la ley no exige esa forma. Sin ella, las mismas acciones son las mismas acciones, y eso tiene consecuencias jurídicas: en España, el acceso no autorizado a un sistema de información, vulnerando las medidas de seguridad, es delito del artículo 197 bis del Código Penal.

En la práctica eso significa que la autorización la da quien es dueño del sistema, no quien lo mantiene. Si su sitio web funciona sobre un servicio de alojamiento, también el proveedor tiene que saber que el pentesting va a ocurrir, porque si no sus sistemas de protección lo detendrán o bloquearán su cuenta. Si en el sistema hay un componente de un tercero que usted no controla, ese componente no entra en el alcance.

Los límites del alcance hay que escribirlos antes, no después, y en esa lista entra cuáles direcciones están en el alcance y cuáles no, si probamos el entorno de producción o una copia, qué ocurre si el pentesting interrumpe el servicio, y quién de su lado está localizable de noche; esta conversación ocupa una hora y resuelve la mayor parte de las disputas que, si no, nacen en mitad del trabajo.

Lo que el pentesting no es: equipo rojo, bug bounty y comprobación de cumplimiento

Junto a las pruebas de penetración existen varios trabajos que suelen llamarse igual, y las diferencias entre ellos no son académicas, sino prácticas —deciden qué encarga usted y qué recibe.

El ejercicio de equipo rojo no comprueba el sistema, sino la defensa: si su gente y sus procesos advierten el ataque y qué hacen. El alcance es más amplio, la duración más larga, y parte del valor está precisamente en que el lado que defiende no sabe que hay un ejercicio. Para una empresa que no tiene nada que advertir, porque nadie lee los registros, este trabajo es prematuro.

Bug bounty es un modelo, no un pentesting: usted publica unas reglas y paga por los hallazgos a quienes los envían. Puede encontrar lo que un solo evaluador no vio, pero no da ni garantía de alcance, ni plazo, ni un informe que se pueda adjuntar a un expediente de contratación.

Las pruebas de penetración basadas en amenazas (TLPT) son un trabajo aparte, regulado, del sector financiero, y están definidas en un reglamento de la Unión Europea. Si su empresa no es una entidad financiera señalada por el supervisor, este término no tiene sitio en su presupuesto.

Hay otro límite que suele borrarse, el de la «caja negra», la «caja blanca» y la «caja gris» —cuánto sabe ya el evaluador del sistema al empezar. Es un acuerdo del sector, no una exigencia normativa, y tiene un efecto directo sobre el precio y sobre lo que el pentesting encontrará. Un evaluador sin acceso imita a un desconocido; un evaluador con una cuenta y documentación llega más lejos en el mismo tiempo. Ninguna de las variantes es la más correcta; la pregunta es de qué tiene usted miedo.

Qué recibe usted y cómo leerlo

El resultado del pentesting es un informe, y su valor está en las prioridades, no en el número de hallazgos, porque un informe con cien filas en las que no se dice por cuál empezar es exactamente tan inutilizable como la impresión de un escáner. Un buen informe dice, de cada hallazgo, qué puede hacer con él un atacante, con qué facilidad, y qué hay que cambiar en concreto.

Lo segundo que hay que pedir es una comprobación después de las correcciones, porque un hallazgo que está corregido y un hallazgo del que alguien cree que está corregido se diferencian el uno del otro, y el único modo de aclararlo es comprobar otra vez. Nosotros lo hacemos en un plazo de treinta días después de las correcciones, y este plazo conviene pedirlo a cualquier ejecutor.

Lo tercero es lo que hará con el informe su desarrollador. Un hallazgo descrito con un número CVE y sin contexto significa para el desarrollador una búsqueda; un hallazgo al que se ha unido la petición concreta y el lugar en el código significa una corrección. Si el desarrollo lo hace una empresa y el pentesting otra, esta diferencia es la que decide si las correcciones se harán en una semana o en un trimestre.

Lo cuarto es lo que no puede estar en el informe: la afirmación de que el sistema ahora es seguro. El pentesting muestra qué se consiguió hacer, en el alcance concreto, en la fecha concreta. No demuestra que no haya nada más, y el ejecutor que lo promete le vende a usted consuelo.

Hay todavía un motivo para empezar esta conversación antes de lo que parece necesario: un pentesting que ocurre una semana antes de poner el sistema en servicio encuentra lo mismo que habría encontrado tres meses antes, pero para corregir los hallazgos ya no hay ni tiempo ni presupuesto, y en la práctica termina en una lista que se acepta como riesgo, no en correcciones, por eso la lógica de probar antes de la puesta en servicio está escrita como está, y la misma lógica vale también para quienes esta exigencia no les vincula.

Y lo último que conviene decir con claridad: unas pruebas de penetración no son un certificado de que el sistema es seguro, sino un certificado de que en una fecha concreta, en un alcance concreto, una habilidad conocida no encontró un camino más allá de algo concreto, y por eso la parte más valiosa del informe suele no ser la lista de hallazgos, sino la descripción de lo que se intentó y no salió, porque precisamente esa parte le dice al siguiente evaluador, dentro de tres años, dónde no merece la pena empezar de cero.

Qué preparar antes de la conversación

Para que un presupuesto sea comparable, quien lo ejecuta tiene que conocer el alcance, así que prepare una lista de direcciones y sistemas que entran en él, indique si probamos el entorno de producción o una copia, diga qué hay en el sistema a lo que no se puede tocar, y nombre a la persona que puede autorizar que se detenga el pentesting.

Entorno de producción o copia

Esta es la pregunta que decide el precio y el riesgo, porque un pentesting en el entorno de producción muestra lo que de verdad está al alcance, y precisamente por eso puede romper algo: saturar, llenar la base de datos con registros de ensayo, enviar a los clientes correos reales o quedar atrapado en un sistema de protección que bloquea al evaluador y después bloquea también a parte de sus usuarios.

Un pentesting sobre una copia es más seguro y al mismo tiempo más incompleto, porque la copia rara vez es idéntica: suelen faltar las integraciones reales, el volumen real de datos y la configuración real, y precisamente en la configuración suele estar el problema. Si elige una copia, anote en qué se diferencia del entorno de producción, porque esta lista es también la lista de lo que el pentesting no comprobó.

El camino de en medio, el que usamos con más frecuencia: operaciones de lectura en el entorno de producción, las de escritura y las potencialmente destructivas en una copia, con una ventana acordada de antemano y una persona que pueda detener. No es un compromiso por el precio, sino un modo de obtener las respuestas de las dos variantes sin interrumpir el trabajo.

Sirve también la lista contraria, es decir, lo que no está en el alcance, porque los límites que se dan por supuestos en silencio son aquellos por los que después se discute. Los servicios de terceros que usted no mantiene no entran en él, y probarlos sin la autorización de esas partes es el mismo problema del que trata la sección anterior. Si su sitio web usa una ventana de pago externa, una ventana de conversación externa o una analítica externa, son propiedad de otros, y un presupuesto que promete «comprobarlos también» promete lo que no se puede.

Por último diga qué pasará con los hallazgos después: quién los corregirá, en qué plazo, y si quien ejecutó volverá a comprobar después de las correcciones. Un pentesting sin este acuerdo suele terminar en un documento que nadie abre, y esa es la versión más cara posible: se ha pagado por un conocimiento que no se usa.

Diga también a qué respuesta busca, porque «tenemos que cumplir un requisito» y «queremos saber si alguien puede llegar a los datos de los clientes» son dos trabajos distintos con dos precios distintos, y el ejecutor que no pregunta cuál de ellos es el suyo ofrecerá el que a él le resulte más cómodo.

Si no está seguro de qué lado del umbral se encuentra, conviene empezar por ahí. La auditoría de seguridad web suele responder a la pregunta sobre los puntos débiles conocidos más barata y más rápido que el trabajo manual de un experto, y su resultado dice también si unas pruebas de penetración son el paso siguiente. Una conversación sobre el alcance conviene empezarla con la descripción del proceso, no con una lista de tecnologías, porque el alcance lo fija lo que usted pierde si el sistema falla.