Protección proactiva: Aprovechar la Estrategia Nacional de Ciberseguridad para la prevención avanzada de amenazas

Este artículo apareció originalmente como parte del Forbes Technology Council. Ha sido actualizado y distribuido aquí.

‍

¿Cuántos registros de datos cree que fueron vulnerados en 2022? Si su estimación ronda los quinientos millones, va por buen camino. Según los datos de brechas disponibles públicamente, el año pasado se robaron aproximadamente 480.014.323 registros, pero es probable que la cifra sea mucho mayor. En cualquier caso, es 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 en el mundo desarrollado hayan visto cómo parte de sus datos personales caían en manos de delincuentes a través de un ciberataque exitoso, por lo que es natural que los gobiernos busquen soluciones para frenar este flujo disruptivo de actividad delictiva en línea. La última propuesta proviene de la Administración Biden en forma de la Estrategia Nacional de Ciberseguridad, y la observo con gran interés. Esta estrategia incluye directrices sobre uno de mis temas favoritos actualmente: la responsabilidad en seguridad.

La estrategia, publicada tras una presentación fundamental de la directora de la CISA, Jen Easterly, ha causado, como era de esperar, cierta división en la comunidad de seguridad. Sin embargo, creo que representa nuestra mejor oportunidad para elevar los estándares de software en todos los ámbitos y, finalmente, marcar el comienzo de una nueva era de desarrolladores con competencias en seguridad.

Los proveedores siempre deberían haber sido responsables del software inseguro.

Durante décadas, en términos de seguridad de software, la responsabilidad ha sido una patata caliente que ningún equipo quiere manejar. Los ejecutivos y los equipos suelen discrepar vehementemente sobre quién es el responsable final de la seguridad del software; un informe de Venafi revela que el 97% de los altos ejecutivos de TI coinciden en que los procesos de creación de software no son lo suficientemente seguros, pero existe discrepancia sobre quién debe 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, mientras que el 31% señaló que debería recaer en el equipo de desarrollo. Y eso es solo una parte: el uso de componentes de código abierto y de terceros en el desarrollo de software amplía constantemente la superficie de ataque. Incluso entre los equipos de AppSec y de seguridad, rara vez hay un "propietario" claro, a pesar de la necesidad de una vigilancia continua en la actualización, supervisión y pruebas.

Esta misma encuesta también reveló que, a pesar del conflicto interno sobre quién debe ser responsable de la seguridad e integridad del software, el 94% de los ejecutivos cree que debería haber sanciones para los proveedores que no protejan sus procesos de desarrollo frente a actores malintencionados y pongan en riesgo a clientes y usuarios finales.

Con la reciente condena del CISO de Uber en relación con la mala gestión de un devastador ciberataque en 2016, así como con iniciativas regulatorias como el RGPD, estamos viendo cómo aumentan lentamente las consecuencias para los proveedores que juegan con fuego al restar importancia a la seguridad. Sin embargo, esto no es suficiente. Estamos perdiendo la batalla contra los ciberdelincuentes y, aunque sea difícil de aceptar, son las prácticas laxas de los proveedores de software las que les brindan oportunidades ilimitadas para prosperar.

La Estrategia Nacional de Ciberseguridad busca marcar un límite y detener el juego de culpas mutuas asignando la responsabilidad total del software inseguro al proveedor.

Echemos un vistazo:

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

«Demasiados proveedores ignoran las mejores prácticas de desarrollo seguro, distribuyen productos con configuraciones predeterminadas inseguras o vulnerabilidades conocidas, e integran software de terceros de procedencia desconocida o no verificada.

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

Esto, como era de esperar, ha molestado a algunos. Pero, al igual que en otros momentos decisivos en el desarrollo de normas y reglamentos en la mayoría de las industrias, es un dolor a medio plazo para garantizar un mejor resultado a largo plazo. Como proveedor de software, tiene sentido que la responsabilidad final recaiga en nosotros en lo que respecta a la seguridad. Es nuestro proceso de desarrollo, nuestros procedimientos y nuestro control de calidad; si fallamos, es nuestra responsabilidad corregirlo.

Además, deberíamos aspirar a 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 esto es una tarea difícil en un mundo centrado en la velocidad a toda costa, pero depende de los líderes de seguridad que guían nuestro futuro asegurar que todos los involucrados en el proceso de creación de software estén adecuadamente capacitados para aplicar las mejores prácticas de seguridad en su rol, especialmente los desarrolladores.

Todavía carecemos de orientación sobre las mejores prácticas a largo plazo.

El objetivo estratégico 3.3 hace referencia al Marco de Desarrollo de Software Seguro del NIST, bien establecido, como base para sus mejores prácticas generales, las cuales son directrices exhaustivas y completas. Especifican la necesidad de «garantizar que las personas, los procesos y la tecnología de la organización estén preparados para realizar un desarrollo de software seguro a nivel organizativo», pero no son particularmente prescriptivas sobre los factores que, por ejemplo, un gerente de concienciación en seguridad debería tener en cuenta al elegir soluciones de capacitación.

Para que el enfoque sea verdaderamente transformador, los desarrolladores deben considerarse parte integral del programa de seguridad y tener 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 manera medible sin herramientas y aprendizaje contextual altamente relevantes, ni si se considera un ejercicio de cumplimiento anual en lugar de una vía de desarrollo de habilidades continua.

Los desarrolladores son una pieza poderosa del rompecabezas cuando se trata de resolver el enigma de la seguridad, y un equipo de desarrolladores con competencias 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 invierte tiempo y recursos en potenciar al equipo. Hasta entonces, todas las directrices de mejores prácticas del mundo no servirán de nada.

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

La Administración Biden ha comprometido 3.000 millones de dólares en financiación 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 tener alguna posibilidad de detener a los actores malintencionados, se necesitará un esfuerzo global para reescribir la historia de la cultura de seguridad.

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