Cuando se trata de problemas de seguridad con productos nuevos y complejos, la respuesta de la sociedad suele ser consistente: primero, culpar al usuario. Sólo más adelante debería responsabilizar al fabricante por los defectos de diseño inherentes a sus productos. Vimos esto con los coches y luego con las computadoras. Pero así como cambió el automóvil, las actitudes en la industria de TI también están evolucionando.

Los primeros coches salieron a la venta en Estados Unidos a finales de la década de 1890. Después de eso vinieron una serie de leyes estatales de seguridad. Connecticut introdujo el primer límite de velocidad en 1901. Luego vinieron los primeros semáforos. Nueva York aprobó la primera ley sobre conducción bajo los efectos del alcohol en 1910. Con el tiempo (pero lentamente), los estados comenzaron a otorgar licencias a los conductores e incluso ocasionalmente a realizarles pruebas.

Castigar al usuario, perdonar al vendedor

Todas estas medidas para regular el comportamiento de los conductores eran importantes, pero, para empezar, nadie responsabilizaba a los proveedores de automóviles por diseñar la seguridad en sus productos. No fue hasta 1965, cuando Ralph Nader publicó su libro sobre seguridad vehicular, Unsafe at Any Speed, que los consumidores comenzaron a pensar en exigir automóviles más seguros. Un año después, el Congreso aprobó la Ley Nacional de Tráfico y Seguridad de Vehículos Motorizados, creando el Departamento de Transporte y, finalmente, obligando a los vendedores de automóviles a colocar cinturones de seguridad en los vehículos.

El Congreso aprobó esa ley sobre el cinturón de seguridad 60 años después de que el primer Ford Modelo T saliera de la línea de producción. Quizás no sea sorprendente, entonces, que 42 años después de que IBM lanzara la PC, haya casi no hay leyes responsabilizar de manera similar a los proveedores de productos tecnológicos por la seguridad de sus productos.

Las únicas leyes reales que rigen la seguridad informática en la actualidad están ahí para vigilar a los usuarios. La Ley de Abuso y Fraude Informático (CFAA), diseñada para detener las intrusiones en la seguridad cibernética, se aprobó hace casi 40 años y no se ha actualizado significativamente desde entonces. La Ley de Derechos de Autor del Milenio Digital (DMCA) se centra en evitar que las personas eludan los controles de derechos de autor digitales.

Despertar a la seguridad por diseño

Ahora, hay un esfuerzo dedicado para lograr que los fabricantes hagan lo correcto e incorporen seguridad a sus productos en la fase de diseño en lugar de como un complemento posventa. En abril de 2023, la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) publicó su guía sobre diseño de productos seguros: Cambiando el equilibrio del riesgo de ciberseguridad: principios y enfoques para la seguridad por diseño y por defecto.

La seguridad por diseño genera seguridad desde la fase de diseño en adelante, en lugar de ser una idea de último momento o un complemento posventa. La seguridad de forma predeterminada garantiza que la seguridad esté activada para proteger a los usuarios desde el primer momento sin cargos adicionales.

Los principios del aviso conjunto incluyen algunas cosas aparentemente obvias. Por ejemplo, advierte que la carga de la seguridad no debe recaer únicamente en el cliente. Los proveedores de software deberían "asumir la propiedad de los resultados de seguridad de la compra de sus clientes". Este también fue un objetivo estratégico en la campaña de marzo de 2023 de la Casa Blanca. Estrategia Nacional de Ciberseguridad.

Otra es la “transparencia radical”, según la cual los proveedores de software deberían enorgullecerse de crear productos seguros y demostrar cómo lo hacen.

Todo esto se basa en el tercer principio: construir una estructura de liderazgo que respalde estos objetivos. Los altos ejecutivos deben estar dispuestos a recopilar comentarios de los clientes sobre la seguridad del producto y luego dedicar recursos internos para abordar esos problemas. Esa estructura organizativa podría significar dedicar una persona específica responsable de la seguridad del software, añade el documento.

El problema de la responsabilidad del proveedor

La seguridad por diseño parece una propuesta simple, pero sus defensores enfrentan varios desafíos difíciles, muchos de los cuales son monetarios.

En primer lugar, aceptar la responsabilidad de la seguridad del software es un riesgo considerable para los proveedores de software, cuyos clientes corren cada día enormes pérdidas debido a fallos en su software. Sólo en casos muy extremos estos proveedores sufren económicamente. Por ejemplo, las aseguradoras de SolarWinds paid 26 millones de dólares a los clientes en un acuerdo después de que su software comprometido afectara a unas 18,000 organizaciones en 2020.

Por cada proveedor de tecnología que se esfuerza por proteger sus productos desde cero, habrá muchos que no lo hagan. La Casa Blanca se ha comprometido a trabajar con el Congreso para desarrollar una legislación que establezca la responsabilidad de los proveedores por la seguridad de los productos tecnológicos, pero a medida que entramos en un año electoral y el Congreso apenas puede ponerse de acuerdo sobre lo suficiente para mantener al gobierno en funcionamiento, las posibilidades de que esto suceda parecen escasas.

