Protección proactiva: aprovechar la estrategia nacional de ciberseguridad para la prevención avanzada de amenazas

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

‍

¿Cuántos registros de datos cree que se vieron comprometidos en 2022? Estaría en el camino correcto si adivinara alrededor de 500 millones. Basado en los datos de violación disponibles públicamente, aproximadamente 480,014,323 registros fueron robados solo el año pasado, pero es probable que el número sea mucho mayor. En cualquier caso, se trata de una estadística aleccionadora para el ciudadano medio y profundamente preocupante para cualquier profesional de la seguridad empresarial.

Hemos llegado a un punto en el que es probable que la mayoría de las personas del mundo desarrollado hayan visto caer al menos algunos de sus datos personales en manos delictivas a través de un ciberataque exitoso, por lo que es natural que los gobiernos del mundo busquen soluciones para detener este flujo disruptivo de actividad delictiva en línea. La última entrega es de la Administración Biden en forma de Estrategia Nacional de Ciberseguridad, y lo observo con gran interés. Esta estrategia incluye directrices en torno a uno de mis temas favoritos en la actualidad: la responsabilidad en materia de seguridad.

La estrategia, publicada después de presentación seminal de la directora de Ciberseguridad y Seguridad de Infraestructura de la CISA, Jen Easterly, ha provocado, 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, iniciar una nueva era de desarrolladores expertos en seguridad.

Los vendedores deben tener siempre ha sido responsabilizado por software inseguro.

Durante décadas se ha dado el caso de que, en términos de seguridad del software, la responsabilidad es una papa caliente con la que ningún equipo busca hacer malabares. Los ejecutivos y los equipos tienden a discrepar con vehemencia sobre quién es el responsable último de la seguridad del software, con un informe de Venafi revelando 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, pero existe una discrepancia en cuanto a quién es el responsable final de aplicar las mejores prácticas de seguridad. El 61% de los ejecutivos dijo 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 la cruz del equipo de desarrollo. Y esa es solo una parte de la ecuación: el problema de los componentes comerciales de código abierto y de terceros en las compilaciones de software es una expansión constante de la superficie de ataque. Incluso entre los equipos de AppSec y de seguridad, rara vez hay un «propietario» evidente, a pesar de la necesidad de mantener una vigilancia continua durante las actualizaciones, la supervisión y las pruebas.

Esta misma encuesta también reveló que, a pesar de los conflictos internos sobre quién debe ser responsable de la seguridad e integridad del software, el 94% de los ejecutivos cree que deberían sancionarse a los proveedores de software que no protejan sus procesos de construcción de los actores de amenazas y pongan en riesgo a los clientes y usuarios finales.

Con el procesamiento reciente del CISO de Uber En relación con su mala gestión de un devastador ciberataque en 2016, así como con iniciativas normativas como el RGPD, poco a poco estamos viendo cómo aumentan las apuestas para los vendedores que juegan con fuego al despriorizar la seguridad. Sin embargo, esto simplemente no basta. Estamos perdiendo la batalla contra los ciberdelincuentes y, si bien es una píldora 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 busca trazar una línea en la arena y detener el juego circular de culpas asignando toda la responsabilidad por el software inseguro al proveedor.

Vamos a echar un vistazo:

Objetivo estratégico 3.3 — Transferir la responsabilidad por productos y servicios de software inseguros:

»Demasiados proveedores «ignoran las mejores prácticas para un desarrollo seguro, envían productos con configuraciones predeterminadas inseguras o vulnerabilidades conocidas e integran software de terceros de procedencia desconocida o no examinada.

Debemos empezar a transferir la responsabilidad a aquellas entidades que no toman las precauciones razonables para proteger su software, al tiempo que reconocemos que incluso los programas de seguridad de software más avanzados no pueden prevenir todas las vulnerabilidades.»

Esto, comprensiblemente, ha desconcertado a algunos. Sin embargo, al igual que ocurre con otros momentos decisivos en la elaboración de normas y reglamentos en la mayoría de los sectores, garantizar un mejor resultado a largo plazo es difícil a medio plazo. Como proveedor de software, tiene sentido que la responsabilidad recaiga en nosotros en lo que respecta a la seguridad. Es nuestro proceso de creación, nuestros procesos y nuestro control de calidad, y si nos equivocamos, es nuestra responsabilidad solucionarlo.

Además, deberíamos estar en un lugar en el que busquemos crear software de la mayor calidad posible, y la codificación segura debe formar parte de las métricas que definen un resultado exitoso. Lograr este objetivo es una tarea ardua en un mundo que apuesta por la velocidad a toda costa, pero son los líderes en seguridad los que guían nuestro futuro los que deben garantizar que todos los que participan en el proceso de creación del software estén adecuadamente capacitados para aplicar las mejores prácticas de seguridad en el contexto de su función, especialmente los desarrolladores.

Todavía nos falta orientación sobre las mejores prácticas a largo plazo.

El objetivo estratégico 3.3 hace referencia a los países bien establecidos Marco de desarrollo de software seguro del NIST como base de sus mejores prácticas generales, y se trata de directrices amplias y globales. Sí especifican la necesidad de «garantizar que las personas, los procesos y la tecnología de la organización estén preparados para desarrollar software de forma segura a nivel organizacional», pero no son particularmente prescriptivas en cuanto a los factores que, por ejemplo, un administrador de conciencia de seguridad debe tener en cuenta a la hora de elegir soluciones de habilitación.

Para que el enfoque sea verdaderamente transformador, se debe considerar a los desarrolladores parte integral del programa de seguridad y se les debe dar todas las oportunidades para mejorar sus habilidades y compartir la responsabilidad de la detección y erradicación de vulnerabilidades. No pueden lograrlo de una manera que sea mensurable sin herramientas y aprendizajes contextuales hiperrelevantes, ni si se considera un ejercicio anual de cumplimiento en lugar de un proceso continuo de desarrollo de habilidades.

Los desarrolladores son una pieza poderosa del rompecabezas cuando se trata de descifrar el acertijo 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 solo cuando se dedica tiempo y recursos a desbloquearla en el equipo. Hasta entonces, todas las directrices generales sobre mejores prácticas del mundo no lograrán avanzar.

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

La administración de Biden ha comprometido 3 mil millones de dólares en fondos para la CISA, con el objetivo de lograr una rápida resiliencia en toda la infraestructura crítica. Si bien la financiación y el apoyo de los niveles más altos del gobierno son fundamentales, para que tengamos la oportunidad de detener a los actores de amenazas en su camino, será necesario un esfuerzo mundial para reescribir la historia de la cultura de la seguridad.

Queda un largo camino por recorrer, pero comienza cuando cada proveedor de software da el primer paso valiente hacia la responsabilidad de la seguridad a nivel organizacional.