¿Qué procesos y evidencias se exigen exactamente para la gestión de vulnerabilidades en la auditoría ISO 27001?

Separa el alcance en dos partes: Infraestructura y código. En la parte de infra, pasa un escáner de vulnerabilidades de código abierto una vez al mes a tus bloques de IP y genera un informe. En la parte de código, añade una herramienta de control de dependencias a tu CI/CD; si al compilar se detecta una librería con una vulnerabilidad crítica conocida, que se pare el proceso. Esos logs del pipeline son la evidencia técnica favorita de los auditores.

Cuando nos auditamos el año pasado mantuvimos unos objetivos de resolución realistas: 7 días para críticas, 30 para altas y 90 para medias. El auditor encontró 4 vulnerabilidades altas sin cerrar en la primera revisión, pero al ver los formularios de aceptación de riesgo con su justificación de negocio nos aprobó sin sacar ninguna no conformidad.

Tu carpeta para la auditoría debe contener sí o sí estos cuatro elementos: 1) Política de Vulnerabilidades aprobada y tabla de SLA, 2) Informes resumidos de escaneo fechados de los últimos tres meses, 3) Historial de resolución de tickets en tu gestor de tareas, 4) Documentos de Aceptación de Riesgo firmados para aquellos fallos que no se hayan podido parchear por motivos técnicos u operativos.

nunca le digan al auditor "aquí no nos sale nniguna vulnerabilidad" sospechan de una y empiezan a rascar más hondo. lo mejor es enseñar un listado de seguimiento transparente q demuestre q salen fallos, q los priorizan según la gravedad y q los van cerrando.

edit: escrito desde el móvil, perdonad las erratas.

¿Y el auditor de la ISO acepta como documento oficial los informes hechos con herramientas de escaneo open source gratuitas o hacen falta sí o sí informes con licencia de software corporativo caro?

Al auditor le da igual la marca de la herramienta lo q mira es la metodología. Escaneen ya mismo todas sus IP externas con una herramienta gratuita pasen las vulnerabilidades a una hoja de cálculo asígnenselas a los desarrolladores responsables y pongan fecha a las cerradas. Si enseñan este ciclo de dos meses pasan la auditoría sin problema.

Los consultores suelen meter miedo para q compres software de escaneo carísimo. Pero la norma no te pide perfección, sino un mecanismo de control definido. Un script de automatización simple hecho por ti y un registro regular de tickets pasan la auditoría perfectamente si tienen una estructura lógica.

Lo probaré.

Separemos los conceptos, se están confundiendo. Si la verificación en dos pasos está activa, una contraseña robada no sirve de nada por sí sola.

También me gustaría saber si alguien lo hace de otra manera.

En teoría es correcto, pero en la práctica no funciona así. La respuesta varía mucho según el sector, no hay una regla general.

Ánimo.

rara vez se encuentra un texto que lo explique tan claro.

De acuerdo, incluso me gustaría recalcarlo. Si obtienes tres respuestas distintas sobre un tema, la pregunta está mal formulada.

Ánimo.

Aquí hay una trampa, no puedo dejar de mencionarla. Empezad con una pequeña prueba, no lo integréis todo de golpe.

También me gustaría saber si alguien lo hace de otra manera.

Hay tres cosas que revisar al hacer esto. El error cometido por gestión de vulnerabilidades suele ser reversible, pero caro.

Los entornos de prueba olvidados son una puerta de entrada más frecuente que el sistema en producción.

Yo no me apresuraría. La gente no defiende el proceso, defiende la costumbre. La resistencia viene de ahí.

Esta es mi opinión, no lo escribo como una verdad absoluta.

guardado.

Yo también estaba pensando en lo mismo. Antes de decidir, mirad qué datos tenéis en la mano.

Los primeros tres meses todo va bien, los problemas aparecen en el cuarto. Yo seguiría por ese camino.

Tomo nota, gracias.