Empresas de ciberseguridad en España: cómo elegir la tuya

Qué se está comprando de verdad bajo ese nombre

"Empresa de ciberseguridad" es una etiqueta que cubre tres negocios que se parecen poco entre sí, y confundirlos es el error que más caro sale.

• Seguridad ofensiva. Gente que ataca tus sistemas con tu permiso y por escrito para encontrar por dónde entraría alguien que no lo tiene. Es el pentesting (test de intrusión), el red team y la simulación de phishing.
• Seguridad defensiva y operación. Quien vigila, detecta y responde: SOC, monitorización, gestión de incidentes. Se compra por meses, no por proyecto.
• Cumplimiento. Quien te lleva a certificar un sistema de gestión o a cumplir una norma sectorial. Es consultoría documental con auditoría al final.

Las tres son necesarias y ninguna sustituye a las otras. Un SOC no te dice si tu aplicación tiene una vulnerabilidad de autorización, y un certificado no te dice si un hacker entraría hoy. Antes de pedir presupuesto conviene tener claro cuál de las tres se necesita, porque el mismo folleto las vende todas y el precio no las distingue.

Asperis hace la primera: seguridad ofensiva, con cumplimiento como consecuencia y no como producto separado. Si lo que buscas es un proveedor local, la página de Barcelona explica cómo trabajamos desde allí.

1. El alcance, y por qué se escribe antes de firmar

El alcance es lo primero porque decide todo lo demás: el precio, la duración, qué se encuentra y qué no. Un presupuesto cerrado sobre un alcance abierto no es una ventaja comercial, es una discusión aplazada.

Lo que tiene que estar escrito, con este nivel de detalle:

• Qué entra, enumerado. Dominios, rangos de IP, aplicaciones, APIs, cuentas cloud, redes wifi, aplicaciones móviles. Y qué queda fuera, dicho con la misma claridad.
• Desde dónde se prueba. Sin credenciales, con usuario normal, con administrador, desde dentro de la red o desde internet. La misma aplicación da resultados distintos en cada caso.
• Entorno. Producción o preproducción, y si es preproducción, en qué se diferencia de producción. Una copia que no tiene los mismos datos ni la misma configuración no prueba lo mismo.
• Ventana y avisos. Cuándo se puede lanzar tráfico, a quién se avisa antes y a quién no, y qué se hace si algo se cae.
• Qué está prohibido. Denegación de servicio, ingeniería social sobre personas concretas, exfiltración real de datos de clientes.

Todo esto junto tiene un nombre en el sector, rules of engagement, y es el documento que convierte un ataque en un servicio legal. Si un proveedor no lo trae de serie, no es un detalle de papeleo: es que va a improvisar.

Antes de discutir el alcance conviene saber qué tienes expuesto, que es más de lo que suele estar en el inventario. Eso es la superficie de ataque, y medirla es un trabajo en sí mismo.

2. La metodología, y qué cambia que la nombren

Pregunta qué metodología siguen y pide que la nombren. No es una formalidad: una metodología pública es una lista de cosas que hay que probar, así que nombrarla es comprometerse a un mínimo verificable. Sin ella, la cobertura depende de la memoria y del humor de quien te toque.

Para aplicación web, la referencia habitual es la guía de pruebas de OWASP, y el OWASP Top 10 es su resumen más conocido. Ojo con esto último, porque es una confusión frecuente y cara: el Top 10 es una lista de categorías de riesgo, no un plan de pruebas. Un proveedor que ofrece "cubrimos el OWASP Top 10" está ofreciendo menos de lo que parece.

Y hay una pregunta que separa el trabajo manual del automático mejor que ninguna otra: qué parte del hallazgo la encuentra una herramienta y qué parte la encuentra una persona. Un escáner encuentra versiones viejas y configuraciones por defecto. No encuentra que el identificador de la factura del cliente A funcione en la sesión del cliente B, porque eso requiere entender qué hace tu negocio. Si la respuesta es vaga, la respuesta es que no hay trabajo manual.

Cuando lo que se quiere probar no es una aplicación sino la capacidad de detectar y responder, el formato es otro: un red team, que persigue un objetivo concreto sin avisar al equipo defensor, o un ejercicio de assumed breach, que arranca dando por hecho que el atacante ya está dentro y mide hasta dónde llega.

3. Quién hace el trabajo, no quién firma la propuesta

En este sector el resultado depende de la persona asignada más que de casi nada. Por eso la pregunta útil no es cuánta gente tiene la empresa, sino quién va a estar en tu proyecto.

• Nombres y perfiles del equipo asignado, no del catálogo entero. Y si cambian, que se avise.
• Certificaciones, con lo que significan. Las que se ganan haciendo un examen práctico de varias horas contra máquinas reales dicen algo distinto de las que se aprueban con un test. Pregunta cuál es cuál y por qué la traen.
• Trabajo propio publicado. Vulnerabilidades reportadas, herramientas, charlas, avisos. Es la forma más barata de comprobar que hay oficio y no solo comercial.
• Subcontratación. Si parte del trabajo se subcontrata, quién y con qué acuerdo de confidencialidad.
• Seguro de responsabilidad civil y qué cubre. A alguien le vas a dar permiso para atacar tus sistemas.
• Referencias contactables de proyectos parecidos al tuyo. Los casos publicados sirven para ver el tipo de trabajo; una llamada sirve para lo demás.

Nosotros contamos quiénes somos en nuestra página de equipo, y ese es exactamente el nivel de detalle que conviene exigirle a cualquiera, incluidos nosotros.

4. El entregable, que es lo único que queda cuando terminan

Pide un informe de ejemplo antes de firmar, anonimizado. Es la petición que más información da y la que menos proveedores esperan. Lo que hay que mirar en él:

