Informe de riesgos de seguridad de los productos de Red Hat de 2024: CVE, XZ Backdoor, SSCA, IA... ¡Vaya!

Tómate una buena taza de café o té y lee el Informe de riesgos de seguridad de los productos de 2024 de Red Hat Product Security. Como alguien que se esfuerza por mantenerse informado sobre el ecosistema del open source y sus desafíos de seguridad, me pareció que el informe de este año era mucho más extenso, pero la profundidad y los detalles no me decepcionaron. De hecho, una adición notable al informe de este año es el análisis de la inteligencia artificial. 

El juego de los números: sube, sube y... un momento, ¿qué?

Primero, analicemos los números sin procesar. Los avisos de seguridad de Red Hat (RHSA) alcanzaron un nuevo pico en 2024, con 2975. Se observó un aumento constante en los últimos años.  Curiosamente, mientras que los avisos importantes y moderados experimentaron un aumento significativo, los avisos críticos disminuyeron ligeramente, lo que apunta hacia prácticas de seguridad más proactivas y una detección más rápida.

El recuento de vulnerabilidades y exposiciones comunes (CVE) se disparó a 4272, un aumento significativo con respecto a años anteriores, que se mantuvieron relativamente estables. ¿Qué causó esto? El informe, se destaca que la Linux Kernel Organization se convirtió en una autoridad de numeración de CVE (CNA) en febrero de 2024. Comenzaron a asignar CVE a numerosos problemas de kernel, muchos de los cuales no habrían recibido asignaciones anteriormente. Si filtras los nuevos CVE de kernel.org, la línea de tendencia parece más familiar, con un ligero aumento, lo que probablemente refleja el crecimiento de la cartera de Red Hat, pero nada alarmante. 

En un análisis más profundo, la mayoría de los CVE nuevos del kernel se calificaron como moderados y bajos, y solo el 45 % de los CVE asignados por kernel.org en 2024 afectaron a los kernels actuales de Red Hat Enterprise Linux (RHEL). Además, el enfoque debe permanecer en las vulnerabilidades críticas e importantes que se alinean con los intentos reales de explotación. Este enfoque está validado por la rapidez de respuesta de Red Hat para más de la mitad de los CVE críticos, lo que proporciona las primeras correcciones en siete días o menos, y tres correcciones en el día 0.

Sin el contexto anterior, al analizar estas métricas, podrías pensar: ¿qué está haciendo Red Hat? El recuento de CVE sin procesar aumentó considerablemente, pero el perfil de riesgo subyacente de los productos de Red Hat no cambió en paralelo. Estos números refuerzan que confiar únicamente en el recuento de CVE no es suficiente; también debes considerar la gravedad, la capacidad de explotación y la relevancia. Los datos validan el enfoque de Red Hat en la aplicación de parches  a los problemas críticos e importantes, lo que demuestra que es allí donde se produce la mayor parte de la explotación en el mundo real, lo que demuestra que un enfoque basado en los riesgos tiene más sentido.

XZ Backdoor: el tema ineludible

¿Quién puede hablar de seguridad en 2024 sin mencionar el incidente de XZ Backdoor? Fue un ataque a la cadena de suministro bien pensado que aún atormenta los sueños de la comunidad del open source. Un mantenedor de confianza que dedicó más de dos años a establecer una buena relación con la comunidad introdujo una puerta trasera sofisticada en la librería XZ. Si Andres Freund no hubiera notado el retraso en el rendimiento que causaba, podría haber comprometido el acceso de Secure Shell (SSH) en innumerables sistemas.

En este informe, Red Hat reflexiona sobre la respuesta al open source y se toma un momento para destacar los riesgos inherentes y mostrar los puntos fuertes del modelo open source. El análisis rápido y colaborativo y el intercambio de información fueron posibles porque el código fuente y las interacciones eran públicos. El informe también analiza las barreras dentro de su propio proceso, como las pruebas de Fedora y la ingeniería de calidad de RHEL, que podrían haberlo detectado, aunque es imposible decirlo con certeza.  

El incidente de XZ Backdoor fue una llamada de atención. Este incidente tendrá efectos duraderos en los procesos de confianza y contribución en el open source. Los ataques a la cadena de suministro son cada vez más numerosos y sofisticados. Los atacantes buscan formas de atacar las herramientas comunes y el código compartido que los desarrolladores usan a diario, con la esperanza de causar problemas generalizados. Estos tipos de ataques muestran que los proveedores de software necesitan varias capas de protección: verificar automáticamente la seguridad de cualquier parte del código prediseñado que se use, tener una línea de ensamblaje segura para diseñar software e inspeccionar cuidadosamente cualquier pieza nueva antes de agregarla. Es bueno saber que Red Hat implementó varias comprobaciones que podría haber detectado el reciente problema de seguridad de XZ, lo que enfatiza que estas capas de seguridad realmente ayudan. La seguridad nunca será una actividad de una sola vez.

Problemas de la cadena de suministro

