PCI DSS v4.0.1: Cómo gestionar las vulnerabilidades internas y externas según los nuevos lineamientos
El Consejo de Normas de Seguridad de PCI DSS ha publicado un nuevo diagrama que explica de manera detallada cómo debe realizarse la gestión de vulnerabilidades, una de las actividades más exigentes del estándar. Este proceso hace referencia directa a los controles 6.3.1, 6.3.3, 11.3.1 y 11.3.1.1, y está dividido en dos grandes etapas:
- Identificación y clasificación del riesgo de las vulnerabilidades
- Resolución o tratamiento de las vulnerabilidades
-
Identificación y clasificación de vulnerabilidades
El primer paso es identificar las vulnerabilidades internas a través de escaneos regulares, tal como lo exige el control 11.3.1, el cual establece que se deben realizar análisis de vulnerabilidades al menos una vez cada tres meses utilizando herramientas especializadas. Además, el requisito 6.3.1 exige tener en cuenta otras fuentes de información externas, como bases de datos de la industria, para complementar la identificación de posibles fallas.
Es fundamental aclarar que los controles 11.3.1 y 6.3.1 no son equivalentes ni intercambiables. Mientras el primero se enfoca en los escaneos técnicos, el segundo requiere un análisis más amplio y estratégico de las amenazas, incluso cuando estas provienen de fuentes externas.
Una vez identificadas, las vulnerabilidades deben ser clasificadas en función de su criticidad. Por defecto, muchas organizaciones adoptan la puntuación que entregan las herramientas de escaneo o las fuentes externas (como CVSS), pero el estándar permite que la entidad ajuste este ranking si considera que el contexto de su entorno así lo requiere.
Este análisis interno puede incluir factores como:
- Nivel de exposición (por ejemplo, si el sistema está conectado a redes públicas)
- Frecuencia de explotación
- Impacto potencial
- Rol del sistema afectado en los procesos críticos
- Controles compensatorios existentes
Para una clasificación más precisa, es posible utilizar herramientas como la calculadora CVSS del NIST (https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator), que permite ajustar los parámetros con base en el entorno específico.
Lo más importante es que la organización logre una evaluación de riesgo robusta, con un score lo más exacto posible, ya que este determinará los tiempos de respuesta y el nivel de atención que debe recibir cada vulnerabilidad.
-
Resolución o tratamiento de vulnerabilidades
El segundo paso es resolver (es decir, corregir) o abordar (mitigar) las vulnerabilidades identificadas. Según el diagrama del PCI Council, estos términos no son equivalentes:
- Resolver implica corregir directamente la falla (por ejemplo, aplicar un parche)
- Abordar puede incluir acciones alternativas para mitigar el riesgo, como implementar controles compensatorios o desactivar servicios vulnerables
El tratamiento de las vulnerabilidades se divide en dos rutas principales:
- a) Vulnerabilidades críticas y de alto riesgo
Estas deben ser corregidas en los tiempos establecidos por la entidad, según el ranking definido en el control 6.3.1. Además, el control 6.3.3 exige que los parches para vulnerabilidades críticas se instalen dentro del primer mes tras su publicación por parte del proveedor.
- b) Otras vulnerabilidades (no críticas ni de alto riesgo)
Para el resto de las vulnerabilidades, el nuevo requisito 11.3.1.1 introduce la necesidad de realizar una evaluación de riesgo (TRA, por sus siglas en inglés). Esta evaluación permite a la organización definir plazos de remediación acordes al nivel de riesgo, siempre en coherencia con los criterios establecidos en el control 6.3.1.
Se recomienda que estos tiempos definidos en el TRA se alineen con las prioridades del sistema y los riesgos reales para garantizar una gestión eficiente.
Vulnerability Management Processes
Source: pcisecuritystandards
