Una falla de día cero en su aplicación de software empresarial preferida permitió que atacantes ingresaran a su red y comprometieran datos confidenciales. Va a costar mucho solucionarlo incluso antes de llegar a las multas regulatorias y las demandas de los clientes, y la aplicación ni siquiera es suya. ¿Quién debería pagar?

Probablemente no sea la empresa que le vendió el software. Sus acuerdos de licencia de usuario final (EULA) normalmente limitan su responsabilidad. La mayoría de nosotros no los leemos porque son demasiado largo y demasiado complejo.

En los últimos meses, las demandas para cambiar esta situación han sido cada vez más fuertes, llegando a los niveles más altos del gobierno. En febrero, Jen Easterly, directora de la Agencia de Seguridad de Infraestructura y Ciberseguridad, explícitamente llamado por responsabilidad del proveedor durante un discurso en la Universidad Carnegie Mellon.

El mundo ha llegado a aceptar la tecnología insegura como la regla cuando debería ser la excepción, afirmó. "Los fabricantes de tecnología deben hacerse cargo de los resultados de seguridad para sus clientes".

Easterly pidió al gobierno que publicara una legislación que impidiera que las empresas de tecnología renunciaran a su responsabilidad por contrato. La administración Biden Estrategia Nacional de Ciberseguridad, lanzado este marzo, se hizo eco del llamamiento a favor de esta ley.

Un debate de larga data

Los gobiernos han reflexionado sobre este problema antes. La Cámara de los Lores del Reino Unido recomendado responsabilizar a los proveedores de software en 2007, incluso después de escuchar argumentos contra la responsabilidad del proveedor por parte de los desarrolladores de software por diversos motivos.

Estas protestas incluyeron la enorme complejidad de los entornos de software modernos. Muchos tipos de software coexisten juntos, señaló el desarrollador, añadiendo que pueden interactuar entre sí de formas extrañas. ¿Podemos esperar razonablemente que un proveedor de software prediga cada caso límite de interoperabilidad?

Otra preocupación era la posibilidad de que se produjeran errores por parte del usuario. ¿Qué pasa si un usuario configura mal el software, haciendo que éste o un componente con el que interactúa sea inseguro debido a una interfaz de usuario deficiente? ¿Qué pasa si el usuario no aplicó un parche por una razón legítima, como una restricción regulatoria? ¿Existe una responsabilidad parcial por una mala configuración y cómo podría decidirse?

Existen otros desafíos para las empresas que intentan cumplir con las cuestiones de responsabilidad del proveedor. Gran parte del software no se crea en el vacío; Se basa en bibliotecas de terceros (a menudo publicadas bajo licencias de código abierto) que pueden contener sus propios problemas de seguridad. Log4Shell, el error en la biblioteca de registro Java Log4J que afectó la ciberseguridad de miles de empresas sin ser detectado desde 2013, es un excelente ejemplo. ¿Quién paga si el software que usted creó utiliza un componente inseguro de terceros?

Su visión del software debe extenderse más allá de sus propios límites, sugirió Easterly. Se hizo eco del llamado de la Casa Blanca para una Lista de Materiales de Software (SBOM) para definir la procedencia del software ensamblado.

¿Cómo es el software seguro?

Responsabilizar a los proveedores de un producto complejo plantea otras cuestiones, como por ejemplo cómo definimos la seguridad del software. Las definiciones se encuentran a lo largo de un continuo, que va desde lo inadecuado (probar algunas pruebas básicas de software estático) hasta lo poco práctico (verificación formal). Este último compara el funcionamiento del software con un modelo matemático abstracto. Estos sistemas existen, pero son para aplicaciones especializadas e implican una gran cantidad de codificación.

La definición más realista se sitúa en algún punto intermedio, con pruebas documentadas de las mejores prácticas que integran la seguridad directamente en la producción de software desde la fase de diseño en adelante. Marco de desarrollo de software seguro del NIST, que recomienda la NCS, articula muchos de ellos.

Otra recomendación de Easterly fue el uso de lenguajes seguros para la memoria. Muchos fallos de seguridad del software moderno tienen su origen en el mal uso de la memoria. Como lenguajes rápidos y de bajo nivel que requieren que los programadores administren la memoria ellos mismos, C y C++ son notablemente débiles aquí. Go, Python y Java son lenguajes interpretados de nivel superior que manejan la memoria en nombre del programador. Un lenguaje más reciente, Rust de Mozilla, también es seguro para la memoria y es el primer lenguaje distinto de C y ensamblador compatible con el kernel de Linux.

Easterly también pidió políticas transparentes de divulgación de vulnerabilidades entre los proveedores de software. Con demasiada frecuencia, hacen todo lo posible para mantener discretos los errores de seguridad, ignorando o, a veces, desalentando los informes de errores de seguridad. Dijo que una relación más abierta y colaborativa con los investigadores de ciberseguridad ayudaría a cerrar las brechas de software.

Pasos intermedios

Mientras espera al Congreso, la Casa Blanca depende de la Orden ejecutiva sobre la mejora de la ciberseguridad de la nación, que ya tiene más de dos años, para empujar a los proveedores en la dirección correcta. La Oficina Oval no puede castigar directamente a las empresas por crear códigos de mala calidad, pero la EO prohíbe a las agencias federales comprárselos.

También podemos buscar respuestas en la estandarización. La norma ISO 27001:2022 actualizada incluye Anexo A Control 8.28, que define principios de diseño y desarrollo seguros tanto para el software desarrollado internamente como para la reutilización de código externo. Dado que muchas empresas confían en esta acreditación como diferenciador clave, la adición de este control crea una presión adicional para mejorar y documentar la seguridad del software.

Cambiando las mareas políticas

Si bien la responsabilidad de los proveedores es un tema delicado, el Congreso no ha rehuido el uso de legislación para abordar cuestiones tecnológicas complejas en el pasado. El interés corporativo juega un papel importante en su reticencia a abordar este problema particular, impulsado por una industria del software con mucho poder de lobby.

Sin embargo, cada vez más personas tienen la misión de exigir responsabilidades a una industria intensamente competitiva. Puede que Facebook haya abandonado oficialmente su antiguo eslogan interno, “muévete rápido y rompe cosas”, pero ese sigue siendo un modelo operativo de facto para las empresas tecnológicas que se apresuran a innovar. A medida que el software afecta cada vez más nuestra vida cotidiana, es más necesario que nunca algún tipo de equilibrio entre el desarrollo imprudente de funciones y la responsabilidad mesurada por un funcionamiento seguro.