La cantidad cada vez mayor de ataques a la cadena de suministro de software (SSCA) y la dependencia de los componentes open source es casi increíble, pero estadísticamente cierto. Análisis de Black Duck presenta un panorama preocupante: un asombroso 97 % de las bases de código comerciales se basan en componentes open source. Si bien esto aumenta la velocidad de la innovación y el desarrollo, puede crear un objetivo extremadamente atractivo para los malintencionados con datos que muestran que no están dejando pasar ninguna oportunidad. El seguimiento de Red Hat de los SSCA informados públicamente reveló 89 incidentes en 2024, un aumento interanual sorprendente del 68 %. El Informe de Sonatype refleja esta tendencia inquietante. Las cadenas de suministro de software están cada vez más asediadas.

El compromiso de XZ Util y los atacantes norcoreanos que utilizaron esquemas elaborados de fraude laboral para obtener acceso interno son solo dos ejemplos de las tácticas en evolución que utilizan los malintencionados. El problema con esto es que para la mayoría de estos ataques se desconoce en gran medida el motivo, y una gran cantidad permanece sin un responsable identificado. Es difícil defenderse de manera efectiva cuando no comprendes completamente quién está atacando ni por qué. Sabemos que algunos atacantes quieren dinero o intentan espiar, pero desconocemos el objetivo de muchos de ellos. Esto complica toda la situación con las amenazas cibernéticas y es difícil de predecir o modelar. Apuntar a los desarrolladores y sus puntos de acceso tiene mucho sentido desde la perspectiva de un atacante, ya que ellos tienen las llaves del reino, pero también significa que el elemento humano de construir nuestro mundo digital es un objetivo principal.

Estos SSCA demuestran la explotación cada vez mayor de las dependencias críticas del open source por parte de atacantes anónimos calificados. No podemos simplemente dejar de usar el open source, ya que respalda el software moderno. Por lo tanto, necesitamos un cambio fundamental para avanzar. Necesitamos más protocolos de seguridad proactivos integrados en todo el ciclo de vida del desarrollo, no solo cuando reaccionamos a las filtraciones. Esto incluye una mejor verificación de las dependencias, prácticas sólidas de seguridad para los desarrolladores y, como se destacó en la respuesta XZ, un modelo de responsabilidad compartida en el que los proveedores, las comunidades y los usuarios invierten en proteger el ecosistema. La magnitud de nuestra dependencia exige una inversión proporcional en su seguridad. Todavía estamos tratando de ponernos al día con los adversarios que claramente están varios pasos por delante.

Oda a la  inteligencia artificial

En caso de que te lo hayas perdido, durante el último año, la  inteligencia artificia generativa (IA gen) se ha disparado, desde los chatbots hasta los asistentes de codificación y las herramientas creativas. El impulso no se está desacelerando, y se prevé que la inteligencia artificial generativa crezca a una tasa del 37 % cada año hasta 2030. Eso es alucinante, por decir lo menos. 

Sin embargo, como sucede con cualquier tecnología nueva y reluciente, hay una fase inicial en la que todos se concentran en lo que puede hacer. ¿Qué tan rápido puede funcionar? ¿Cuánto puede crear? ¿Cómo podría cambiar la forma en que hacemos casi todo?

Pero ahora que vemos el valor real, especialmente en sectores altamente regulados como la salud, las finanzas y el gobierno, donde los errores pueden tener implicaciones importantes, debemos comenzar a pensar  sobre las cosas serias. ¿Cómo mantenemos el uso de la inteligencia artificial seguro, protegido y confiable? ¿Podemos confiar en que no estropee las cosas ni filtre información privada? Los responsables de la toma de decisiones afirman que mantener la seguridad de los datos ya es la principal preocupación de las personas acerca de la inteligencia artificial este año. Eso tiene mucho sentido. No quieres que tu información personal se divulgue ni que la inteligencia artificial tome malas decisiones porque no se diseñó de manera segura. Como has leído anteriormente, ya tenemos algunos objetivos de alta visibilidad en el open source. 

Lo que aprecio es que no solo nos estamos uniendo a la ola de la inteligencia artificial; de hecho, estamos trabajando para descubrir cómo hacer que la inteligencia artificial sea segura y protegida. Sin embargo, no es una tarea fácil. 

Una de las primeras cosas que destaca Red Hat en Building Trust: Foundations of Security, Safety and Transparency in AI es la necesidad de diferenciar una vulnerabilidad de seguridad de la inteligencia artificial de un problema de seguridad en el comportamiento de la inteligencia artificial:

• Vulnerabilidad de seguridad: un hacker encuentra la manera de  de entrar en el sistema de inteligencia artificial.
• Problema de seguridad en el comportamiento: la misma inteligencia artificial dice algo inexacto, sesgado o incluso dañino, incluso si nadie la "infiltró".

Estos problemas deben abordarse de manera diferente, ya que corregir un error no es lo mismo que enseñar a la inteligencia artificial a no ser tóxica o inventar cosas. Necesitan reglas diferentes.

