Gestión de vulnerabilidades en PCI DSS: Conectando todos los controles relacionados

La gestión de vulnerabilidades es una de las tareas más desgastantes en un entorno PCI DSS, ya que se requiere monitorizar periódicamente la publicación de notificaciones por parte de los fabricantes, revisar los reportes de los escaneos y pruebas de penetración, asignar una prioridad a cada vulnerabilidad identificada y –  con base en ello – gestionar su corrección y validar que las acciones implementadas fueron efectivas. Y todo esto dentro de unos límites de tiempo establecidos. Por esta razón, el PCI SSC publicó la infografía «PCI DSS v4.0.1 Vulnerability Management Processes», que sirve de referencia para enlazar todos los pasos y controles del estándar PCI DSS necesarios para la identificación, categorización, priorización y remediación de vulnerabilidades.

Cada uno de los pasos del proceso de gestión de vulnerabilidades de PCI DSS está descrito en un control específico del estándar, distribuídos a lo largo de diferentes requerimientos. Sin embargo, estas tareas no se habían esquematizado en un diagrama de flujo en el que se pudiera comprender su orden, sus prerrequisitos y su conexión con otros controles. Y es precisamente aquí en donde la infografía del PCI SSC entra en acción: Conectando de forma lógica cada uno de los controles para establecer una estrategia coordinada de gestión de vulnerabilidades.

Infografía de gestión de vulnerabilidades en PCI DSS

La infografía está dividida en dos partes:

• Una primera parte orientada al proceso de identificación, categorización y priorización de las vulnerabilidades identificadas y su riesgo asociado.
• Una segunda parte en donde, con base en los resultados anteriores, se procede con la gestión del riesgo, ya sea mediante la implementación de controles para su mitigación, la remoción del activo asociado, la delegación a un tercero o el uso de un control compensatorio si existen restricciones técnicas o administrativas que no permitan la implementación de controles como lo exige el estándar.

El objetivo final de esta actividad es gestionar cada vulnerabilidad identificada, garantizando que el riesgo asociado ha sido manejado de forma correcta.

Gestión de vulnerabilidades vs. análisis y gestión de riesgo

Es muy importante que las entidades afectadas por el cumplimiento de PCI DSS tengan presente que el proceso de categorización y asignación de niveles de criticidad a las vulnerabilidades identificadas es solamente el primer paso. De forma implícita, para poder contextualizar la vulnerabilidad en cada entorno específico, es imprescindible la ejecución de un análisis de riesgos.

Hay que tener presente que los fabricantes y otras entidades suelen usar sistemas de puntuación para evaluar la gravedad en vulnerabilidades, siendo uno de los más empleados Common Vulnerability Scoring System (CVSS). CVSS provee un sistema númerico de 0 a 10 para representar la criticidad de una vulnerabilidad. Sin embargo, no tiene en cuenta otras variables como la probabilidad de ataque o el impacto que puede tener una vulnerabilidad en un entorno particular, por lo que ese valor, sin su contexto adecuado, puede llevar a errores en los procesos de gestión del potencial riesgo.

Métricas de vulnerabilidades de CVSS. Fuente: https://nvd.nist.gov/vuln-metrics/cvss#

No se deben confundir los conceptos de «vulnerabilidad» y «riesgo». CVSS es una métrica para asignar criticidad a vulnerabilidades, no a riesgos

De acuerdo con el documento NIST Special Publication 800-30 Revision 1: Guide for Conducting Risk Assessments y otros muchos estándares y guías de análisis y gestión de riesgos (OCTAVE, ISO 27005, MAGERIT, FAIR, etc.) se deben contemplar los siguientes elementos para poder tener un contexto claro del potencial riesgo:

• Amenaza (threat): Una amenaza es cualquier circunstancia o evento con el potencial de afectar de forma adversa las operaciones de la organización y sus activos, individuos, otras organizaciones o a la Nación a través de a través de un sistema de información vía acceso no autorizado, destrucción, divulgación, o modificación de información, y/o denegación de servicio.
• Vulnerabilidad (vulnerability): Una vulnerabilidad es una debilidad en un sistema de información, en los procedimientos de seguridad del sistema, en los controles internos o en su implementación que podría ser explotada por una fuente de amenaza.
• Probabilidad (likelihood): La probabilidad de ocurrencia es un factor de riesgo ponderado basado en un análisis de la probabilidad de que una amenaza dada sea capaz de explotar una vulnerabilidad dada (o un conjunto de vulnerabilidades).
• Impacto (impact): El nivel de impacto de un evento de amenaza es la magnitud del daño que puede esperarse que resulte de las consecuencias de la divulgación no autorizada de información, la modificación no autorizada de información, la destrucción no autorizada de información, o la pérdida de información o de disponibilidad del sistema.
• Riesgo (risk): El riesgo es una función de la probabilidad de que se produzca una amenaza y del impacto adverso potencial en caso de que se produzca. Para calcular el riesgo existen múltiples fórmulas, tanto cuantitativas como cualitativas, entre ellas:
  • Riesgo = probabilidad x impacto – MAGERIT
  • Riesgo = vulnerabilidad x probabilidad x impacto – FAIR (Factor Analysis of Information Risk)
  • Riesgo = (amenaza x vulnerabilidad x probabilidad x impacto)/controles implementados

Modelo genérico de riesgos con sus componentes críticos (NIST 800-30)

