Hace ya algo más de un mes hablé en este artículo de todo lo que había alrededor de la vulnerabilidad en Log4J, una biblioteca ampliamente utilizada de software libre que tiene todas las papeletas de volverse un problema presente y sobre todo futuro para buena parte de la industria informática.
El tema era, como comentaba en ese momento, que estábamos ante una nueva vulnerabilidad surgida en un desarrollo que estaba siendo gestionado por unas pocas personas… de forma totalmente filantrópica. En sus ratos libres y sin cobrar nada, vaya.
Claro, cuando las cosas van bien, todos felices.
El problema es que al surgir este 0 Day, de pronto millones de proyectos y desarrolladores que usan Log4j en sus propios proyectos corrieron a meter presión al equipo de Log4J. Y estos, como cabría esperar, se vieron totalmente desbordados.
Cuando surge una vulnerabilidad en un software propietario, por el que hemos pagado, es normal que el usuario se queje (tiene derecho a ello), y la compañía que tiene detrás se haga cargo.
Pero cuando surge una vulnerabilidad en un software open source, que no genera beneficio alguno, y cuyos desarrolladores van implementando cambios en sus ratos libres, ¿qué podemos hacer?
E iría aún mas lejos: ¿Tiene sentido entonces que prácticamente cualquier desarrollo corporativo parta de bibliotecas abiertas como Log4J?
Sobre esto precisamente trataba el artículo en cuestión.
Me parafraseo:
¿Se debería por ley considerar el software libre una amenaza para la seguridad nacional, y por tanto prohibir su uso, por ejemplo, en infraestructuras críticas?
El problema de esta postura es que, por cómo se entiende hoy en día el desarrollo informático, negar una parte tan core probablemente nos haga retroceder varias décadas a nivel de usabilidad e interconectividad de sistemas.
Algo que, ya de por sí, entraña también riesgos y un coste económico y social más que significativo.
¿Se debería entonces forzar a que las grandes compañías que hacen uso del software libre estén obligadas a financiarlo? Pues se me antoja una buena salida.
Al poco de publicar aquella pieza surgió otra noticia muy relacionada.
La de color.js, otro script ampliamente usados en la industria (alrededor de 15 millones de descargas semanales) cuya nueva versión, de pronto, generaba una sobresaturación del procesador al intentar ejecutar en un bucle infinito la impresión en pantalla de caracteres aleatorios (EN).
A ojos de cualquier desarrollador parecía un error más. A fin de cuentas, todos somos humanos.
El tema es que Marak Squires, el desarrollador detrás de este script, lo había hecho queriendo, tras varios meses exigiendo que aunque fuera alguna de las múltiples compañías (algunas de ellas multinacionales) que hacían uso de sus scripts le diera trabajo.
Por supuesto, dejando de lado el factor psiquiátrico de esta persona (denunció públicamente que estaba viviendo en la calle al no conseguir trabajo de desarrollador y haberse quemado su casa, obviando que ese incendio accidental se debía al uso de químicos con los que pretendía crear una bomba (EN), motivo por el cual estuvo arrestado), situaciones como esta, en la que una actualización de una API rompe sistemas de nuestra organización se solucionan de una manera sencilla:
No actualizando a nuevas versiones tan pronto estas salen.
El problema, como te habrás podido imaginar, es que esto genera un bucle de retroalimentación negativa, ya que si bien es verdad que cualquier actualización de cualquier componente informático supone, de facto, asumir un riesgo… el no actualizarlo, y por tanto trabajar en un entorno obsoleto, también conlleva asumir otro tipo de riesgos.
Y en estos casos, la duda que puede surgirle a cualquier administrador de sistemas es qué tiempo, y bajo qué condicionantes, debe esperar a la hora de mantener los sistemas actualizados para que el riesgo de que una potencial nueva versión rompa el sistema junto al riesgo a estar expuestos a potenciales fallos de seguridad explotables sea el mínimo posible.
La solución, por supuesto, no es única.
Para algunas organizaciones, y en herramientas en producción core para el negocio, pasará por esos 6 meses típicos de delay. Para otras, un mes.
Habrá actualizaciones que corra más prisa actualizar (mayor riesgo de seguridad frente al riesgo de ruptura), habrá otras que requieran menos importancia y pueda por tanto demorarse más (mayor riesgo de ruptura vs el riesgo de seguridad).
El tiempo justo y necesario para que «otros» sirvan de conejillos de indias… y que nuestras herramientas estén lo antes posible parcheadas.
El Santo Grial, vaya.
Con lo difícil que es precisar esto, en un entorno cada vez más dependiente de software de terceros.
En CyberBrainers ayudamos a empresas y usuarios a prevenir, monitorizar y minimizar los daños de un ataque informático o una crisis reputacional. Si estás en esta situación, o si quieres evitar estarlo el día de mañana, escríbenos y te preparamos una serie de acciones para remediarlo.
Monitorización y escucha activa
Ponemos nuestras máquinas a escuchar para identificar potenciales fugas de información, campañas de fraude/extorsión y usurpación de identidad que estén en activo, y/o datos expuestos de ti o de tu organización.
Planes de autoridad y Presencia Digital
Ayudamos a organizaciones y particulares a definir la estrategia e implementar acciones digitales que mitiguen los posibles daños reputacionales que pueda sufrir en el futuro.
Gestión de crisis reputacionales
Cuando el mal ya está hecho, establecemos un calendario de acciones para reducir su duración e impacto, y que la organización y/o persona pueda volver a la normalidad lo antes posible.
Pablo F. Iglesias es un empresario e inversor español especializado en la Consultoría de Presencia Digital y Reputación Online, fundador de la agencia de reputación CyberBrainers, de la startup EliminamosContenido, y del sello editorial Ediciones PY. Además, es un reconocido escritor con su saga de ciencia ficción "25+1 Relatos Distópicos" y "Historias Conectadas", y la colección de fantasía épica "Memorias de Árganon". Dedica sus "horas libres" a concienciar sobre las oportunidades y riesgos del entorno digital, ya sea en charlas, talleres, sus escritos en blogs y las colaboraciones con medios de comunicación.