Es reconfortante ver que empresas como Red Hat, gobiernos como los de la Unión Europea y Estados Unidos, y varios grupos del sector se esfuerzan por resolver este problema. Están tratando de crear pautas, estándares y formas de rastrear estos diferentes riesgos de la inteligencia artificial. Quieren diseñar esta tecnología de manera responsable desde cero, capacitando a sus ingenieros y creando diseños seguros. Lo importante es que Red Hat no solo habla, sino que crea.

Entonces, ¿qué significa todo esto? El auge de la inteligencia artificial es emocionante y podría cambiar muchas cosas. Sin embargo, todo se reduce a la confianza. Al igual que con cualquier buena relación, la confianza es fundamental. Nuestra relación con la inteligencia artificial debe basarse en la confianza para que podamos aprovecharla al máximo, y eso es más que demostraciones llamativas. Se trata de trabajar arduamente entre bastidores para garantizar que la tecnología sea segura y fiable, y funcione como se espera. Parece que las personas adecuadas se centran en eso, lo cual es una buena noticia. Debemos ser cuidadosos y diseñar medidas de seguridad ahora, en lugar de intentar solucionar problemas graves más adelante. ¡Necesitamos personas que confíen en la inteligencia artificial para hacer esto!  

Entre bastidores, el ajetreo del Software Development Lifecycle (SDLC)

En 2024, Red Hat demostró que detrás de cada producto confiable hay mucho esfuerzo para asegurarse de que nada se pierda.  Nuestro enfoque va más allá del simple cumplimiento de los estándares de seguridad del National Institute of Standards and Technology (NIST).  Red Hat está desarrollando sus propios métodos únicos para ayudar a verificar que todo lo que diseñamos, incluidas las tecnologías de inteligencia artificial, sea confiable desde el principio.

El ciclo de vida de desarrollo de software seguro de Red Hat (RHSDLC), que proporciona nuestro plan para diseñar software centrado en la seguridad, ahora es más inteligente y está aún más alineado con los desafíos actuales de seguridad del mundo real. Pero no solo estamos simplemente cumpliendo los requisitos. Estamos creando nuestros propios estándares, como RHSDLC, para asegurarnos de que la cadena de suministro de software esté reforzada de principio a fin mediante la maduración del procedimiento de Aprobaciones operativas de seguridad (SOA). Esto incluye verificar las herramientas de terceros, automatizar las verificaciones y marcar los riesgos antes de que se conviertan en problemas. Es como prevenir el problema antes de que se agrave, en lugar de esperar a que se desborde. Nos dedicamos a potenciar la confianza de los clientes en nuestros productos mediante el análisis exhaustivo de los detalles de seguridad y la priorización de la confianza, la transparencia y la resiliencia.

Me encantó ver la estandarización de las revisiones de la arquitectura de seguridad (SAR) en el RHSDLC. Estas revisiones respaldan los principios de seguridad clásicos y probados, como "brinda acceso solo a lo que sea absolutamente necesario", "superpón tus defensas" y garantizar que la seguridad esté integrada en el diseño del producto desde el primer día. 

Por último, está RapiDAST. Si te gusta el open source o incluso el desarrollo de aplicaciones, esta herramienta es una herramienta valiosa. Es la herramienta dinámica de pruebas de seguridad de las aplicaciones de Red Hat y, en 2024, recibió algunas actualizaciones importantes. RapiDAST no solo se volvió más potente, sino también más fácil de usar. Por ejemplo, puede ofrecer soporte para las pruebas de los operadores de Kubernetes, una mejor automatización y una interfaz mucho más sencilla. Ahora, puede exportar los resultados directamente a Google Cloud Storage, lo que aumenta la eficiencia de la colaboración.

Red Hat está incorporando todo esto directamente en nuestros canales de CI/CD, los mismos sistemas que los desarrolladores usan a diario para diseñar y lanzar productos. Y para aquellos que confían en las herramientas, ya sean desarrolladores, profesionales de TI o usuarios finales que intentan mantener los sistemas seguros, el compromiso con el desarrollo centrado en la seguridad es realmente importante. En un mundo en el que las amenazas cibernéticas son constantes, es reconfortante saber que tu proveedor de software se centra en gran medida en la seguridad, desde la fase de diseño hasta las pruebas y el seguimiento de los componentes. Red Hat considera que la seguridad es una parte fundamental de la calidad, no solo una idea de último momento.

Hasta que nos volvamos a encontrar en 2025

El informe de este año es un recordatorio de que la seguridad siempre está cambiando. Debido a los cambios en la forma en que se informan los CVE, los riesgos constantes de la cadena de suministro, el impacto cada vez mayor de la inteligencia artificial y la priorización de los puntos vulnerables, los usuarios deben tener en cuenta muchas cosas.

Es muy importante contar con informes transparentes como este. Nos ayudan a todos, desde los desarrolladores hasta los equipos de TI y los lectores curiosos como yo, a ver lo que sucede, comprender los desafíos y tomar decisiones más informadas. Desde mi punto de vista,  no se trata solo de prevenir problemas; la forma en que respondemos a ellos es igual de importante. ¿La forma en que la comunidad del open source se unió durante incidentes como el XZ Backdoor? Ese es el poder de la colaboración en acción.

Lee la versión completa: Red Hat Product Security Risk Report 2024.