¿Cuándo es "demasiada información"?

Joao Correia

14 de abril de 2023 - Evangelista técnico

Seguro que te has dado cuenta de la tendencia: es difícil pasarla por alto si has estado atento. Los registros de cambios son cada vez más escasos, sobre todo en el último año. A veces, un simple "errores corregidos" o "mejoras de rendimiento" es todo lo que se ofrece para describir qué se ha hecho exactamente entre una versión y otra. Hay algunas razones de peso para este cambio, así como varios argumentos igualmente interesantes.

Atrás quedaron los días en los que había más párrafos de texto describiendo un cambio de código que líneas de código para dicho cambio. Los changelogs eran piezas de texto cautivadoras, elaboradas con una caligrafía capaz de hacer que algunos autores literarios se replantearan sus opciones profesionales. Tiempos felices.

Pero esos días han quedado atrás. Si nos fijamos en el registro de cambios de cualquier actualización de Windows, tendremos que indagar mucho para ver qué es exactamente lo que estaba mal y requería una corrección, y qué se hizo para solucionar el problema. Hubo muchas reacciones en contra (muy ruidosas) cuando esto entró en vigor hace unos años, pero Microsoft no cedió, y la política sigue en vigor hoy en día, afectando tanto a los productos de consumo como a los profesionales.

Uno podría pensar que se trata simplemente de Microsoft siendo Microsoft y que esto es parte del manual de las "grandes corporaciones". Pero si miramos al otro lado del pasillo, por ejemplo, al kernel de Linux, vemos que ocurre lo mismo. Por supuesto, puedes seguir todas las discusiones, comentarios e hilos en múltiples foros sobre errores, vulnerabilidades y nuevas características del Kernel, pero cuando examinas el registro de cambios en sí, te costará identificar las correcciones de seguridad específicas que se abordan en una versión determinada.

La seguridad a través de la oscuridad no suele durar mucho, pero es una línea muy fina la que los desarrolladores están enhebrando aquí.

Los problemas de seguridad

Los defensores de reducir la cantidad de información en los changelogs suelen argumentar que son (sin ningún orden en particular):

Reducir la información de que disponen los malos actores para identificar nuevas vulnerabilidades presentes en versiones anteriores ya desplegadas (y, por tanto, vulnerables);
Proporcionar un pequeño margen de tiempo para que los "buenos" parcheen sus sistemas antes de que los hackers empiecen a intentar vulnerarlos, ya que el tiempo entre la divulgación de una vulnerabilidad y la aparición de exploits "in the wild" se está acortando a meros minutos;
Afirmando que los usuarios no necesitan conocer todos los pequeños detalles, ya que se supone que deben adoptar la última versión lo antes posible; es de ciberseguridad 101 parchear siempre.

Sin embargo, hay argumentos igual de convincentes en el otro lado:

Los malos actores tienen los recursos, los conocimientos y los incentivos para comparar las diferencias reales de código entre versiones y no necesitan realmente los registros de cambios. Esto se agrava aún más por el hecho de que los bots de IA ahora pueden proporcionar asistencia en esta tarea, trivializando el nivel de conocimiento requerido.
Ocultar estos detalles hace más difícil, o incluso imposible, priorizar lo que hay que parchear, ya que no se dispone de una medida de riesgo comparable para evaluar.
Tomar siempre la última versión no siempre es del todo seguro, ya que ningún parche ha causado nunca consecuencias no deseadas, ¿verdad?

Las discusiones sobre este tema pueden acalorarse rápidamente, y es fácil perder el norte y caer en argumentos del tipo "yo sé más" que, en última instancia, son improductivos. Sin embargo, estos debates ponen de manifiesto un problema que tiene efectos tangibles en la seguridad. Es innegable que hay que mantener siempre los sistemas con la versión más actualizada de cualquier software. Pero sucesos comunes como la pérdida de soporte de hardware o los cambios en el alcance, los requisitos o la disponibilidad pueden hacer que eso sea imposible de conseguir. En ese caso, la falta de información obstaculizará mucho más que ayudar, ya que no tienes forma de identificar alguna nueva vulnerabilidad a la que ahora estás expuesto - hasta que algo malo suceda.

