El objetivo de este artículo es describir un time-line de gestión de una vulnerabilidad crítica alineado con los requisitos de PCI DSS 3.2.1. Es importante comentar que no hay una única manera de gestionar vulnerabilidades alineadas con PCI DSS, pero sí que todas ellas deben contener al menos los puntos de control identificados en este artículo.
El siguiente esquema nos muestra, a alto nivel, los procedimientos de gestión que intervienen en la gestión de una vulnerabilidad crítica, alineado con los requisitos de PCI DSS.
t0: Descubrimiento y publicación de la vulnerabilidad.
El primer objetivo que toda empresa debe perseguir para una óptima gestión de vulnerabilidades es ser capaz de detectarlas en el menor tiempo posible. Por ello, es de vital importancia que, dentro del proceso de gestión de vulnerabilidades se haya definido cuales son las fuentes que la empresa va a consultar y con qué frecuencia.
Este objetivo está incluido en el requisito 6.1 de PCI DSS v3.2.1. En el cual, se establece que las fuentes que se consulten sean de confianza. Por ejemplo, la página web oficial del proveedor del sistema de información (Firewalls, switches, bases de datos, servidor de aplicaciones…), páginas web de gubernamentales (INCIBE, NIST, …), así como otras fuentes de confianza para la empresa, como pueden ser los repositorios de las librerías que se utilicen para desarrollos ad-hoc (Log4j, Spring, Git).
Para minimizar el tiempo desde que la fuente de confianza pública una vulnerabilidad y la empresa la identifica, quizá la mejor manera es estar suscrito a los canales de notificaciones de la fuente; ya sean listas de correo, RSS, u otras.
t1: Identificación y análisis de la criticidad de la vulnerabilidad y su impacto dentro de la empresa.
Una vez que la empresa ha identificado una vulnerabilidad, que potencialmente puede afectar a los sistemas de información de la entidad, se debe analizar:
- Si realmente afecta a los sistemas de la empresa. Por ejemplo, si es una vulnerabilidad para la versión de software que estamos utilizando o, si por el contrario, aunque sea una vulnerabilidad muy grave esta no afecte a la empresa, ya que no afecta a la versión de software que la empresa utiliza o explota un servicio que se encuentra deshabilitado.
- La criticidad de la vulnerabilidad, generalmente basado en un estándar de referencia.
Los requisitos que engloban la identificación y la instalación de vulnerabilidades son 6.1 y 6.2 en la actual norma de PCI DSS v3.2.1. El primero de ellos, rige la identificación y análisis de la vulnerabilidad. Y el requisito 6.2 define la necesidad de aplicar todos los parches de seguridad que se publiquen, así como el tiempo máximo que se puede demorar la instalación del parche, dada la criticidad de la vulnerabilidad que solvente.
A modo de ejemplo, este podría ser un análisis tipo (el mínimo recomendable), para identificar el tipo de vulnerabilidad y analizar la criticidad de la misma.
Información sobre la vulnerabilidad.
La vulnerabilidad de log4j fue descubierta el pasado 13 de diciembre y supuso una de las mayores brechas de seguridad identificadas en la última década. Dado el amplio uso que tiene la librería log4j (https://logging.apache.org/log4j/2.x/) en todo tipo de productos y servicios, ya sean comerciales o de desarrollo ad-hoc en cualquier empresa.
La librería log4j, aunque de sobra conocida, es una librería software libre de apache.org que permite generar logs (archivo donde se registran eventos o acciones) de calidad en las aplicaciones en muy pocas líneas de código. Su gran aceptación y uso en la industria es debido a la mínima interferencia en el código y a su licencia libre de uso (https://logging.apache.org/log4j/2.x/license.html#).
Criticidad y cómo un atacante podría explotar la vulnerabilidad.
Aunque el análisis en profundidad de la vulnerabilidad no es objeto de este artículo, dicha vulnerabilidad permite ejecutar código en máquinas remotas, sin necesidad de autenticación o acceder a información de la aplicación que implementa la librería log4j en las versiones anteriores a 2.15.0.
La vulnerabilidad original de log4j (CVE-2021-44228), posteriormente se han identificado otras vulnerabilidades relacionadas, fue calificada con una severidad de 10 sobre 10 por el NIST y así está publicado en la National Vulnerability Database (https://nvd.nist.gov/vuln/detail/CVE-2021-44228).
Aunque el requisito 6.1 de PCI DSS permite a la empresa asignar una criticidad propia a las vulnerabilidades que se analizan, dado que dicho análisis de criticidad debe tener como base alguna conocida, por ejemplo, el CVSS, mi recomendación es utilizar directamente la asignación de criticidad que es asignada a la vulnerabilidad en el momento de su publicación.
Una vez analizada la criticidad de la vulnerabilidad, y sabiendo que realmente afecta a los sistemas de la empresa, hay que monitorizar la publicación del parche de seguridad de manera constante. Y una vez esté a disposición de la empresa, iniciar la fase de gestión del cambio lo antes posible, ya que hay que tener en cuenta los tiempos de gestión del cambio dentro del tiempo máximo que el requisito 6.2 de PCI DSS establece para la instalación de parches de seguridad.
t2: Actualización de sistemas de información para solventar la vulnerabilidad.
La actualización de sistemas de información, más si cabe los que están en entornos productivos, nunca es un proceso banal, ya que cualquier error no solo afecta al área de TI si no también posiblemente a las áreas de negocio. Por ello, es fundamental que la empresa cuente con un proceso de gestión del cambio robusto y que se actualice siempre que se identifique alguna casuística especial no contemplada anteriormente.
El procedimiento de gestión del cambio debe, al menos, contener los ítems identificados en el requisito 6.4.5. y relacionados de PCI DSS. Para cada cambio que se vaya a realizar hay que:
- Analizar el impacto que puede tener en el sistema / aplicación a actualizar, así como a todos los sistemas / aplicaciones relacionadas a los que la actualización pueda afectar.
- Aprobación formal por parte de los responsables de los sistemas, autorizando los cambios que se vayan a realizar.
- Antes de realizar la actualización en un entorno productivo, se debe actualizar los sistemas de los entornos no productivos y realizar todas las pruebas que se consideren oportunas, para de este modo asegurar que el cambio no tiene un impacto negativo en cualquier operativa en los sistemas que están afectados o relacionados con la actualización.
- Definir y tener preparado un rollback para todos los sistemas afectados o relacionados con la actualización. El objetivo es que, en caso de que se produzca cualquier imprevisto en el entorno productivo, este pueda volver a su estado previo de la actualización en el menor tiempo e impacto posible para la operación y para la seguridad de los sistemas.
- Por último, una vez realizada la actualización en todos los sistemas involucrados en el cambio, se deben proceder de igual manera en todos los documentos o repositorios de información relacionados con el cambio. En este caso podrían ser; la CMDB donde está identificada la versión de la librería log4j que estamos utilizando, alguna guía de desarrollo seguro, … etc.
t3: Análisis de puntos débiles a mejorar en el proceso de gestión de vulnerabilidades.
Una vez solventada la vulnerabilidad crítica de los sistemas de información, es el momento de analizar cómo ha sido el proceso tanto de la identificación y gestión de la vulnerabilidad como del proceso de gestión del cambio. El objetivo de esta revisión es analizar qué puntos de todo el proceso no han sido todo lo eficientes que nos hubiera gustado y ver cómo podemos mejorar o simplificar los mismos para conseguir un modelo más eficiente. Esto es lo que otros estándares denominamos "Lecciones aprendidas", el cual busca una mejora continua de los procesos de seguridad.
Sin duda alguna, este análisis si se hace desde un punto vista crítico y con el único objetivo de mejorar día a día el proceso de la empresa, nos permitirá mejorar la gestión de vulnerabilidades e ir alcanzando un nivel de madurez cada vez mayor, tanto en este proceso como a nivel general para toda la empresa.
Conclusión
Como se ha descrito en el artículo, la actualización de una pequeña, aunque importante, librería en una aplicación de un entorno PCI DSS, requiere un proceso de gestión y coordinación entre los diferentes roles en la empresa importante. Por ello, es de suma importancia seguir los procedimientos definidos, para minimizar errores y/o demorar el proceso por encima de lo definido en la norma de PCI DSS.
Cabe recordar que la norma PCI DSS es un estándar auditable y que por ello será necesario preservar las evidencias durante toda la gestión de la vulnerabilidad para, llegado el momento, poder evidenciar en la auditoria PCI DSS la madurez del proceso que la empresa tiene implantado y que se están siguiendo los controles identificados.
Bibliografía
- Log4j Oficial web page: https://logging.apache.org/
- Incibe: https://www.incibe.es/protege-tu-empresa/avisos-seguridad/vulnerabilidad-critica-apache-log4j
- Cybersecurity & Infraestructure Security Agency https://www.cisa.gov/uscert/ncas/current-activity/2021/12/10/apache-releases-log4j-version-2150-address-critical-rce
- National Vulnerability Database (https://nvd.nist.gov/vuln/detail/CVE-2021-44228)
- Explicación exploit-log4shell: https://news.sophos.com/es-419/2021/12/21/dentro-del-codigo-como-funciona-el-exploit-log4shell/
- PCI DSS v3.2.1: https://www.pcisecuritystandards.org/document_library#agreement
Autor: David de la Fuente - PCI QSA, CISA, CISM, 22301 L.A., CDPSE
Dpto. Consultoría
