ISO 27001 proporciona un marco para gestionar la seguridad de la información mediante un Sistema de Gestión de Seguridad de la Información (SGSI) basado en riesgos y mejora continua.
Dentro de este enfoque, las evaluaciones técnicas pueden aportar información útil para comprobar determinados controles, identificar vulnerabilidades y mejorar el tratamiento de riesgos.
El hacking ético, el pentesting y el análisis de vulnerabilidades pueden formar parte de ese programa de seguridad cuando resulten adecuados para el alcance y los riesgos de la organización.
La cuestión no es realizar un pentest únicamente para conseguir una certificación, sino integrar las pruebas dentro de un proceso continuo de evaluación, corrección y mejora.
En esta página explicamos cómo relacionar ISO 27001 y hacking ético, qué tipos de pruebas pueden utilizarse, cómo documentar sus resultados y cómo aprovecharlos dentro del SGSI.
¿Qué relación existe entre ISO 27001 y hacking ético?
ISO 27001 establece un marco de gestión de la seguridad de la información.
El hacking ético permite realizar pruebas técnicas autorizadas sobre aplicaciones, sistemas, infraestructuras u otros activos para identificar debilidades.
Ambos conceptos son diferentes, pero pueden complementarse.
Una organización puede utilizar pruebas técnicas para obtener evidencias sobre el estado de determinados controles y utilizar los resultados dentro de su gestión de riesgos.
Por ejemplo, una empresa puede tener establecidos controles de autenticación y acceso dentro de su SGSI. Una evaluación técnica puede ayudar a comprobar si existen debilidades que permitan eludir determinados controles.
Por eso, el valor del hacking ético dentro de ISO 27001 está principalmente en aportar evidencias sobre el estado real de la seguridad.
ISO 27001 no es lo mismo que un pentest
Conviene separar ambos conceptos.
ISO 27001 establece un sistema de gestión para controlar los riesgos relacionados con la seguridad de la información.
El hacking ético engloba pruebas técnicas autorizadas destinadas a identificar vulnerabilidades o comprobar determinados escenarios de seguridad.
Un pentest puede formar parte del programa de seguridad de una organización certificada en ISO 27001, pero un pentest por sí solo no equivale a cumplir ISO 27001.
Del mismo modo, disponer de un SGSI no significa que todas las vulnerabilidades técnicas hayan desaparecido.
Ambas piezas cumplen funciones diferentes y pueden complementarse.
¿Qué aporta el hacking ético a un SGSI?
Integrar pruebas de seguridad dentro del SGSI puede aportar información que difícilmente se obtiene únicamente revisando documentación.
Entre sus posibles aportaciones se encuentran:
- identificar vulnerabilidades técnicas;
- detectar configuraciones que necesitan revisión;
- evaluar determinados controles de acceso;
- revisar aplicaciones y APIs;
- obtener evidencias técnicas;
- priorizar riesgos;
- comprobar determinadas medidas de protección;
- verificar correcciones mediante retest.
El resultado más importante no debería ser simplemente una lista de vulnerabilidades.
Lo útil es conectar cada hallazgo con el riesgo que representa para la organización, establecer una acción correctiva y conservar evidencias del proceso.
¿Qué tipos de pruebas pueden integrarse en ISO 27001?
No todas las organizaciones necesitan las mismas evaluaciones.
El programa debería diseñarse teniendo en cuenta el alcance del SGSI, los activos, los riesgos identificados y las características del negocio.
Análisis de vulnerabilidades
El análisis de vulnerabilidades utiliza herramientas especializadas y revisión de resultados para detectar determinadas debilidades conocidas en sistemas, redes, aplicaciones u otros activos.
Puede ayudar a identificar:
- software desactualizado;
- configuraciones inseguras;
- servicios expuestos;
- vulnerabilidades conocidas;
- determinados problemas de seguridad;
- componentes que necesitan revisión.
Es especialmente útil como mecanismo recurrente de detección.
Sin embargo, un escáner no sustituye necesariamente una evaluación manual, ya que determinados problemas requieren analizar el contexto, la lógica de negocio o las relaciones entre diferentes componentes.
Pentesting
El pentesting consiste en realizar pruebas de penetración autorizadas para evaluar la seguridad de un objetivo concreto.
Dependiendo del alcance, puede centrarse en:
- aplicaciones web;
- APIs;
- infraestructura externa;
- infraestructura interna;
- servicios cloud;
- determinados sistemas críticos.
La evaluación puede combinar herramientas y revisión manual para analizar problemas dentro del alcance acordado.
Cuando el objetivo es una aplicación web, puede utilizarse un pentesting web específicamente orientado a ese entorno.
Ingeniería social
El componente humano también forma parte de la seguridad de la información.
Las organizaciones pueden realizar ejercicios autorizados para evaluar determinados aspectos relacionados con la concienciación y la respuesta de los usuarios.
Estas pruebas deben definirse previamente, contar con la autorización necesaria y respetar las condiciones establecidas para el proyecto.
Red Team
Los ejercicios de Red Team pueden tener un alcance más amplio que un pentest convencional.
Pueden plantear escenarios controlados para evaluar conjuntamente tecnología, procesos, detección y respuesta.
No todas las empresas necesitan este tipo de ejercicio. Su utilidad depende del nivel de riesgo, criticidad y madurez de la organización.
¿Qué controles de ISO 27001 pueden relacionarse con pruebas técnicas?
Dentro de un SGSI pueden existir controles y procesos relacionados con diferentes áreas de seguridad tecnológica.
Entre ellas pueden encontrarse:
- gestión de vulnerabilidades técnicas;
- configuración segura;
- desarrollo seguro;
- monitorización;
- seguridad de servicios cloud;
- gestión de amenazas.
Esto no significa que cada uno de estos ámbitos requiera automáticamente un pentest.
La relación debe establecerse a partir del análisis de riesgos, la Declaración de Aplicabilidad y las necesidades concretas de la organización.
Por ejemplo, si una empresa tiene una aplicación web crítica dentro del alcance del SGSI, puede tener sentido complementar los controles relacionados con el desarrollo y la seguridad de la aplicación mediante análisis de vulnerabilidades y pruebas de penetración.
¿Cómo integrar el pentesting dentro del SGSI?
1. Definir el alcance
Antes de realizar cualquier prueba hay que determinar qué activos pueden evaluarse.
Pueden incluirse:
- dominios;
- aplicaciones;
- APIs;
- servidores;
- redes;
- servicios cloud;
- sistemas internos.
Un alcance bien definido permite relacionar posteriormente los resultados con el SGSI.
2. Relacionar las pruebas con los riesgos
El pentesting debería responder a una necesidad concreta.
Si el análisis de riesgos identifica una aplicación crítica, por ejemplo, puede tener sentido priorizar su evaluación.
Así, los recursos destinados a pruebas técnicas se concentran donde pueden aportar mayor valor.
3. Definir las reglas de la prueba
Antes de comenzar deben establecerse:
- sistemas incluidos;
- sistemas excluidos;
- fechas;
- horarios;
- técnicas permitidas;
- limitaciones;
- contactos;
- procedimiento ante incidencias;
- tratamiento de información sensible.
La autorización y las condiciones del trabajo deben quedar documentadas.
4. Ejecutar la evaluación
Los profesionales realizan las pruebas dentro del alcance definido y utilizando la metodología adecuada para el objetivo.
5. Clasificar los hallazgos
Cada vulnerabilidad debe analizarse según su gravedad y contexto.
Además de la valoración técnica, pueden considerarse:
- exposición;
- criticidad del activo;
- impacto para el negocio;
- posibilidad de explotación;
- datos afectados;
- controles existentes.
6. Vincular los resultados con el tratamiento de riesgos
Los hallazgos pueden incorporarse al proceso de gestión y tratamiento de riesgos del SGSI.
La organización puede determinar:
- qué debe corregirse;
- quién será responsable;
- qué prioridad tiene;
- qué plazo se establece;
- qué riesgo permanece después de aplicar la medida.
7. Realizar un retest cuando corresponda
Después de corregir vulnerabilidades relevantes puede realizarse una nueva comprobación para verificar las medidas aplicadas.
8. Conservar las evidencias
Los informes, resultados, registros y comprobaciones posteriores pueden formar parte de las evidencias del proceso.
La secuencia puede resumirse así:
detección → evaluación → tratamiento → comprobación → cierre
¿Cada cuánto hay que hacer un pentest para ISO 27001?
No existe una frecuencia universal de pentesting aplicable a todas las empresas simplemente por estar certificadas en ISO 27001.
La periodicidad debería establecerse según factores como:
- análisis de riesgos;
- cambios importantes;
- criticidad de los activos;
- exposición;
- nuevas aplicaciones;
- incidentes;
- requisitos contractuales;
- necesidades de la organización.
Puede ser razonable realizar nuevas pruebas después de cambios importantes en una aplicación, infraestructura o servicio crítico.
Por eso, resulta más adecuado establecer una política de pruebas basada en riesgos que aplicar una periodicidad rígida a todas las organizaciones.
¿Análisis de vulnerabilidades o pentesting?
No son exactamente lo mismo.
| Análisis de vulnerabilidades | Pentesting |
|---|---|
| Identifica principalmente vulnerabilidades conocidas | Evalúa la seguridad mediante pruebas controladas |
| Puede automatizarse en gran medida | Requiere mayor intervención manual |
| Puede cubrir numerosos activos | Suele centrarse en objetivos definidos |
| Es útil para revisiones recurrentes | Puede ofrecer una evaluación más profunda |
| Necesita interpretación de resultados | Permite contextualizar determinados hallazgos |
Dentro de un programa de seguridad maduro, ambos servicios pueden complementarse.
El análisis ayuda a mantener una visión recurrente de determinados problemas técnicos, mientras que el pentesting puede profundizar en activos o escenarios concretos.
¿Cómo debe ser un informe de hacking ético para ISO 27001?
Un informe útil no debería limitarse a enumerar vulnerabilidades.
Debe permitir comprender:
- qué se ha evaluado;
- cuál era el alcance;
- cuándo se realizaron las pruebas;
- qué metodología se utilizó;
- qué vulnerabilidades se encontraron;
- cuál es su gravedad;
- qué activos están afectados;
- cuál puede ser su impacto;
- qué recomendaciones existen;
- qué evidencias respaldan los hallazgos.
Cuando se realiza una corrección, también conviene conservar la evidencia del retest.
De esta forma, el informe se integra dentro del sistema de gestión y no se convierte en un documento aislado.
¿Qué ocurre con las vulnerabilidades encontradas?
Encontrar una vulnerabilidad no significa automáticamente que exista una no conformidad de ISO 27001.
Lo importante es comprobar cómo gestiona la organización el riesgo asociado.
Un proceso puede consistir en:
- detectar la vulnerabilidad;
- analizar su impacto;
- registrar el riesgo;
- decidir el tratamiento;
- asignar un responsable;
- aplicar la corrección;
- verificar el resultado;
- documentar el cierre.
Una organización puede tener vulnerabilidades y seguir gestionando adecuadamente sus riesgos.
Lo importante es demostrar que las identifica, las evalúa y toma decisiones sobre ellas.
ISO 27001 y hacking ético frente a ENS, NIS2 y RGPD
En España, algunas organizaciones pueden encontrarse simultáneamente con diferentes marcos y obligaciones de seguridad.
Entre ellos pueden aparecer:
- ISO 27001;
- ENS;
- NIS2, cuando resulte aplicable;
- RGPD, en materia de protección de datos personales.
No son equivalentes.
Sin embargo, determinados procesos pueden aportar información útil para más de un objetivo cuando el alcance y los requisitos lo permiten.
Por ejemplo, una evaluación técnica correctamente documentada puede aportar evidencias relacionadas con la gestión de riesgos o determinados controles, aunque eso no implique automáticamente el cumplimiento de todos los requisitos de cada marco.
Cuando una empresa también trabaja con requisitos del ENS, puede consultar nuestra página sobre Esquema Nacional de Seguridad para empresas.
¿ISO 27001 garantiza que una empresa sea segura?
No.
La certificación no significa que una organización esté libre de vulnerabilidades ni que no pueda sufrir incidentes.
La situación de seguridad puede cambiar cuando:
- aparecen nuevas vulnerabilidades;
- se incorporan aplicaciones;
- cambia la infraestructura;
- aparecen nuevos proveedores;
- evolucionan las amenazas.
Por eso, el SGSI debe mantenerse y mejorarse continuamente.
El hacking ético puede formar parte de ese proceso como mecanismo de evaluación técnica.
Buenas prácticas para integrar hacking ético e ISO 27001
Relacionar las pruebas con el riesgo
No todas las aplicaciones o sistemas necesitan el mismo nivel de evaluación.
Definir el alcance antes de contratar
Especifica qué activos se revisarán y qué elementos quedan fuera.
Combinar automatización y revisión profesional
Las herramientas pueden ayudar a detectar problemas, pero la interpretación de los resultados sigue siendo importante.
Documentar la remediación
No basta con encontrar una vulnerabilidad. Conviene registrar cómo se gestiona y cuándo se comprueba su corrección.
Conservar las evidencias
Mantén informes, registros y resultados de las comprobaciones realizadas.
Revisar el programa cuando cambie el entorno
Los cambios tecnológicos, organizativos o de riesgo pueden justificar nuevas evaluaciones.
¿Qué ventajas aporta este enfoque?
Integrar evaluaciones técnicas dentro del SGSI puede ayudar a:
- conocer mejor los riesgos técnicos;
- identificar vulnerabilidades;
- priorizar acciones;
- generar evidencias;
- mejorar determinados controles;
- verificar correcciones;
- apoyar la mejora continua.
En lugar de preguntarse únicamente si la empresa tiene suficiente seguridad, la organización puede analizar cuestiones más concretas:
¿Qué activos presentan mayor riesgo?
¿Qué vulnerabilidades requieren atención prioritaria?
¿Qué controles necesitan validación técnica?
¿Qué debemos corregir primero?
¿Cómo empezar un programa de hacking ético alineado con ISO 27001?
Una organización puede comenzar de forma progresiva:
- revisar el alcance del SGSI;
- identificar los activos críticos;
- revisar el análisis de riesgos;
- determinar qué controles necesitan validación;
- definir una política de pruebas;
- establecer prioridades;
- realizar las evaluaciones;
- registrar y tratar los hallazgos;
- realizar retests cuando corresponda;
- revisar periódicamente el programa.
El objetivo no es acumular informes de pentesting, sino utilizar las evaluaciones para reducir riesgos y mejorar la seguridad.
Preguntas frecuentes sobre ISO 27001 y hacking ético
¿ISO 27001 obliga a realizar un pentesting?
No existe una obligación universal de realizar exactamente el mismo pentesting para todas las organizaciones. La necesidad depende del alcance, los riesgos y los controles aplicables.
¿Un pentest garantiza el cumplimiento de ISO 27001?
No. Un pentest es una evaluación técnica y no sustituye un SGSI ni el resto de requisitos de ISO 27001.
¿Puede un análisis de vulnerabilidades formar parte del SGSI?
Sí. Puede utilizarse como mecanismo de identificación y seguimiento de vulnerabilidades cuando resulte adecuado.
¿Cada cuánto debe hacerse un pentest?
La frecuencia debe establecerse teniendo en cuenta el riesgo, los cambios tecnológicos, la criticidad de los activos y otros requisitos aplicables.
¿Qué debe contener el informe?
Debe indicar, según el alcance, qué se evaluó, cómo se evaluó, qué hallazgos se identificaron y qué recomendaciones pueden aplicarse.
¿Es necesario realizar un retest?
Puede ser útil para comprobar determinadas correcciones después de solucionar los hallazgos.
¿ISO 27001 garantiza que no habrá vulnerabilidades?
No. La seguridad requiere evaluación, tratamiento del riesgo y mejora continua.
¿ISO 27001 y ENS son lo mismo?
No. Son marcos diferentes y cada uno tiene su propio ámbito y requisitos.
Solicita una evaluación técnica para tu SGSI
Si tu empresa trabaja con ISO 27001 y necesita evaluar aplicaciones, sistemas o infraestructura, el primer paso es definir el alcance y determinar qué riesgos requieren una comprobación técnica.
Cuéntanos qué activos forman parte del SGSI, qué quieres comprobar y qué objetivo tienes.
A partir de esa información podemos ayudarte a valorar el tipo de evaluación que mejor encaje con tu entorno.