Por el momento, obligarlos a cambiar podría ser responsabilidad del cliente. La CISA recomienda que las empresas elijan con su dinero, evaluando los esfuerzos de sus proveedores para asegurar los productos desde el diseño y por defecto. La Casa Blanca está colaborando. En julio, anunció el US Trust Mark, un sistema de calificación de ciberseguridad para ayudar a los consumidores a evaluar los dispositivos conectados.

Hay otros desafíos a la responsabilidad del proveedor. Si bien algunos errores de seguridad pueden ser culpa del proveedor, habrá muchos en los que el proveedor podría culpar al cliente por hacer un mal uso o una mala configuración del software.

Una herramienta para ayudar a prevenir dicho uso indebido por parte del cliente es el perfil de autorización de software. Esta táctica de seguridad incorporada, destacada por CISA en su guía, recomienda cómo los usuarios de ciertos tipos deben usar el software, incluida la descripción de los privilegios de acceso para esos diferentes roles. Esto impide que el supervisor de la sala de correo acceda a las mismas funciones en el sistema de planificación de recursos empresariales que, por ejemplo, el jefe de ventas. Los proveedores de software expertos pueden alertar a los usuarios si intentan desviarse del perfil.

Costo y complejidad

La seguridad integrada es compleja y costosa. Como señala el aviso conjunto: "El desarrollo seguro por diseño requiere la inversión de recursos significativos por parte de los fabricantes de software en cada capa del proceso de diseño y desarrollo del producto que no se pueden 'añadir' más adelante".

Esto es especialmente problemático cuando se trata de productos de software y hardware heredados. Muchos proveedores de software trabajan con código heredado monolítico desarrollado durante años que es frágil y difícil de actualizar. Esto es más difícil de actualizar que el software modular, con muchos componentes independientes y débilmente acoplados.

Las empresas pueden pagar esta deuda técnica gradualmente a través de múltiples iteraciones de productos, pero se necesitan recursos significativos para desmantelar ese software hasta sus cimientos y reestructurar la seguridad desde cero.

Diseño seguro: una tarea ingrata

Eso nos lleva al siguiente problema: la visibilidad o la falta de ella.

Produzca una nueva característica brillante y altamente visible, como la IA generativa, y tentará a los clientes a comprar la próxima versión de su producto o mantener su suscripción. Por el contrario, ajustar código debajo del capó para ser más seguro y bien organizado es loable pero ingrato; No es un gran punto de venta para muchos clientes. Un sitio web que dice "Ahora seguro de adentro hacia afuera" probablemente generará la respuesta: "¿Qué? ¿Quieres decir que no era tan seguro en primer lugar?"

La seguridad siempre ha sido un poco como un seguro de propiedad o de vida: hay que hacerlo, pero es difícil de vender. Hacer que sus propios productos no relacionados con la seguridad sean más seguros no genera ingresos directos. Sin embargo, vender productos de seguridad secundarios, como software antimalware y cortafuegos, es lucrativo.

Tácticas de seguridad por diseño

Dicho todo esto, los desafíos no deberían disuadirnos de buscar la seguridad por diseño. Las organizaciones pueden adoptar algunas tácticas que ayudarán a fomentar la seguridad del software desde el principio. Uno de ellos, destacado en la guía CISA, es el uso de lenguajes seguros para la memoria.

Algunos lenguajes de programación tradicionales de bajo nivel, en particular C y C++, permiten a los programadores manipular áreas de la memoria que no deberían. Pueden leer memoria que podría contener información confidencial o código inapropiado. También pueden cambiar la forma en que se ejecutan otros programas o ponerlos en un estado de confusión, volviéndolos vulnerables a ataques.

Los proveedores de sistemas operativos han introducido medidas de protección de la memoria, pero CISA dice que son inadecuadas por sí solas. En su lugar, recomienda utilizar lenguajes de programación con protecciones de memoria integradas, como C#, Go o Rust.

Abordar este problema desde el principio podría generar importantes mejoras de seguridad. En 2019, los ingenieros de Microsoft dijo que aproximadamente siete de cada diez de todas las vulnerabilidades en los productos de Microsoft se debían a problemas de seguridad de la memoria.

¿Quién lidera la seguridad por diseño?

Varios grupos gubernamentales e industriales ya cuentan con principios y marcos de diseño seguros que se centran en varios niveles de la pila tecnológica. En el lado del software, estos incluyen Marco de desarrollo de software seguro del NIST y una iniciativa de toda la industria para el desarrollo de software seguro llamada SafeCode. También se están realizando algunos esfuerzos para incorporar la seguridad en áreas específicas, como el diseño de aplicaciones web, a través de Principios de diseño seguro de OWASP.

En cuanto al hardware, las empresas han trabajado juntas durante años en sistemas de módulos de plataforma confiable (TPM) que almacenan físicamente secretos en silicio a prueba de manipulaciones en la placa base. En este punto, no puede instalar Windows 11 sin una versión 2.0 de TPM.

Una carrera hacia el fondo (de la pila)

La insistencia de Microsoft en el hardware TPM es un ejemplo de cómo algunos proveedores están haciendo todo lo posible para abordar la seguridad desde el diseño, colaborando entre sí para crear cadenas de seguridad que comienzan en el silicio y se extienden al sistema operativo.

Un ejemplo es Secure Boot, una característica de seguridad que almacena códigos aprobados por el fabricante que prueban que varios componentes del sistema, como el firmware y el sistema operativo, son legítimos. Esto se basa en un TPM, junto con la Interfaz de firmware extensible unificada (UEFI), la versión moderna del firmware de la computadora, lo que ejecuta y arranca el resto de la computadora cuando se enciende.

Al verificar y proteger el código en niveles inferiores del sistema, los proveedores de sistemas operativos y los fabricantes de equipos originales pretenden garantizar un control completo sobre todo lo que depende de ese código. Sin embargo, estas protecciones están sujetas a sus propios fallos de seguridad, como todo lo demás. En el caso de Secure Boot, un código de vulnerabilidad llamado Baton Drop permitió a los atacantes introducir un rootkit UEFI llamado BlackLotus que eludió estas protecciones, permitiendo a los atacantes poseer el sistema para sus atacantes.

Ataques como estos no significan que no debamos buscar la seguridad por diseño y por defecto. Impulsar más seguridad al sistema desde el principio inclina la balanza a favor de los defensores y dificulta los ataques. Pero ataques como BlackLotus muestran que incluso la seguridad impuesta durante la fase de diseño puede burlarse. La respuesta es diseñar múltiples capas y facetas de protección en los sistemas, minimizando la superficie de ataque y proporcionando múltiples obstáculos que los atacantes deben superar.

Regulación

Los gobiernos se están tomando en serio la seguridad desde el diseño, con varias medidas legislativas ya sea aquí o en proceso. En Estados Unidos, California y Oregón han aprobado leyes de seguridad de IoT. Estos requieren que los dispositivos individuales conectados tengan contraseñas únicas preprogramadas o obliguen a los usuarios a generar un nuevo medio de autenticación antes de poder acceder al dispositivo por primera vez.

En el Reino Unido, la Ley de Telecomunicaciones y Seguridad de Productos exigirá requisitos de seguridad básicos para los productos conectados listos para usar. Estos incluyen contraseñas únicas, información sobre cómo informar problemas de seguridad con un producto y el período mínimo de soporte para actualizaciones de seguridad.

Este es un comienzo, pero todavía se pierden algunas oportunidades para imponer una seguridad sólida desde el diseño en todos los productos esenciales. Por ejemplo, las computadoras de escritorio y portátiles y las tabletas están excluidas de la ley del Reino Unido, al igual que los dispositivos médicos, los medidores inteligentes y los teléfonos inteligentes. Al menos sus hervidores conectados y cámaras de seguridad web están cubiertos.

El problema con este tipo de leyes es encontrar el equilibrio entre eficacia y complejidad. Las leyes que microgestionan la aplicación de principios de seguridad son difíciles de controlar y actualizar. Sin embargo, exigir la solicitud y documentación de una ciclo de vida seguro del desarrollo de software ayudaría a asegurar muchos productos.

La UE también espera abordar el problema de seguridad inherente a nivel de bloque. En septiembre de 2022, publicó un proyecto de ley, mucho más estricto que la ley del Reino Unido, que endurecería las normas de ciberseguridad para imponer una mejor seguridad de los productos. La Ley de Resiliencia Cibernética obligaría a los fabricantes a mejorar la seguridad de los productos durante todo el ciclo de vida del producto.

Aprendiendo de la historia

El enfoque de la industria de las PC hacia la seguridad por diseño es actualmente el mismo que el de la industria automotriz a mediados de los años sesenta. La ciberseguridad se ha convertido en una preocupación pública generalizada y algunas organizaciones han estado explorando enfoques de seguridad integrada de forma voluntaria para diferenciarse y proteger a sus usuarios.

Ahora, los gobiernos están presionando gradualmente el tema con legislación. Queda un largo camino por recorrer, en parte porque la complejidad de las soluciones de TI y las cadenas de suministro digitales que las respaldan es un orden de magnitud mayor que la del sector automotriz anterior a la digitalización.

Algunas cosas siguen igual, en particular la falta de conciencia o la ambivalencia de los consumidores. Cuando Estados Unidos ordenó la inclusión de cinturones de seguridad en los automóviles, su uso era voluntario. Cuando los primeros estados comenzaron a exigir el uso del cinturón de seguridad, casi dos décadas después, menos de una de cada cinco personas lo utilizaba. Dependerá de los gobiernos y los proveedores imponer una mayor seguridad en los productos tecnológicos y garantizar que estén activados para los usuarios de forma predeterminada.