«Necesitamos un pentest para la certificación» es una frase frecuente en las organizaciones que implementan ISO/IEC 27001. A veces es cierto que conviene hacerlo; otras veces lo que hace falta es algo más básico y continuo: saber qué vulnerabilidades tienen los sistemas y corregirlas a tiempo. Confundir una cosa con la otra puede llevar a contratar una prueba costosa que se archiva sin que nadie corrija los hallazgos.
Este artículo explica qué pide la norma sobre las vulnerabilidades técnicas, en qué se diferencian el análisis, la prueba de penetración y el tratamiento, y qué evidencia conviene conservar.
Qué pide el control 8.8
El Anexo A de ISO/IEC 27001:2022 incluye el control 8.8, sobre la gestión de vulnerabilidades técnicas. En síntesis, tiene tres partes:
- Obtener información sobre las vulnerabilidades técnicas de los sistemas de información que se usan.
- Evaluar la exposición de la organización a esas vulnerabilidades.
- Tomar las medidas apropiadas.
El control no menciona herramientas, frecuencias ni técnicas concretas. Para ubicarlo entre los demás, lea nuestro artículo sobre los controles del Anexo A. Como los demás controles del Anexo A, se aplica según la evaluación de riesgos y su inclusión y justificación quedan en la declaración de aplicabilidad. Si quiere repasar ese documento, lea nuestro artículo sobre la declaración de aplicabilidad.
Tres actividades que no son lo mismo
- Análisis de vulnerabilidades. Busca, por lo general con herramientas automáticas, debilidades conocidas en equipos, aplicaciones y configuraciones: versiones sin actualizar, servicios expuestos o configuraciones inseguras. Produce una lista amplia, con falsos positivos que hay que depurar.
- Prueba de penetración. Un equipo competente intenta aprovechar las debilidades, con un alcance y unas reglas acordadas, para demostrar qué podría lograr un atacante: acceder a datos, escalar privilegios o moverse entre sistemas. Es más profunda y más acotada que el análisis.
- Tratamiento. Es decidir qué se corrige, en qué orden y en qué plazo, aplicarlo y comprobar que funcionó. Sin tratamiento, las otras dos actividades solo producen informes.
La gestión de vulnerabilidades incluye además fuentes que no requieren pruebas: los avisos de seguridad de los fabricantes, los boletines de los proveedores de nube y la información de los equipos de respuesta a incidentes.
Qué técnicas usar y quién lo decide
ISO/IEC 27002:2022 desarrolla la orientación para implementar los controles del Anexo A, entre ellos el 8.8. Para elegir técnicas, una referencia técnica pública es la guía SP 800-115 del Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST), que describe cómo planificar y ejecutar evaluaciones técnicas de seguridad, entre ellas el escaneo de vulnerabilidades y las pruebas de penetración. En la práctica, recomendamos que el escaneo se haga con herramientas adecuadas a las tecnologías en uso y que las pruebas de penetración las hagan personas competentes y autorizadas.
ISO/IEC 27002 es una guía, no una lista de requisitos certificables. El control 8.8 de ISO/IEC 27001 no fija que una organización deba hacer una prueba de penetración al año. La necesidad, la frecuencia y el alcance salen de la evaluación de riesgos y de las obligaciones que la organización tenga con clientes, contratos o reguladores.
Dos controles más se relacionan con las pruebas. El 8.29 pide definir e implementar procesos de pruebas de seguridad en el ciclo de desarrollo, y el 8.34 pide que las pruebas de auditoría y otras actividades de aseguramiento sobre sistemas en operación se planifiquen y acuerden entre quien las ejecuta y la dirección responsable.
Cuándo tiene sentido una prueba de penetración
Recomendamos considerarla, según el riesgo, en situaciones como estas:
- sistemas expuestos a internet que manejan información sensible, como portales de trámites, pagos o datos personales;
- antes de poner en producción una aplicación crítica o después de un cambio importante en su arquitectura;
- para comprobar que una corrección o un control nuevo funcionan frente a un ataque real;
- cuando un cliente, un contrato o una norma sectorial la exige.
Si la organización aún no tiene un inventario de activos ni un análisis periódico de vulnerabilidades, empezar por ahí suele dar más valor que una prueba de penetración aislada.
Antes de la prueba: autorización y alcance por escrito
En Colombia, el artículo 269A del Código Penal, adicionado por la Ley 1273 de 2009, sanciona a quien acceda a un sistema informático sin autorización o por fuera de lo acordado. Por eso conviene que la prueba cuente con una autorización por escrito de quien tiene el derecho sobre los sistemas, que delimite el alcance pactado. Undernet no presta asesoría jurídica: si tiene dudas sobre la autorización, consúltelas con su área legal.
El documento de alcance y reglas debería definir, como mínimo:
- los sistemas, direcciones y aplicaciones incluidos y los excluidos;
- las técnicas permitidas y las prohibidas, por ejemplo pruebas de denegación de servicio o ingeniería social;
- las fechas y horarios, y los contactos de emergencia de ambas partes;
- las condiciones del proveedor cuando los sistemas están en la nube o en un tercero, y su autorización cuando su política la exija;
- cómo se tratará la información sensible que el equipo encuentre y cuándo se eliminará.
Del hallazgo al tratamiento
Severidad no es riesgo
Los informes suelen clasificar las vulnerabilidades con el Sistema Común de Puntuación de Vulnerabilidades (CVSS). La puntuación base, que es la que suelen traer los informes, mide la gravedad técnica, no el riesgo para su organización; FIRST, que mantiene el sistema, lo advierte en su guía. Una vulnerabilidad crítica en un servidor de pruebas sin datos puede pesar menos que una media en el sistema que expone datos de los ciudadanos o los clientes. Para priorizar, cruce la severidad con la exposición y con el valor del activo, que sale del inventario y la clasificación de activos.
Plazos y excepciones
La norma no fija plazos de corrección; los define la organización según el riesgo. Recomendamos establecerlos por nivel de prioridad, con un responsable por hallazgo. Cuando no hay actualización disponible o no se puede aplicar a tiempo, se usan medidas alternativas, como desactivar el servicio afectado, restringir el acceso o aumentar la vigilancia, y conviene que la excepción quede aceptada por el dueño del riesgo, con fecha de revisión.
Verificación
Un hallazgo se cierra cuando se comprueba que la corrección funcionó, por ejemplo con un nuevo análisis o una nueva prueba sobre ese punto, no cuando alguien informa que aplicó el parche.
La evidencia que suele revisar un auditor
- el inventario de activos que define qué se analiza;
- el procedimiento de gestión de vulnerabilidades, con roles, fuentes y plazos;
- los informes de análisis y de pruebas, con su fecha y alcance;
- el registro de tratamiento: decisión, responsable, fecha y verificación;
- las excepciones aceptadas y su revisión;
- en las pruebas de penetración, la autorización y el documento de alcance.
Si la organización es una entidad pública, esta evidencia también alimenta la implementación del MSPI, que organiza sus controles según el Anexo A de ISO/IEC 27001:2022. Lo explica nuestro artículo sobre el MSPI e ISO/IEC 27001.
Errores frecuentes
- Tratar la prueba de penetración como un requisito anual fijo de la norma, en lugar de una decisión basada en el riesgo.
- Contratar la prueba sin un análisis previo de vulnerabilidades, de modo que el equipo gasta tiempo en debilidades que un escaneo habría encontrado.
- Priorizar solo por la puntuación CVSS, sin considerar el activo afectado.
- Cerrar hallazgos sin verificar la corrección.
- Probar sistemas en la nube sin revisar las condiciones del proveedor.
- Presentar el informe de la prueba como garantía de seguridad. Una prueba muestra lo que se encontró con un alcance y en una fecha; no demuestra que no haya otras vulnerabilidades.
Preguntas frecuentes
¿ISO 27001 exige una prueba de penetración para certificarse?
No de forma explícita. Cuando el control 8.8 es aplicable, exige gestionar las vulnerabilidades técnicas, y la organización decide con base en el riesgo qué actividades usa para hacerlo. El organismo de certificación evalúa la eficacia del control, no si se usó una técnica concreta.
¿Cada cuánto conviene hacer análisis de vulnerabilidades?
La norma no fija la frecuencia. Recomendamos definirla en el procedimiento según la exposición y la criticidad de los sistemas, y repetir el análisis después de cambios importantes.
¿Undernet puede ayudar?
Sí. Undernet ofrece asesoría, auditoría interna y capacitación en ISO/IEC 27001, y diagnósticos de vulnerabilidades con un alcance acordado con su organización. Undernet no certifica: preparamos a su organización para la auditoría del organismo de certificación que usted elija. Conozca el alcance en nuestra página de ISO/IEC 27001.
Solicite un diagnóstico de vulnerabilidades
Fuentes
- ISO/IEC 27001:2022, sistemas de gestión de seguridad de la información · ISO
- ISO/IEC 27002:2022, controles de seguridad de la información · ISO · 15 de febrero de 2022
- Ley 1273 de 2009, protección de la información y de los datos · Congreso de la República · 5 de enero de 2009
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment · NIST
- Common Vulnerability Scoring System v4.0, guía de usuario · FIRST