• Que cada hallazgo se pueda reproducir. Petición exacta, pasos, capturas o traza. Si tu equipo no puede repetirlo, no puede arreglarlo ni comprobar que lo arregló.
• Impacto en tu negocio, no solo severidad técnica. El CVSS es una escala útil y no es una prioridad: un fallo de severidad media en el sistema de pagos va antes que uno alto en la intranet de la cafetería. El informe tiene que decir qué se rompe si eso se explota, con tus datos delante.
• Cómo se arregla, en concreto. "Sanitizar la entrada" no es una recomendación, es una categoría. La recomendación dice qué cambiar y dónde.
• Resumen para dirección que se sostenga solo. Alguien que no es técnico va a decidir el presupuesto de remediación con esa página.
• Qué se probó y no salió nada. Un informe que solo lista fallos no permite distinguir lo que está bien de lo que no se miró.

Y una pregunta práctica que ahorra semanas: en qué formato entregan. Un PDF es un documento; los hallazgos en tu propio gestor de incidencias son trabajo que ya está empezado. En nuestro caso los hallazgos viven en la plataforma desde que se encuentran, y no al final.

5. El retest, que es donde se ve si sirvió de algo

Un pentest sin retest es una foto. Alguien te dice qué está mal, tu equipo lo arregla, y nadie comprueba que lo arreglado esté de verdad arreglado. Es sorprendentemente frecuente que la corrección tape el camino que se probó y deje abierto el de al lado.

Lo que hay que dejar cerrado en el contrato:

• Si el retest está incluido o se factura aparte. Las dos respuestas son legítimas; la que no lo es es no contestarla hasta que llegue la factura.
• Cuánto tiempo tienes para pedirlo desde la entrega del informe.
• Qué cubre. Solo los hallazgos corregidos, o también lo que haya cambiado alrededor.
• Qué documento produce. Lo normal es una versión del informe con cada hallazgo marcado como corregido, mitigado o abierto, que es lo que luego se enseña a un cliente o a un auditor.

Y una recomendación que no cuesta dinero: acuerda antes quién arregla, en qué plazo por severidad, y quién decide si un riesgo se acepta en vez de corregirse. Los informes se atascan casi siempre ahí, y no en la parte técnica.

6. Lo que te va a pedir la norma: ENS, ISO 27001, NIS2 y DORA

Muchas veces la búsqueda de una empresa de ciberseguridad no nace de un susto sino de un requisito. Conviene saber cuál se te aplica antes de pedir presupuesto, porque cambia el entregable.

• ENS, el Esquema Nacional de Seguridad. Se aplica a la administración pública española y se traslada por contrato a sus proveedores. Clasifica los sistemas por categoría y exige auditoría periódica: si vendes al sector público, esto acaba llegándote aunque seas una empresa privada. Nosotros lo tratamos en el servicio de ENS.
• ISO 27001. Certifica un sistema de gestión de la seguridad de la información, no un producto ni una aplicación. Lo audita una entidad de certificación acreditada, que no puede ser la misma que te implanta el sistema. Un pentest no certifica nada por sí solo, pero es la evidencia con la que se sostienen varios de los controles. Va en el servicio de ISO 27001.
• NIS2. Directiva europea que sube el listón para entidades esenciales e importantes de sectores como energía, transporte, sanidad, agua o infraestructura digital. Dos cosas la diferencian de lo anterior: responsabiliza directamente a la dirección, y obliga a notificar incidentes significativos en plazos cortos. Y alcanza a la cadena de suministro, así que puede llegarte como cláusula de tu cliente.
• DORA. Reglamento europeo para el sector financiero y sus proveedores tecnológicos. Es el que más afecta a lo que estás comprando, porque para determinadas entidades exige pruebas de intrusión dirigidas por inteligencia de amenazas, el TLPT, que no es un pentest normal: lo dirige inteligencia sobre atacantes reales de tu sector y tiene requisitos propios de ejecución y de proveedor.

La pregunta que hay que hacerle al proveedor no es si "trabaja con" estas normas, sino qué evidencia concreta produce su trabajo que puedas poner delante de un auditor. Y si lo que necesitas es protección de datos personales, eso es otra conversación y va por RGPD.

7. Las señales de que te van a vender un escáner, y la lista para llevar

Ninguna de estas señales es concluyente por sí sola. Dos o tres juntas sí lo son.

• Precio cerrado sin haber preguntado el alcance. Si nadie ha preguntado cuántas aplicaciones hay ni qué hacen, el número sale de una plantilla.
• Plazo de dos días para "toda la infraestructura". Lo que cabe en dos días es una pasada de herramienta.
• El informe de ejemplo tiene aspecto de exportación. Cientos de hallazgos, todos con el mismo formato, ninguno con una petición reproducible, y capítulos que hablan de puertos y versiones pero no de tu negocio.
• No hay rules of engagement.
• No hay retest, o "ya se verá".
• No sabes quién va a hacerlo.
• Se venden certificaciones como si fueran resultados. Un logo en la propuesta no es un hallazgo.

La lista corta, para llevar a la reunión: alcance escrito y enumerado; metodología nombrada; qué es manual y qué automático; nombres del equipo asignado; informe de ejemplo anonimizado; impacto de negocio además de severidad; retest con condiciones cerradas; seguro; referencias contactables; y qué evidencia produce para la norma que se te aplica.

Si te sirve de contraste, así es como respondemos nosotros a estas diez: el catálogo está en servicios, el hacking ético es la puerta de entrada habitual, y en contacto se puede pedir el informe de ejemplo sin compromiso. Y si lo que buscas es empezar por lo básico y en orden, la guía de ciberseguridad para empresas va por delante de todo esto.