Un test de intrusión no es pasar un escáner y entregar el PDF que sale. Es intentar entrar de verdad, con alcance pactado y bajo control, y demostrar hasta dónde se llega. La diferencia se ve en el informe: nosotros no le decimos que podría haber un problema, le enseñamos cómo lo hemos explotado.
Cuándo necesita un test de intrusión
Antes de publicar: una aplicación nueva, una integración con un tercero o una migración a cloud. Corregir antes de exponer cuesta una fracción de lo que cuesta después.
Después de un cambio de arquitectura: cuando cambia el perímetro, los controles que lo protegían dejan de cubrir lo mismo.
Porque lo exige un cliente o una norma: ISO 27001, ENS, NIS2, DORA y PCI DSS piden pruebas técnicas periódicas, y cada vez más contratos las exigen antes de firmar.
Porque ha habido un susto: un intento de intrusión, un correo que no debería haber llegado, un proveedor comprometido. Conviene saber qué más hay abierto.
Porque no se ha hecho nunca: si nadie ha intentado entrar con permiso, el primero que lo intente de verdad será alguien que no lo tiene.
Una vez al año, como mantenimiento: la superficie expuesta cambia sola — servicios que alguien levanta, certificados que caducan, subdominios olvidados — aunque usted no toque nada.
Qué hacemos y qué no
Sí
Explotamos
Encadenamos vulnerabilidades hasta alcanzar un impacto real: acceso a datos, control de un sistema, escalada de privilegios. Con prueba de concepto reproducible.
Sí
Priorizamos por impacto
Cada hallazgo lleva su criticidad razonada en su contexto, no la puntuación genérica de una base de datos.
No
Entregar ruido
Un listado de 400 hallazgos de los que 380 son informativos no es un servicio, es un traslado del problema.
Modalidades
Perimetral externo: todo lo que expone a Internet, incluido lo que no sabía que tenía expuesto.
Interno: qué consigue un atacante que ya está dentro, sea por un portátil comprometido o por un empleado descontento. Directorio Activo, segmentación, movimiento lateral y escalada.
Aplicaciones web y API: lógica de negocio, autenticación, autorización y todo lo que no encuentra un escáner automatizado.
Aplicaciones móviles: análisis estático y dinámico, almacenamiento local, comunicaciones y controles del lado del cliente.
Cloud: configuración de identidades y permisos, exposición de servicios y rutas de escalada dentro del propio proveedor.
Caja negra, gris o blanca: elegimos con usted según lo que quiera comprobar. La caja blanca encuentra más; la negra se parece más a un ataque real.
Metodología y normas que aplicamos
Reglas de enfrentamiento firmadas: alcance, ventanas horarias, criterios de parada y contactos de emergencia. Por escrito, antes de la primera petición.
Marcos de referencia: OWASP Testing Guide y OWASP API Security en aplicaciones, OWASP MASVS en móvil, PTES y NIST SP 800-115 en infraestructura, y OSSTMM donde aplica.
Clasificación de hallazgos: CVSS v4.0, ajustado al contexto real de su entorno y no a la puntuación teórica de la base de datos.
Explotación verificada: lo que no se demuestra se marca como no demostrado. No inflamos el informe con hallazgos teóricos.
Trazabilidad: cada prueba queda registrada con hora y origen, para que su equipo pueda distinguir nuestra actividad de la de un atacante real en sus registros.
Encaje normativo: el informe se entrega con el formato y la trazabilidad que piden ISO 27001, ENS, NIS2, DORA y PCI DSS.
Cómo trabajamos
1
Alcance y reglas de enfrentamiento
Qué se toca y qué no, ventanas horarias, contactos de emergencia y criterios de parada. Por escrito y firmado antes de tocar nada.
2
Reconocimiento
Superficie real de exposición, tecnologías, versiones y puntos de entrada. Aquí suelen aparecer activos que la organización había olvidado.
3
Explotación
Verificamos cada vulnerabilidad explotándola. Lo que no se puede demostrar se marca como tal, sin inflar el informe.
4
Post-explotación
Hasta dónde se llega desde ahí: escalada, movimiento lateral, acceso a datos. Es lo que convierte un hallazgo técnico en un riesgo de negocio.
5
Informe y presentación
Dos documentos y una reunión: el ejecutivo para dirección y el técnico para quien tiene que corregir.
6
Retest
Volvemos a probar lo corregido. Incluido, porque un informe sin verificación de cierre no sirve de mucho.
Qué recibe
Informe ejecutivo: qué riesgo real corre el negocio, en lenguaje de dirección y sin jerga.
Informe técnico: cada vulnerabilidad con evidencia, pasos de reproducción, impacto y corrección concreta.
Priorización por criticidad y por facilidad de explotación en su entorno.
Reunión de presentación con su equipo técnico para resolver dudas de remediación.
Retest de los hallazgos corregidos y certificado del estado final.
Quién lo ejecuta. El mismo equipo que audita, no un perfil comercial. En gobierno, riesgo y cumplimiento: CISSP, CISM, ISO 27001 Lead Auditor, ENS y Análisis de Riesgos (CCN), DPD/DPO certificado, CCSP y CDPP (ISMS Forum) y PMP (PMI). En la parte técnica: OSCP, CRTO II y eWPTX, con presencia en el Top 1 % de la plataforma Atenea del CCN-CERT.
Plazos, alcance y presupuesto
Cómo se presupuesta: por alcance acotado, nunca por hora abierta. El importe depende del número de activos, de la complejidad de las aplicaciones y de la profundidad acordada, y se cierra antes de empezar.
Qué incluye siempre: ejecución, informe ejecutivo, informe técnico, reunión de presentación y retest. Si alguna de esas piezas se factura aparte, no es un test de intrusión completo.
Plazos: una vez acotado el alcance le damos fechas cerradas de inicio, de entrega del informe y de retest.
Cómo acotarlo bien: en media hora de llamada se identifica qué hay que probar y qué no aporta nada. Esa es la diferencia entre un presupuesto razonable y uno inflado.
Confidencialidad: acuerdo firmado antes de recibir ninguna información suya, y destrucción de la evidencia al cierre según lo acordado.
Dónde trabajamos
Cobertura: Madrid y toda España. El pentest externo y el de aplicaciones se ejecutan en remoto; el interno requiere presencia en su sede o un acceso controlado que preparamos con su equipo.
Internacional: procedimientos, informes y reuniones en español e inglés para grupos con filiales fuera de España.
Preguntas que nos hacen
¿Nos van a tirar producción?
No, y por eso las reglas de enfrentamiento se pactan antes. Hay pruebas que solo se ejecutan en preproducción o en ventana acordada, y hay técnicas que simplemente no usamos contra sistemas en producción. Si algo puede afectar a la disponibilidad, se avisa y se decide juntos.
¿Cuánto dura?
Depende del alcance: número de activos, complejidad de las aplicaciones y profundidad. Tras acotar el alcance le damos duración y precio cerrados, no una horquilla abierta.
¿Test de intrusión o Red Team?
El pentest busca cobertura: cuántas vulnerabilidades hay en un perímetro definido. El Red Team busca un objetivo concreto y además mide si usted lo detecta. Si aún no ha hecho un pentest, empiece por el pentest: un Red Team contra una superficie llena de agujeros conocidos es dinero mal gastado.
¿Con qué frecuencia hay que repetirlo?
Anual como mínimo, y siempre después de un cambio relevante de arquitectura o de una publicación importante. Entre pentests, el análisis de vulnerabilidades periódico cubre la deriva.
¿Nos sirve para cumplir una norma?
Sí. ISO 27001, ENS, DORA, PCI DSS y NIS2 exigen pruebas técnicas periódicas. Emitimos el informe con el formato y la trazabilidad que el auditor espera.
¿Cuánto cuesta un test de intrusión?
Depende del alcance, y por eso no publicamos tarifas: un perímetro de diez activos y una aplicación con lógica de negocio compleja no cuestan lo mismo. Lo que sí hacemos es dar un importe cerrado antes de empezar, con el alcance detallado por escrito, de forma que no aparezcan ampliaciones a mitad de trabajo.
¿Qué diferencia hay entre un análisis de vulnerabilidades y un test de intrusión?
El análisis de vulnerabilidades identifica fallos conocidos con herramientas automáticas y sirve como control continuo. El test de intrusión los explota, los encadena y mide hasta dónde se llega de verdad. El primero le dice qué puertas pueden estar abiertas; el segundo entra y le enseña qué hay dentro.
¿Podéis probar sin que lo sepa nuestro equipo de seguridad?
Sí, pero entonces hablamos de un ejercicio de Red Team, no de un pentest. En un test de intrusión su equipo sabe que se está ejecutando, porque el objetivo es cobertura. Si lo que quiere medir es la detección y la respuesta, el servicio que busca es el de Red Team.
Acote el alcance en media hora
Le decimos qué tipo de prueba encaja con lo que quiere comprobar y qué alcance tiene sentido para su presupuesto. Sin formularios: teléfono, correo o agenda.
Teléfono: +34 686 250 244 (L-V, 9:00 a 18:00) · Email: info@jaymonsecurity.com
Respondemos en 2 horas dentro del horario laboral.
