ISO/IEC 27001:2022 · destino de mapeo derivado
A.8.8Management of technical vulnerabilities
Find out about technical vulnerabilities in your systems, assess your exposure and take timely action such as patching. Known, unpatched weaknesses are a leading cause of breaches.
El mapeo de un vistazo
A.8.8Management of technical vulnerabilitiesISO/IEC 27001:2022
A.8.8 queda cubierto por 30 controles del Sekit CSF. +25 más en la tabla de abajo. Abrir en el grafo completo →
Mapeado desde el Sekit CSF
Los controles de Sekit que cubren este requisito, lente a lente.
RCF-0009Risk assessment · TécnicaapoyaAlimentar las evaluaciones de riesgo con datos reales de escáner y vulnerabilidades fundamenta la evaluación técnica de exposición de A.8.8 en evidencia en lugar de opinión.RCF-0012Risk treatment · TécnicaapoyaVerificar que cada medida técnica de riesgo acordada esté realmente configurada en el entorno de producción cierra el ciclo entre una decisión de vulnerabilidad y su implementación.RCF-0033Control testing program · TécnicaapoyaLos escaneos de vulnerabilidades programados y las verificaciones de desviación de configuración ejercitan los controles técnicos de forma continua, dándole a la visión de exposición de A.8.8 evidencia permanente en lugar de puntual.RCF-0127Dependency/SBOM management · PolíticaapoyaEsta faceta de política ordena que se inventaríe todo componente de terceros, la pata de composición de software de la exposición de A.8.8 de la que dependen las vulnerabilidades de dependencias.RCF-0128Dependency/SBOM management · ProcesoapoyaLa faceta de proceso mantiene actualizada una lista de materiales por aplicación y la revisa frente a datos de vulnerabilidades conocidas con un calendario.RCF-0129Dependency/SBOM management · TécnicaapoyaLa faceta técnica ejecuta escaneo automatizado de dependencias que marca o bloquea compilaciones con componentes de vulnerabilidad conocida, una fuente directa de los datos técnicos de vulnerabilidad de A.8.8.RCF-0154Patch management · PolíticaapoyaEsta faceta de política fija plazos escritos para aplicar actualizaciones de seguridad por severidad en todo sistema que opera la empresa, la columna vertebral de plazos que pide A.8.8.RCF-0155Patch management · ProcesoapoyaLa faceta de proceso aplica las actualizaciones según el calendario acordado y rastrea el estado de parcheo por dispositivo para que nada quede atrás sin que se note.RCF-0156Patch management · TécnicaapoyaLa faceta técnica automatiza el despliegue de parches y reporta los pendientes por antigüedad y severidad en toda la flota, la herramienta en la que se apoya el programa de parches de A.8.8.RCF-0200SIEM use cases · ProcesorelacionadoRevisar y actualizar las reglas de detección del SIEM en un ciclo recurrente mantiene actualizada la detección de amenazas, una práctica de monitoreo adyacente pero distinta del manejo de vulnerabilidades de A.8.8.RCF-0217Vulnerability scanning · PolíticaapoyaEsta faceta de política exige que todo servidor, estación de trabajo y servicio accesible desde el exterior se escanee con un calendario definido, alineándose con el requisito central de escaneo de A.8.8.RCF-0218Vulnerability scanning · ProcesoapoyaLa faceta de proceso ejecuta escaneos según el calendario y asigna cada hallazgo relevante a alguien para que actúe, convirtiendo la salida del escaneo en trabajo rastreado.RCF-0219Vulnerability scanning · TécnicaapoyaLa faceta técnica despliega un escáner automatizado que cubre todo el parque de activos y envía los hallazgos al sistema de seguimiento del que depende el requisito de escaneo de A.8.8.RCF-0220Vulnerability remediation SLAs · PolíticaapoyaEsta faceta de política define plazos de remediación por severidad, la tabla de SLA que espera A.8.8 que la organización se exija a sí misma.RCF-0221Vulnerability remediation SLAs · ProcesoapoyaLa faceta de proceso rastrea cada vulnerabilidad abierta frente a su plazo y escala antes de que se venza, no después.RCF-0222Vulnerability remediation SLAs · TécnicaapoyaLa faceta técnica calcula automáticamente la antigüedad de la vulnerabilidad frente a la tabla de plazos y notifica a los responsables cuando los ítems se acercan o superan la fecha límite.RCF-0229Patch prioritization · PolíticaapoyaEsta faceta de política define cómo se priorizan los parches por severidad, criticidad del activo y explotación activa, la lógica de priorización de la que depende el requisito de acción oportuna de A.8.8.RCF-0230Patch prioritization · ProcesoapoyaLa faceta de proceso aplica la regla de priorización en cada ciclo y registra el motivo cada vez que un parche se aplaza más allá de la ventana de su nivel.RCF-0231Patch prioritization · TécnicaapoyaLa faceta técnica combina la severidad del escáner con inteligencia de amenazas en tiempo real para que la cola de parches se reordene según lo que realmente se está explotando.RCF-0232Exposure management · PolíticaapoyaEsta faceta de política se compromete a mantener una vista de todo lo expuesto a internet y a reducir la exposición sin necesidad de negocio, la pata de gestión de exposición de A.8.8.RCF-0233Exposure management · ProcesoapoyaLa faceta de proceso mantiene un inventario preciso de activos expuestos a internet y cierra la exposición que carece de justificación de negocio.RCF-0234Exposure management · TécnicaapoyaLa faceta técnica ejecuta monitoreo continuo de superficie de ataque externa que alerta cuando aparece un servicio nuevo o uno conocido se vuelve vulnerable.RCF-0235Penetration testing · PolíticaapoyaEsta faceta de política se compromete a una prueba de penetración independiente en un intervalo definido y tras cambios importantes, la pata de validación adversarial que espera A.8.8.RCF-0236Penetration testing · ProcesoapoyaLa faceta de proceso define el alcance de cada prueba de forma deliberada, la ejecuta con un evaluador calificado y rastrea cada hallazgo hasta su cierre o aceptación formal.RCF-0329Software supply chain (SBOM) · ProcesoapoyaMantener actualizado el inventario de componentes de cada aplicación y revisarlo en busca de dependencias vulnerables extiende el rastreo de exposición de A.8.8 a la cadena de suministro de software.RCF-0330Software supply chain (SBOM) · TécnicaapoyaEl escaneo automatizado de dependencias en el pipeline marca componentes con vulnerabilidades conocidas antes de que se lancen, una instancia de cadena de suministro de la identificación técnica de vulnerabilidades de A.8.8.RCF-0347Workload protection · ProcesoapoyaVerificar las cargas de trabajo en la nube en ejecución frente al estándar de seguridad e investigar las desviaciones extiende la revisión técnica de exposición de A.8.8 a la infraestructura en la nube específicamente.RCF-0424Patch/compensating controls (ICS) · PolíticaapoyaEsta faceta de política define un enfoque documentado para vulnerabilidades de OT que no pueden parchearse en los plazos normales de TI, la pata compensatoria que anticipa A.8.8 para sistemas de producción.RCF-0425Patch/compensating controls (ICS) · ProcesoapoyaLa faceta de proceso evalúa las vulnerabilidades de OT a medida que llegan los avisos y establece una medida compensatoria documentada dondequiera que el parcheo no sea viable.RCF-0426Patch/compensating controls (ICS) · TécnicaapoyaLos controles técnicos compensatorios, aislamiento de red, listas de aplicaciones permitidas, monitoreo dirigido, protegen los sistemas de producción que no pueden parchearse tal como espera A.8.8 cuando el parcheo normal no puede aplicarse.
Correspondencias en NIST CSF 2.0
Alcanzadas a través de los controles del Sekit CSF que ambos mapean: un mapeo, no una equivalencia formal.
Correspondencias en Cyber Essentials
Evidencia que demuestra este control
Lo que pide un auditor, o el motor de evidencias de Sekit.
Informe de actualizaciones y parches
La prueba de que las actualizaciones de seguridad se aplican a tiempo en los equipos y sistemas, con seguimiento de lo que queda pendiente.
Del catálogo de evidencias de Sekit
En la práctica
La gestión de vulnerabilidades suele tener un escáner en funcionamiento y una hoja de cálculo que nadie mantiene al día. Una pyme puede mostrar que un escaneo se ejecutó el mes pasado, pero el reporte queda en una bandeja de entrada en lugar de alimentar un sistema de seguimiento con responsables y plazos. Los hallazgos críticos se parchean rápido porque alguien los nota; los hallazgos medios de hace seis meses siguen abiertos porque nadie escala antes de que se venza el plazo. El escaneo de dependencias marca una biblioteca desactualizada en la compilación, pero el ticket para actualizarla lleva abierto desde el último lanzamiento, retomado solo cuando el siguiente escaneo vuelve a marcar la misma biblioteca.
Brechas habituales
Los escaneos de vulnerabilidades se ejecutan según un calendario definido, pero los hallazgos no se asignan a un responsable ni a un plazo, así que la remediación depende de que alguien lo recuerde.
Las vulnerabilidades críticas se parchean rápido, pero los hallazgos de menor severidad rutinariamente incumplen su plazo de remediación sin escalarse a dirección.
El escaneo de dependencias marca bibliotecas desactualizadas en la compilación, pero el ticket de corrección sigue abierto a lo largo de varios lanzamientos en lugar de bloquear uno.
Preguntas que hará tu auditor
¿Con qué rapidez se espera corregir las vulnerabilidades críticas una vez encontradas?
Plazos escritos fijan días para correcciones críticas y ventanas progresivamente más largas para severidades menores, y una herramienta rastrea automáticamente la antigüedad de la vulnerabilidad frente a esa tabla.
¿La empresa sabe qué está expuesto a internet en un momento dado?
El monitoreo continuo de superficie de ataque externa alerta al equipo cuando aparece un servicio nuevo o uno conocido se vuelve vulnerable.
¿Cómo se verifican los componentes de código abierto en el código base en busca de fallos conocidos?
El escaneo automatizado de dependencias se ejecuta en el pipeline y marca o bloquea las compilaciones que contienen componentes con vulnerabilidades conocidas.
¿Las pruebas de penetración son un ejercicio único o se repiten?
Se encarga una prueba de penetración independiente a un intervalo definido y tras cambios importantes, con los hallazgos rastreados hasta su cierre.
Dónde lo exige la regulación
El artículo 21 de NIS2 exige gestión de parches de seguridad (6.6) y un proceso definido de manejo y divulgación de vulnerabilidades (6.10).
El ENS op.exp.4 exige mantenimiento y actualizaciones de seguridad, la obligación operativa que satisface el programa de parches y remediación de A.8.8.
Controles relacionados
Vía el tema compartido del Sekit CSF, no el índice del propio marco.
Pregúntale a Sekura: «¿Qué evidencia demuestra A.8.8?»
También vía MCP, gratis con cuenta