Las siglas no son exclusivas de la ciberseguridad, pero se han convertido en un sello distintivo de cómo nos comunicamos entre nosotros. ¿Realmente necesitamos agregar esta capa de complejidad a una industria que ya es compleja? ¿O simplemente están deprimiendo más a nuestros desarrolladores? Hagamos que la seguridad sea accesible y viable.
La industria de la seguridad cibernética está experimentando un crecimiento récord, creciendo a un ritmo del 20% anual, y se basa en la promesa de una mayor productividad. Sin embargo, los desarrolladores a menudo tienen dificultades para centrarse en lo que es importante. En cambio, se topan con nuevas siglas que les hacen recurrir a ese diccionario cada vez que quieren hacer algo. Hemos desarrollado algo único en la industria de la seguridad cibernética: un idioma que nadie habla de forma nativa.
Investigador de seguridad y abogado de aikido.
El poder de un lenguaje común
La causa fundamental de todos nuestros problemas de comunicación es que describimos las herramientas de seguridad por lo que son en lugar de por lo que hacen.
Tomemos como ejemplo las “comprobaciones de seguridad de aplicaciones estáticas”: en realidad no significa nada para las personas que ya no saben qué es. Pero lo que realmente hace es intentar proteger nuestro código. Con este conocimiento podemos intentar comprender inmediatamente qué son las “pruebas dinámicas de seguridad de aplicaciones”. Esto es semántica, no conjeturas. (P.D. Esto último es como un hacker que intenta encontrar vulnerabilidades en nuestras aplicaciones).
Mi principal frustración es que no puedo entender por qué necesitamos siglas para estas cosas cuando simplemente podemos describir lo que hacen. Cuando creamos herramientas de seguridad, debemos poder describir fácilmente lo que hacen en términos no técnicos, en lugar de intentar describir qué son.
A medida que esta barrera de comunicación avanza en la cadena y cruza la brecha técnica, estos problemas se vuelven aún mayores. A nivel de la junta directiva, los equipos de seguridad están completamente contra la pared en términos de financiación. Tenemos esta situación sin salida en la que los equipos de seguridad no reciben suficiente financiación, o al menos creen que no la reciben, y también sufrimos muchos más ataques a la seguridad. Uno de los mayores problemas es que a nivel de junta directiva, quienes toman las decisiones no entienden mucho de lo que se necesita. Porque no entienden qué hacen realmente las cosas. No se puede entrar a la sala de juntas y pedirle al CEO que entregue dinero en efectivo para CNAPP.
El cínico que hay en mí también ve muchas de estas iniciales como máquinas de imprimir dinero. Cuando creamos nuevas siglas que reemplazan a las antiguas y decimos que necesitamos nuevas herramientas para ellas, simplemente parece otra venta. E incluso cuando se necesita algo, es difícil separar las necesidades del engaño.
el valor de brillo
Hay una sensación de incredulidad de que todavía estaré tocando este tambor en 2024, pero debemos abordar la seguridad cibernética de manera más integral. Tendemos a proteger aplicaciones completas o desarrollos de software completos en fases separadas. Están en silos. ¿Qué pasaría si pudiéramos aprovechar toda esta innovación para crear un enfoque de seguridad que parezca una parte natural del desarrollo? Estas son las cuatro áreas clave en las que debemos centrarnos. En lenguaje sencillo, por supuesto:
Asegurando nuestro código fuente – Cubre todo lo escrito en código, incluida la infraestructura como código. Se trata de escribir código seguro desde cero.
Asegurar nuestra aplicación en tiempo de ejecución – Se trata de proteger nuestra aplicación mientras se ejecuta. ¿Puede un atacante encontrar vulnerabilidades? Esto incluye herramientas de ofuscación (herramientas que intentan dañar su aplicación arrojándole datos inesperados), pruebas de API y lo que comúnmente llamamos “pruebas dinámicas”.
La seguridad de nuestros entornos en la nube – Esto significa proteger la infraestructura sobre la que funciona todo.
Asegurar nuestra cadena de suministro – Cubre dependencias, componentes de código abierto y elementos de terceros.
cuatro áreas. Explicación clara. Y es mucho más fácil para los desarrolladores entender que en lugar de verse perjudicados por acrónimos que hacen algo ligeramente diferente o que combinan dos funciones diferentes, las prioridades están claramente definidas.
Como me dijo Jason Deeks, ex CISO de Ubisoft, en mi antiguo podcast Security Repo: “Poder dividir los términos técnicos en términos no técnicos realmente me llevó a donde estoy”. Me confirmó que esta es la habilidad que necesitas para tener éxito, y las siglas realmente no ayudan. Incluso si desechamos las iniciales, aún queda camino por recorrer. Si estás hablando de “necesitamos una herramienta de prueba de seguridad de aplicaciones estáticas” o “necesitamos infraestructura como herramienta de prueba de código”, lo que deberíamos decir en la sala de juntas es “necesitamos estas herramientas para proteger nuestro código fuente” y ” Necesitamos estas herramientas para proteger nuestra aplicación”.
Esta es la realidad: las siglas deben ser entendidas por un pequeño subconjunto de personas. Sin embargo, tenemos (según el último recuento) más de 300 de ellos. Necesitamos pasar de una cultura de complejidad y exclusividad a una cultura de claridad e inclusión. Cuando comunicamos eficazmente sobre seguridad, hacemos más que comunicar información: la comunicación inteligente respeta el tiempo y la carga cognitiva de los desarrolladores. También permite que la comunicación avance de manera efectiva en la cadena, lo que significa que ya no es una parte de la organización incomprendida y con fondos insuficientes.
Hemos clasificado el mejor software de protección de terminales.
Este artículo se produjo como parte del canal Expert Insights de TechRadarPro, donde mostramos las mejores y más brillantes mentes de la industria tecnológica actual. Las opiniones expresadas aquí son las del autor y no necesariamente las de TechRadarPro o Future plc. Si estás interesado en donar, descubre más aquí:
