El jefe saliente de la CISA, Jen Easterly, comparó recientemente el desarrollo de software seguro con la seguridad automotriz, argumentando que estábamos en un punto de inflexión similar a 1965 cuando Ralph Nader publicó el libro Inseguro a cualquier velocidad. El libro provocó la indignación pública sobre la seguridad vial, lo que ayudó a fomentar la adopción generalizada de medidas innovadoras de seguridad de los vehículos.
Después de leer las publicaciones de Jen sobre el tema, la pregunta abierta sigue siendo: ¿estamos realmente en un punto en el que podemos usar la indignación contra el riesgo de software inseguro para impulsar un cambio significativo? Veamos si podemos ver objetivamente esta pregunta y determinar qué debe suceder en 2025 junto con la presión pública continua. Para los compradores de software de CISO y TI, además de su mejora cotidiana, exigiendo que el software que compre es seguro, y sus proveedores se comprometen a asegurar según los principios de diseño, ¿en qué debe centrarse en 2025 para ayudar a mover la aguja?
Muéstrame el incentivo y te mostraré el resultado
La comparación entre el riesgo de automóvil en la década de 1960 y el riesgo de software en la era moderna es evidente. La innovación de tecnología rápida ha resultado en que los productos inseguros se utilicen diariamente. El mundo del software, al igual que la industria automotriz en los años 60, prioriza la velocidad de lanzamiento, las características y la funcionalidad, y empuja los límites y límites del uso seguro, todo en nombre de vender más productos e innovar nuevas ofertas más rápido que sus competidores. Los desarrolladores de software enfrentan una presión continua para liberar productos lo más rápido posible, a menudo a expensas de la seguridad del código. Se percibe que la seguridad ralentiza el ciclo de desarrollo y a menudo es un atornillado después del hecho.
Para citar al gran Charlie Munger, “Muéstrame el incentivo y te mostraré el resultado”. Los desarrolladores de software no escriben código seguro porque no tienen incentivos para hacerlo. Para empeorar las cosas, las empresas para las que trabajan tienen muy pocos incentivos para concentrarse en la seguridad de sus productos. Los compradores de IT y CISO han estado comprando código inseguro durante el tiempo que haya existido.
La industria del automóvil tenía un problema similar: los autos comprados hasta ese punto no se compraron porque estaban a salvo. La gente no iba a los concesionarios de automóviles (¿tenían concesionarios en los años 60?) Y hacía preguntas sobre la clasificación de seguridad del vehículo o si tenía una columna de dirección colapsable y un tablero acolchado. Compraron vehículos según el aspecto, el estilo, la velocidad máxima y la aceleración, y lo más importante, la alegría que recibieron al operar el nuevo modo de transporte. La seguridad no era una característica requerida y, por lo tanto, era una ocurrencia tardía. Esto es casi idéntico a cómo hemos construido y comprado software hasta hoy. Priorizamos y compramos en función del valor que obtenemos del software, con poco o ningún interés en lo seguro que es.
No hay ningún incentivo para priorizar la seguridad cuando eso no es lo que los compradores exigen. La industria del automóvil requirió el reconocimiento del consumidor del problema, lo que resultó en una protesta por mejores estándares de seguridad antes de que los fabricantes de automóviles “perderan su tiempo” en las características de seguridad del producto.
No veremos un momento de ‘inseguro a velocidad de software’ en 2025
La industria del software no ha aprendido del pasado de la industria del automóvil por algunas razones clave. En primer lugar, cuando entras en un accidente automovilístico, hay una posibilidad no trivial de la pérdida de vidas. Las personas mueren cuando no hay características de seguridad presentes en sus automóviles, e incluso un pequeño número de muertes es inaceptable para el público. Las consecuencias de un accidente automovilístico fueron inmediatas y visceral y dejaron una impresión duradera en las mentes de aquellos que estaban en uno o vieron uno. El software es diferente. Cuando el software en su televisor, por ejemplo, se rompe, simplemente lo reinicia.
Hasta hace poco, en el peor de los casos, la gran mayoría de los defectos de software dieron como resultado el compromiso de una entidad corporativa anónima con poca o ninguna relación con la población. Claro, puede haber una posibilidad muy pequeña de que sus cuentas se vieran comprometidas, el dinero directamente robado de ellas o fraude perpetrado contra ellos, pero la mayoría del mundo de los consumidores cree que “eso no me pasará”, y por la ley de Grandes números, probablemente tengan razón. Y si lo hace, están asegurados, cubiertos por pérdida y, la mayoría de las veces, solo sufren de tener que saltar a través de muchos aros para recuperar lo que han perdido.
Debido a esta actitud de laissez-faire hacia los riesgos, es mucho más fácil para la industria del software ignorar el problema, cancelándolo como un costo de hacer negocios. En otras palabras, no hay demanda de cambio.
Además de la diferencia de riesgo entre automóviles y vulnerabilidades de software, la complejidad del panorama de software eclipsa el del automóvil de la década de 1960. Si pudiéramos implementar rápidamente de cuatro a seis procesos de software y arreglar todo el registro de riesgos de software global, prometo que lo haríamos. El problema es mucho más complejo y difícil de solucionar que los menos de 10 grandes fabricantes de automóviles de la década de 1960 tuvieron que resolver. Si solo existieran 10 empresas de desarrollo de software hoy en día, sería más fácil exigir el cambio.
Sin embargo, el software está literalmente en todo lo que tocamos. Desde dispositivos IoT hasta electrodomésticos hasta juguetes para niños: el software ha comido el mundo, lo que hace que asegurar ese software sea una tarea mucho más difícil de completar. Los constructores de automóviles tuvieron que hacer algunos cambios en sus productos y estaban listos para vender. No tuvieron que cambiar todo el mundo de fabricación para cada producto disponible para el público para avanzar hacia la seguridad. Aquí es donde la comparación se queda corta.
SBD y el impulso para asegurar nuestro software
Este increíble nivel de complejidad plantea la cuestión de quién es responsable de solucionar el problema. En mayo de 2024, hubo un gran impulso para que los proveedores de software firmen la compromiso de “Secure by Design (SBD)”. Actualmente, más de 250 empresas se han comprometido a seguir los principios seguros por diseño y garantizar que su software se cree con estándares de alta seguridad en cada paso del proceso de desarrollo.
Me encanta el compromiso de diseño Secure By, pero 250 compañías son una caída en el cubo; Según CyberDB, hay más de 3.500 compañías de seguridad cibernética solas. Estas son solo las empresas que están trabajando para asegurar nuestra vida cotidiana. 250 firmas es un simple error en comparación con el número de empresas en los Estados Unidos. Algunas investigaciones reclaman más de 33 millones de empresas solo en 2024 en los Estados Unidos, la mayor parte de las cuales son pequeñas empresas. El problema difícil es llegar al punto de inflexión requerido para las empresas de los EE. UU., Y el mundo, para darse cuenta de que el riesgo es demasiado alto y la demanda de cambio de sus proveedores de software.
La investigación de la Escuela de Comunicación Annenberg de la Universidad de Pensilvania y la Escuela de Ingeniería y Ciencias Aplicadas muestra que aproximadamente el 25% de una población debe alcanzar el punto de inflexión para un cambio social a gran escala. Ni siquiera estamos cerca.
En lo que creo que deberíamos estar pensando no es cómo solucionamos los problemas de seguridad del código mejor o más rápido, sino en cómo llegamos al punto de inflexión donde cambia la estructura de incentivos y el software del mundo comienza a solucionarse. Si lo pensamos de esta manera, rápidamente vemos que el cambio solo se producirá cuando se implementen una tierra de la demanda del comprador y las regulaciones obligatorias del gobierno.
Arreglar el código seguro como un movimiento en 2025
Dada la perspectiva negativa y las expectativas templadas que he presentado, probablemente te arrepiente de haber leído este artículo. Me encantaría que te vayas con la idea opuesta en tu cerebro y tal vez te acerques a 2025 como el año en que la industria del software puede acercarte al punto de inflexión para construir software de manera más segura.
Similar a los temas discutidos en Inseguro a cualquier velocidadlas empresas que escriban software de cualquier tipo continuarán retrocediendo la propiedad del problema e intentarán desviar o ignorar la responsabilidad de cualquier problema de salud, seguridad y seguridad que aparezcan. A medida que el software se utiliza cada vez más en situaciones de vida y muerte, como atención médica, automotriz, comunicaciones de emergencia, etc. La demanda de negocios y compradores de menos riesgo aumentará.
Si somos lo suficientemente fuertes, en algún momento, la responsabilidad del software cambiará a aquellos que están construyendo el producto, y cuando lo haga, las estructuras de incentivos cambiarán, y las empresas prestarán mucha más atención a los riesgos para sus propios negocios. Lamentablemente, no creo que lleguemos al punto en que las empresas se preocupan lo suficiente por la seguridad del código para priorizarlo solo porque es lo correcto para sus clientes. En cambio, para lograr nuestros objetivos, tenemos que hacer que sea imperativo para la salud y el éxito de su negocio escribir un código más seguro, y la única forma de hacerlo es ser muy fuerte y la demanda de cambio.
Entonces, ¿qué puede hacer como comprador de software CISO y TI en 2025 para ayudar a mover la aguja y crecer hacia el punto de inflexión de código seguro? En primer lugar, necesitamos que cada uno de ustedes sea educado sobre los riesgos de los defectos de software y ayude a articular estos problemas a los desarrolladores de software que usted compra o licencia. Los usuarios y los desarrolladores deben ser más conscientes de la importancia de la seguridad y las posibles consecuencias de las vulnerabilidades de software tanto para la compañía que vende el software como para las personas que lo usan.
En segundo lugar, y probablemente más crítico, debe impulsar a sus representantes y agencias gubernamentales a ser más educados sobre el tema y desarrollar regulaciones y estándares más fuertes para la creación de software seguro. El automóvil nunca se habría vuelto más seguro si las agencias gubernamentales no hubieran intervenido y colocado regulaciones y estándares en su lugar que exigían que los vehículos motorizados tuvieran al menos un nivel mínimo de seguridad. Tenemos que tener regulaciones en el mundo del software que colocen el punto de inflexión al alcance, y depende de los compradores y usuarios de software empujar al gobierno en este frente. La responsabilidad debe volver al constructor, que solo sucede cuando el gobierno se involucra. Se necesitará un ejército, pero si gritamos y gritamos lo suficientemente fuerte con el tiempo, compramos solo un software que se escribe de forma segura y hacemos un nivel de ruido lo suficientemente significativo, podemos continuar marchando lentamente hacia la mejora.
La lenta marcha hacia ‘asegurar a todas las velocidades’
Precisamente como Inseguro a cualquier velocidad fue una llamada de atención para la industria automotriz, una creciente conciencia de los problemas de seguridad del software y el impacto de las vulnerabilidades hacia la seguridad y la salud humana está generando presión para un cálculo similar en el mundo del software. Debemos seguir moviéndonos hacia un Asegurar Todo Velocidad Mundo de desarrollo de software.
No creo que veamos el punto de inflexión en 2025, pero cada uno de nosotros debe abordar este cambio con un grito de rally uniforme para construir el volumen requerido para ser escuchado en los niveles más altos. Gracias, Jen Easterly y el equipo de CISA, por el trabajo de tierra que ha realizado para este movimiento, y espero que 2025 sea el año en que trabajaremos juntos para dar pasos diarios hacia el éxito.