Soalmente con un análisis de estas variables, se puede tener un contexto completo para priorizar y definir las acciones a realizar:

• Mitigar el riesgo, empleando el despliegue de controles propios del estándar o controles compensatorios, minimizando el riesgo hasta un umbral tolerado por la organización.
• Eliminar el riesgo, removiendo el activo afectado del entorno.
• Transferir el riesgo, delegando su gestión y responsabilidad a un tercero.

Vale la pena anotar que bajo el estándar PCI DSS, cualquier riesgo identificado no puede ser aceptado (es decir: no se puede conocer el riesgo y no hacer nada para gestionarlo), ya que se expondría a la entidad a una potencial afectación de los datos de tarjetas de pago.

Estrategias de gestion de riesgos en PCI DSS

Volviendo nuevamente al infográfico del PCI SSC, una vez se tienen los valores de criticidad de una vulnerabilidad en particular (ya sea que hayan sido provistos por el fabricante o por un tercero o hayan sido calculados por la entidad), se debe proceder con su contextualización al entorno afectado, para lo cual se deben agregar a la ecuación todas las demás variables listadas anteriormente (amenaza, probabilidad, impacto). Cuando el valor del riesgo sea obtenido, se deberá proceder con la priorización de la remediación. Esta acción se encuentra implícita en la siguiente sección de la infografía:

Análisis de riesgos para priorizar la remediación

Es MUY IMPORTANTE que no se use únicamente el valor de criticidad de la vulnerabilidad como elemento de priorización de la remediación. La priorización debe venir de un análisis de riesgos, que agrega la contextualización necesaria del entorno afectado y otorga un valor real de priorización.

Ejemplo prácticos de gestión de vulnerabilidades

A continuación se presenta un ejemplo sencillo de gestión de vulnerabilidades con base en los criterios descritos arriba. Es importante tener en cuenta que existen múltiples formas de calcular el riesgo, por lo que la entidad debe escoger y adaptar estas fórmulas a sus propias necesidades.

Para efectos de este ejemplo, se usará la calculadora de riesgos de la OWASP (OWASP Risk Rating Calculator), que se basa en la fórmula Probabilidad x Impacto, teniendo en cuenta amenazas y vulnerabilidades.

Ejemplo: Vulnerabilidad explotable en base de datos

Para este caso, imaginemos que se ha identificado una vulnerabilidad técnica en una base de datos que permite el escalamiento de privilegios de usuarios autenticados para obtener provilegios administrativos. Se trata de una vulnerabilidad pública, con exploits y herramientas de explotación disponibles. No obstante, los datos sensibles almacenados en esta base de datos están cifrados, existe un sistema de detección de intrusiones implementado y hay registro de acciones (logs). Si un atacante llegase a acceder a los datos almacenados, el impacto sería menor (ya que la información sensible está protegida) pero podría tener impacto en la reputación de la entidad si se publica en foros en línea.

Ajustando los valores de las variables, obtenemos que el resultado es ALTO (HIGH) y, de acuerdo con PCI DSS req. 6.3.3, su corrección debería implementarse dentro del primer mes una vez sea liberada la actualización.

Resultado del análisis de riesgos empleando OWASP Risk Rating Calculator

Es importante ver que los valores asignados a la vulnerabilidad (vulnerability factors) son críticos (si se usara CVSS sería una vulnerabilidad con puntuación de 9 (CRITICAL), por ejemplo) pero, teniendo en cuenta el contexto de la organización, los controles implementados y el impacto, su criticidad disminuye. Precisamente por esta razón es TAN IMPORTANTE contextualizar los valores tanto de vulnerabilidades como de riesgos.

Comentarios adicionales

Si bien esta infografía del PCI SSC sirve como punto de inicio y referencia para la gestión de vulnerabilidades, existen algunos elementos que no fueron tenidos en cuenta y que deberían ser incorporados en versiones posteriores:

1. El estándar PCI DSS v4.0.1 no hace una clara diferenciación enter los conceptos de «vulnerabilidad» y «riesgo», usándolos algunas veces como sinónimos. Como se explicó arriba, las criticidades de las vulnerabilidades son generalmente provistas por los fabricantes o por terceros con fórmulas estándar (CVSS, por ejemplo) que no contemplan las particularidades de cada entorno afectado. Por ello, el factor que debe ser usado para priorizar las acciones de remediación es el riesgo y no la criticidad de la vulnerabilidad.
2. La infografía está enfocada en los resultados provenientes de escaneos de vulnerabilidades internos, pero es aplicable también a escaneos externos (ASV) y pruebas de penetración, así como a procesos de análisis de código.
3. El flujograma inicia con la ejecución de escaneos. No obstante, las vulnerabilidades también pueden identificarse desde notificaciones de los fabricantes, revisiones internas, notificaciones provenientes de programas de bug bounty, etc.
4. Se asume que las acciones de remediación son solamente la instalación de actualizaciones de seguridad (parches). Sin embargo, también se pueden emplear otras acciones tales como correcciones de configuraciones, implementación de controles compensatorios, remoción de los activos afectados, etc.
5. Finalmente, una vez implementada la remediación, es necesario volver a ejecutar un escaneo (rescan – 11.3.1.3/11.3.2.1) o pentest (11.4.4) para confirmar que todo está funcionando como se espera y actualizar las guías de configuración segura para prevenir que el mismo problema sea replicado en el despliegue de activos similares (2.2.1).