Permítanme ser claro desde el principio: este no es un argumento en contra de la actualización. El progreso importa. Las nuevas capacidades son importantes. Las mejoras en seguridad son importantes. Lo peligroso no es actualizar, sino actualizar transmitiendo a la línea de tiempo de otra persona, esperando que la velocidad sea igual a la seguridad.
Esta distinción es importante, ya que acontecimientos recientes han demostrado lo que sucede cuando la elección, la visibilidad y el juicio desaparecen silenciosamente.
Cofundador y director de innovación de Origina.
Cuando Airbus puso en tierra aviones de la familia A320 por un mal funcionamiento del control de vuelo relacionado con la radiación solar, parecía un problema de aviación específico. No lo fue. Fue un recordatorio de que incluso las industrias basadas en una ingeniería de seguridad obsesiva y un control de cambios pueden verse atrapadas en dependencias críticas expuestas por los riesgos del software.
Y si esto pudiera suceder en la aviación, con sus despidos, certificaciones y disciplinas, debería hacer reflexionar a todos los CIO.
Hemos visto el mismo patrón en otros lugares. Actualización de Crowdstrike que dejó inutilizables millones de máquinas con Windows. Interrupciones de Cloudflare que se extendieron por gran parte de Internet.
En cada caso, un cambio o falla introducido muy arriba desencadena consecuencias inmediatas aguas abajo. Pero el problema más profundo no fueron sólo las actualizaciones. Era la dependencia y las suposiciones que la acompañaban.
Dependencias ocultas y riesgos heredados
En el caso de Airbus, los aviones modernos de vuelo por cable dependen naturalmente de sistemas de software estrechamente integrados. Cuando estos sistemas encontraban un modo de falla contra el cual no estaban lo suficientemente preparados, no había una vía de escape operativa fácil.
El avión fue puesto en tierra no sólo porque los ingenieros fueron descuidados, sino también porque se exigía seguridad y se requería un cambio de certeza antes de poder reanudar el vuelo. Cloudflare cuenta una historia similar a escala de Internet.
Cloudflare ejecuta una operación sólida y brinda servicios críticos. Ellos no son los villanos aquí. Pero una gran parte de Internet ahora depende de un pequeño número de proveedores de infraestructura compartida para DNS, enrutamiento, seguridad y disponibilidad.
Las organizaciones que diseñan sus servicios para depender completamente de esas plataformas heredan sus modos de falla. Cuando un servicio clave falla, a menudo no hay una degradación elegante, solo una parada muy brusca.
Ésta es la incómoda realidad del sector moderno de TI. La dependencia no es gratuita. Cuando se subcontrata la energía, el control se diluye. A menos que los sistemas se diseñen intencionalmente teniendo en cuenta la resiliencia, la diversidad y las alternativas, las organizaciones absorben silenciosamente riesgos que no comprenden completamente.
Los líderes tecnológicos deben tener claro de qué dependen, cómo fallan esas dependencias y qué sucede cuando lo hacen.
Perturbaciones que cruzan la línea hacia la seguridad
Aquí es donde la disrupción deja de ser un inconveniente y se convierte en un problema de seguridad. Los hospitales, los servicios de emergencia, los servicios públicos y los mercados financieros operan cada vez más con capas de software unidas durante décadas.
Las integraciones se acumulan, las responsabilidades se acumulan y nadie tiene una visibilidad completa del impacto de un extremo a otro. En ese entorno, incluso los cambios “rutinarios” pueden conllevar riesgos reales.
Una actualización del proveedor o una interrupción externa pueden retrasar el acceso a los registros de los pacientes, alterar los sistemas de despacho o interrumpir los servicios en los que las personas confían en momentos críticos. La aviación supone que el cambio es peligroso hasta que se demuestre lo contrario. Muchos sectores digitales todavía asumen que el cambio es seguro a menos que algo se rompa.
Sin embargo, la narrativa dominante permanece sin cambios: manténgase actualizado, actúe rápido, confíe en el proveedor.
Esa narrativa se ve reforzada por incentivos. Los vendedores son recompensados por la velocidad de las actualizaciones. Depende del modelo de soporte, los ingresos y la estrategia de producto. El impacto operativo posterior, la reexaminación de los casos de seguridad y la recapacitación del personal, recae enteramente en el cliente.
Ahí es donde entra en juego la codicia. No como malicia, sino como indiferencia incorporada al modelo de negocio. Las personas que presionan por el cambio no sienten las consecuencias cuando las cosas van mal.
La elección, no la obligación, debería impulsar las actualizaciones
La actualización es opcional. Sólo deberían ocurrir cuando una organización quiere que se le entreguen nuevas capacidades, porque un proveedor declara que una versión “no es compatible”. El software no tiene una fecha de caducidad.
Existe la peligrosa creencia en las prácticas de seguridad modernas de que una vez que se aplica el último parche, el riesgo se ha abordado y trabajado en él. En la práctica, la aplicación de parches es una respuesta potencial al riesgo y, a veces, al error.
Un parche puede reducir la exposición, pero también puede introducir inestabilidad, nuevas vulnerabilidades o modos de falla completamente nuevos.
La forma más fuerte de defensa no es la velocidad, sino la comprensión. Saber a qué está expuesto, cómo se manifiesta esa exposición en su entorno y qué controles o mitigaciones realmente reducen el riesgo en la práctica. Esto requiere evidencia, no conjeturas. A menudo, colocar parches se convierte en un ritual más que en una decisión.
Las presiones regulatorias pueden incluso reforzar involuntariamente este comportamiento. Los marcos diseñados para mejorar la resiliencia a veces se reducen a “aplicar la última solución y seguir adelante”. El consentimiento se convierte en una casilla de verificación.
El aseguramiento se vuelve operativo. Un sistema recién parcheado aún no se comprende bien, se monitorea mal y se defiende mal.
El riesgo debe gestionarse deliberadamente mediante controles que tengan sentido para su arquitectura y modelo operativo. A veces eso incluye actualizaciones. A menudo significa aislar, compensar, endurecer u observar. La evidencia, no el miedo o la presión de los proveedores, debe impulsar la decisión.
Es posible que los CIO no puedan cambiar los incentivos de los proveedores, pero sí pueden cambiar sus propias actitudes. La actualización que realmente necesita la industria no es una nueva versión de software. Es un cambio de mentalidad, del cumplimiento a la comprensión, de la velocidad a la sustancia y de lo “parcheado” a lo “resiliente”. Porque el aceite de serpiente y los sistemas críticos aún no se mezclan.
Hemos presentado los mejores cursos de ciberseguridad en línea.
Este artículo se creó como parte del canal Expert Insights de TechRadarPro, donde destacamos las mejores y más brillantes mentes de la industria tecnológica actual. Las opiniones expresadas aquí son las del autor y no necesariamente las de TechRadarPro o Future plc. Si está interesado en contribuir, obtenga más información aquí:
