Este artículo apareció originalmente como parte del Consejo de Tecnología de Forbes. Se ha actualizado y sindicado aquí.

‍

¿Cuántos registros de datos cree que se vieron comprometidos en 2022? Estaría en el buen camino si adivinara alrededor de 500 millones. Según los datos de filtraciones disponibles públicamente, sólo el año pasado se robaron aproximadamente 480.014.323 registros, pero es probable que la cifra sea mucho mayor. En cualquier caso, se trata de una estadística aleccionadora para el ciudadano medio y muy preocupante para cualquier profesional de la seguridad empresarial.

Hemos llegado a un punto en el que es probable que la mayoría de los habitantes del mundo desarrollado hayan visto cómo al menos algunos de sus datos personales caían en manos de delincuentes a través de un ciberataque con éxito, por lo que es natural que los gobiernos del mundo estén buscando soluciones para frenar este flujo perturbador de actividad delictiva en línea. El último paso lo ha dado la Administración Biden con la Estrategia Nacional de Ciberseguridad, que estoy siguiendo con gran interés. Esta estrategia incluye directrices sobre uno de mis temas favoritos en la actualidad: la responsabilidad en materia de seguridad.

La estrategia, publicada tras una presentación seminal de la Directora de Ciberseguridad y Seguridad de Infraestructuras de CISA, Jen Easterly, ha causado, comprensiblemente, cierta división en la comunidad de seguridad. Sin embargo, creo que representa la mejor oportunidad que tenemos para elevar los estándares de software en todos los ámbitos y, finalmente, marcar el comienzo de una nueva era de desarrolladores cualificados en seguridad.

Los vendedores deberían haber respondido siempre de la inseguridad del software.

Desde hace décadas, en lo que respecta a la seguridad del software, la responsabilidad es una patata caliente con la que ningún equipo trata de hacer malabarismos. Los ejecutivos y los equipos tienden a discrepar vehementemente sobre quién es el responsable último de la seguridad del software, y un informe de Venafi revela que el 97% de los altos ejecutivos de TI están de acuerdo en que los procesos de creación de software no son lo suficientemente seguros, aunque existe una discrepancia sobre quién es el responsable último de aplicar las mejores prácticas de seguridad. El 61% de los ejecutivos afirmó que los equipos de seguridad de TI deberían asumir la responsabilidad de la seguridad del software, mientras que el 31% afirmó que debería ser el equipo de desarrollo el que cargase con la cruz. Y eso es sólo una parte de la ecuación: la cuestión de los componentes comerciales de código abierto y de terceros en las compilaciones de software es una expansión siempre presente de la superficie de ataque. Incluso entre los equipos de seguridad y AppSec, rara vez hay un "propietario" obvio, a pesar de la necesidad de una vigilancia continua en la actualización, supervisión y pruebas.

Esta misma encuesta también puso de manifiesto que, a pesar del conflicto interno sobre quién debe ser responsable de la seguridad y la integridad del software, el 94% de los ejecutivos cree que debería haber sanciones para los proveedores de software que no protegen sus procesos de compilación de las amenazas y ponen en riesgo a los clientes y usuarios finales. 

Con el reciente procesamiento del CISO de Uber en relación con su mala gestión de un ciberataque devastador en 2016, así como iniciativas regulatorias como el GDPR, estamos viendo poco a poco cómo suben las apuestas para los proveedores que juegan con fuego al quitar prioridad a la seguridad. Sin embargo, esto simplemente no es suficiente. Estamos perdiendo la batalla contra los ciberdelincuentes y, aunque sea difícil de tragar, son las prácticas laxas de los proveedores de software las que les brindan oportunidades ilimitadas para prosperar. 

La Estrategia Nacional de Ciberseguridad pretende trazar una línea en la arena y poner fin al juego circular de echar la culpa al proveedor asignándole toda la responsabilidad del software inseguro.

Veámoslo:

Objetivo estratégico 3.3 - Cambiar la responsabilidad de los productos y servicios de software inseguros:

"Demasiados vendedores "ignoran las mejores prácticas para un desarrollo seguro, distribuyen productos con configuraciones por defecto inseguras o vulnerabilidades conocidas, e integran software de terceros de procedencia no verificada o desconocida.

Debemos empezar a trasladar la responsabilidad a aquellas entidades que no tomen precauciones razonables para asegurar su software, reconociendo al mismo tiempo que ni siquiera los programas de seguridad de software más avanzados pueden evitar todas las vulnerabilidades."

Es comprensible que esto haya irritado a algunos. Pero, como en otros momentos decisivos en el desarrollo de normas y reglamentos en la mayoría de los sectores, se trata de un dolor a medio plazo para garantizar un mejor resultado a largo plazo. Como proveedor de software, tiene sentido que la responsabilidad recaiga sobre nosotros en materia de seguridad. Es nuestro proceso de construcción, nuestros procesos y nuestro control de calidad, y si cometemos un error, es nuestra responsabilidad remediarlo.

Además, deberíamos estar en un lugar en el que buscamos crear software de la mayor calidad posible, y la codificación segura debe formar parte de las métricas que definen un resultado satisfactorio. Lograr esto es una tarea difícil en un mundo que se centra en la velocidad a toda costa, pero depende de los líderes de seguridad que guían nuestro futuro garantizar que todos los que participan en el proceso de creación de software reciban la formación adecuada para ofrecer las mejores prácticas de seguridad en el contexto de su función, especialmente los desarrolladores. 

Aún nos falta orientación sobre las mejores prácticas a largo plazo.

El Objetivo Estratégico 3.3 hace referencia al bien establecido Marco de Desarrollo Seguro de Software del NIST como base para sus mejores prácticas generales, y se trata de directrices exhaustivas que lo abarcan todo. Especifican la necesidad de "garantizar que el personal, los procesos y la tecnología de la organización estén preparados para llevar a cabo un desarrollo de software seguro a nivel de la organización", pero no son especialmente prescriptivas en cuanto a los factores que, por ejemplo, un responsable de la concienciación sobre la seguridad debe tener en cuenta a la hora de elegir soluciones de habilitación.

Para que el enfoque sea realmente transformador, los desarrolladores deben ser considerados parte integral del programa de seguridad, y se les deben dar todas las oportunidades para mejorar sus habilidades y compartir la responsabilidad de la detección y erradicación de vulnerabilidades. No pueden lograr esto de una manera que sea medible sin aprendizaje y herramientas hiper-relevantes y contextuales, ni si se considera un ejercicio de cumplimiento anual en lugar de una vía de desarrollo de habilidades en curso. 

Los desarrolladores son una poderosa pieza del rompecabezas cuando se trata de descifrar el enigma de la seguridad, y un equipo de desarrolladores expertos en seguridad es esencialmente el ingrediente que falta en la mayoría de las organizaciones. Hacen posible la seguridad a gran velocidad, pero sólo cuando se dedican tiempo y recursos a desbloquearla en el equipo. Hasta entonces, todas las directrices generales de buenas prácticas del mundo no servirán para mover la aguja.

El largo camino hacia el nirvana de la seguridad del software.

La Administración Biden ha comprometido 3.000 millones de dólares de financiación para la CISA, con el objetivo de lograr una rápida resiliencia en todas las infraestructuras críticas. Aunque la financiación y el apoyo de las más altas instancias del gobierno son fundamentales, para que tengamos alguna posibilidad de frustrar a los actores de las amenazas en su camino, será necesario un impulso global para reescribir la historia de la cultura de la seguridad.

Queda un largo camino por recorrer, pero empieza con cada proveedor de software dando el primer paso valiente hacia la responsabilidad de la seguridad a nivel organizativo.