No identificar explícitamente los problemas de seguridad como tales también significa que no solicitarás (o retrasarás la solicitud) de un CVE para el problema. En un campo como el de la ciberseguridad, que se centra casi exclusivamente en el seguimiento, la gestión, el escaneado y el parcheado de los CVE, tener problemas de seguridad que eluden todas las herramientas y la supervisión es, como mínimo, discutible.

Hacia dónde vamos

Puede llegar un momento en que los registros de cambios pierdan todo su valor.

En las compilaciones de Windows Server Insider, ni siquiera hay una - y la ironía aquí es que estás ejecutando una versión beta haciendo el trabajo de prueba de forma gratuita y sin embargo no tienes manera de saber lo que se supone que estás probando. Esto podría convertirse en la norma y no en la excepción. Las versiones de consumo del sistema operativo ya no proporcionan un acceso fácil a la descripción del parche, que ahora sólo contiene una mención genérica de "errores corregidos". Hay que indagar más para encontrar más detalles, e incluso eso está llegando gradualmente a un público más reducido.

De nuevo, es importante subrayar que esto no es algo ligado sólo al software de código cerrado. El mundo del código abierto también está adoptando este enfoque como válido. De hecho, esto crea una situación peculiar para los proyectos de código abierto. Por un lado, el código fuente es de libre acceso, se informa de los errores y se desea incentivar a los desarrolladores para que se dediquen a corregir errores y añadir funciones. Pero, por otro lado, se oculta a propósito información que ayudaría en esas tareas. Algo no cuadra aquí.

Hay una lista muy larga de argumentos en torno a este debate que puedes encontrar en este hilodonde algunos líderes del Kernel discuten los méritos del enfoque que han elegido para esta cuestión, así como las extensas críticas que la acompañan.

El impacto de la IA

La IA evoluciona rápidamente y es difícil mantenerse al día de todas las novedades. Pero una característica bien establecida de los bots de IA actuales es su capacidad para ayudarte a entender y encontrar problemas en el código. Es trivial pegar un bloque de código antes y después en la interfaz de chat de un bot de IA y pedirle que "encuentre los fallos que se solucionaron con esos cambios de código" y "cómo podrían explotarse esos fallos".

El software de código abierto sentirá este impacto mucho más rápido que el de código cerrado, ya que la accesibilidad jugará en su contra en este sentido. Comprobar las diferencias entre distintas versiones de software para identificar vulnerabilidades de seguridad ya era algo a lo que se dedicaban los actores de amenazas, y ahora el listón se ha bajado considerablemente. Pero todavía no basta con que los buenos tengan la disponibilidad y los recursos para hacerlo ellos mismos: también tienen otras preocupaciones, en lugar de centrarse únicamente en encontrar y explotar fallos.

La "oscuridad" de la "seguridad a través de la oscuridad" está a punto de quedar bastante bien iluminada.

Balas mágicas o falta de ellas

Este problema no tiene solución mágica. Hasta ahora se ha demostrado intratable y, por increíble que parezca, todo el mundo cree que su propio enfoque es el mejor, de ahí que lo hagan de esa manera. Puede ser tan extremo como tener tres aplicaciones de software diferentes en un sistema, todas con enfoques distintos: el sistema operativo, el servidor web y la base de datos. Al final, alguien paga el precio de este enfoque dispar a la hora de compartir (u ocultar) información, y supone un obstáculo más que los profesionales de TI tienen que superar para hacer su trabajo con eficacia.

En última instancia, el debate en torno a los registros de cambios y la cantidad de información que se comparte en ellos es complejo y polifacético. A medida que la tecnología y la IA sigan evolucionando, es posible que el sector deba reevaluar su enfoque de la seguridad y el intercambio de información para encontrar un equilibrio entre transparencia y protección.