Auditoría de ciberseguridad y vulnerabilidades web
Auditoría de vulnerabilidades, SIEM ligero y endurecimiento de aplicaciones.
Pruebas de intrusión, revisión de permisos, endurecimiento de las APIs y plan de respuesta a incidentes. El informe prioriza por CVSS y por impacto real, e incluye el protocolo de notificación de brechas: el RGPD da 72 horas para comunicarlas a la autoridad.
Para quién es
- Empresas con datos personales sujetas al RGPD
- SaaS con clientes enterprise que exigen auditoría
- Startups con financiación y exposición pública
Por qué acaba haciendo falta
Casi ningún incidente empieza con un ataque sofisticado. Empieza con una librería que lleva dos años sin actualizar, una clave de API que quedó en un repositorio, un usuario de un empleado que se fue y sigue activo, o un panel de administración accesible desde internet porque un día hacía falta para trabajar desde casa.
Lo que convierte eso en un problema serio es que casi siempre se descubre tarde. Sin registros ni alertas, alguien puede llevar semanas dentro; y cuando se detecta, el reloj corre: el RGPD da setenta y dos horas para notificar una brecha de datos personales a la autoridad, y ese plazo empieza cuando te enteras, no cuando decides qué hacer.
Por eso una auditoría útil no acaba con una lista de vulnerabilidades. Acaba con un orden de corrección justificado por impacto real, con lo urgente ya endurecido, y con un procedimiento escrito de qué hace cada uno en las primeras horas. Una lista sin eso se archiva y no cambia nada.
Qué entrego
- Informe de auditoría — Vulnerabilidades priorizadas por CVSS con prueba de concepto.
- Plan de mitigación — Roadmap de correcciones con esfuerzo estimado.
- Hardening aplicado — Reglas, políticas IAM, WAF si aplica.
- Runbook de respuesta — Procedimiento ante incidentes documentado.
- Revisión de dependencias — Librerías con vulnerabilidad conocida y la actualización que las cierra.
- Segunda pasada — Se vuelve a probar lo corregido y se cierra por escrito.
Qué incluye
- Análisis de vulnerabilidades
- Revisión de configuración y accesos
- Informe priorizado por riesgo
- Revisión posterior de las correcciones
Lo que se decide antes de escribir una línea
- Qué se prueba y qué no — El alcance se acuerda por escrito antes de tocar nada: qué sistemas entran, en qué ventana horaria y qué pruebas quedan fuera. Una auditoría que tumba un servicio en hora punta no es una auditoría, es un incidente que has pagado tú.
- Producción o un entorno de pruebas — Las pruebas activas van sobre un entorno de pruebas siempre que exista y se parezca al real. Cuando no existe, se acota qué se puede hacer en producción y se hace en ventana acordada. La diferencia entre los dos entornos es, ella misma, un hallazgo del informe.
- Cómo se ordenan los hallazgos — Por CVSS y por exposición real, no solo por la puntuación. Un fallo crítico en un sistema interno sin salida a internet no va antes que uno medio en la web pública, y presentarlo al revés hace que se corrija lo que menos importa primero.
- Qué se corrige aquí y qué después — El endurecimiento que no rompe nada —permisos, políticas, cabeceras, dependencias— se aplica dentro del trabajo. Lo que implica cambiar la aplicación se entrega priorizado y con esfuerzo estimado, para que lo planifiques. Y se vuelve a probar lo corregido antes de cerrar por escrito.
Lo que no entra
- Ingeniería social ni pruebas de suplantación al personal, salvo que se contraten aparte.
- Corregir el código de la aplicación: se entrega priorizado, lo aplica tu equipo o se acuerda como desarrollo.
- Vigilancia continua ni servicio de guardia, que son un contrato distinto.
- Certificación: esto es una auditoría técnica, no la emisión de un certificado.
- Auditar sistemas de terceros sin su autorización escrita.
Lo que necesitas tener
- Autorización escrita del titular de los sistemas que se van a probar.
- Una ventana horaria acordada y a quién avisar si algo se cae.
- Accesos de prueba con los distintos roles, para revisar permisos de verdad.
- Saber qué datos personales trata cada sistema, para ordenar por impacto real.
Preguntas frecuentes
¿Es una auditoría de verdad o un escáner automático?
Hay escaneo automático, pero el informe se revisa a mano. Un escáner marca cientos de avisos y la mayoría no son explotables; lo que se entrega es lo que sí lo es.
¿Con qué criterio se priorizan los hallazgos?
Por CVSS y por impacto real, con un plan de mitigación por orden. Un fallo crítico en un sistema que no está expuesto no va antes que uno medio en la web pública.
¿Vais a tocar el sistema en producción?
No sin acordar antes y por escrito el alcance, la ventana horaria y qué pruebas quedan fuera. Una auditoría que tira un servicio no es una auditoría.
¿Cuánto dura?
La auditoría son dos semanas: reconocimiento, pruebas activas e informe con reunión de priorización. La segunda pasada sobre lo corregido va después y está incluida.
¿Qué pasa si encontráis algo grave?
Se avisa en el momento, no al final en el informe. Si hay indicio de que ya ha sido explotado, lo primero es el procedimiento de brecha y sus plazos, no seguir probando.
¿Sirve para lo que me pide un cliente enterprise?
Sirve como auditoría técnica con informe priorizado y segunda pasada, que es lo que suele pedirse. Si lo que te exigen es una certificación concreta, eso lo emite una entidad acreditada y se dice antes de empezar.