Generar confianza: el camino hacia una verdadera sinergia de seguridad entre AppSec y los desarrolladores

Una versión de este artículo apareció en Revista Cyber Defense. Se ha actualizado y distribuido aquí.

Una relación que se basa en los cimientos inestables de la desconfianza es, bueno, mejor abordarla con bajas expectativas. Lamentablemente, este puede ser el estado de la relación de trabajo entre los desarrolladores y el equipo de AppSec dentro de una organización. La situación, que por lo general es fría y se ve empañada por una tendencia a interponerse en el camino de los demás, no es la ideal y conduce a malos resultados en un mundo en el que las dependencias de la tecnología son muy riesgosas.

A los desarrolladores les encanta resolver problemas, crear funciones y mostrar creatividad en su trabajo. AppSec, por otro lado, tiene la poco envidiable tarea de encontrar errores de seguridad en su código, recuperarlos para corregirlos y proporcionar auditorías e informes que estropean los proyectos favoritos del ingeniero. No es justo echar la culpa únicamente a los desarrolladores (la seguridad no es su prioridad ni forma parte de sus KPI), ni se puede penalizar al equipo de AppSec, que está sobrecargado de trabajo, simplemente por hacer su trabajo. Sin embargo, para seguir las mejores prácticas de ciberseguridad y obtener mejores resultados de seguridad a nivel organizacional, es necesario que empiecen a actuar con cautela.

Y todo comienza con la confianza.

La imagen de «chico malo» de AppSec se interpone en el camino de la armonía de DevSecOps.

Si tus únicas interacciones con alguien se producen cuando te señala en qué te has equivocado, es muy probable que sus comentarios no sean vistos favorablemente.

Las connotaciones negativas de la presencia del equipo de seguridad, que rara vez se ven a menos que haya un problema, tienden a causar cierta fricción. La relación se ha roto durante bastante tiempo: los desarrolladores ven al equipo de AppSec como un obstáculo para su creatividad, sus procesos y el envío puntual de las funciones, mientras que AppSec se cansa de señalar continuamente los errores de seguridad más comunes que existen (y su solución) desde hace décadas.

Con plazos cada vez más imposibles, equipos con pocos recursos y un fuerte deseo de evitar tener que volver a trabajar, los desarrolladores solían esperar hasta el último momento posible para enviar su código, lo que hacía que la oportunidad de revisar e intervenir en AppSec fuera lo más pequeña posible. Se trata de un proceso disfuncional que tiene el impacto inaceptable de aumentar el riesgo de ciberseguridad para la organización.

Para los especialistas en seguridad, se trata de «no matar al mensajero»; al fin y al cabo, su trabajo consiste en encontrar errores e informarlos para que puedan solucionarlos, nada personal. El problema es que, con frecuencia, pueden hacer recomendaciones que no son las más adecuadas para el conjunto tecnológico de la empresa, por lo que pueden considerarse en gran medida inútiles desde el punto de vista del desarrollo interno de software.

La idea de que AppSec es el villano es contradictoria para la mayoría de las metodologías de desarrollo, pero para DevSecOps es un desastre. El estándar de referencia ha ido mucho más allá de Waterfall, Agile e incluso DevOps, y se ha convertido en un proceso que considera la seguridad como una responsabilidad compartida desde el principio del SDLC como algo vital.

Para que DevSecOps funcione, los ingenieros de software deben tener una razón para preocuparse por la seguridad, y eso proviene de entender por qué es tan importante para ellos hacer su parte para proteger el software mundial. Los especialistas en seguridad que se esfuerzan por extender la rama de olivo, trabajan con los gerentes de desarrollo para satisfacer las necesidades del equipo y asumen una función más bien de mentores para fomentar la conciencia de seguridad tienden a ver beneficios a largo plazo de sus esfuerzos... y dedican un poco menos de tiempo a arrancarse los pelos por otro error de XSS.

Los desarrolladores deben estar capacitados para ofrecer resultados de codificación más seguros.

Cuando se trata de aprender a programar de forma segura durante la educación superior, para muchos ingenieros, es inexistente. Y no es porque estuvieran todos ocupados jugando al beer pong y a WoW, simplemente no forma parte de la mayoría de los títulos de informática e informática.

Con ese fin, la formación en el trabajo suele ser la primera exposición que un desarrollador tendrá al arte de la seguridad del software, y rara vez incendia su mundo. Las horas de vídeos aburridos son un método de formación habitual, al igual que los ejercicios de cumplimiento «para marcar las casillas», que son demasiado poco frecuentes como para tener un impacto real a la hora de enseñar a los desarrolladores a programar de forma segura o a avanzar en la reducción de las vulnerabilidades más comunes del software de una organización.

Tanto el equipo de AppSec como la cohorte de desarrollo están muy ocupados, por lo que cualquier formación debe ser significativa, atractiva y práctica. Desde el punto de vista del desarrollo, nos encanta resolver problemas y ponernos manos a la obra, por lo que la mayoría de las capacitaciones estáticas no nos dejan de lado mientras nos concentramos en algo más urgente (o, seamos sinceros, interesante).

Los especialistas de AppSec tienen una posición de influencia y pueden forjar una situación a largo plazo en la que todos salgan ganando si defienden los intereses de los desarrolladores. Buscar una formación viable que sea relevante para el puesto de trabajo y que se imparta en los idiomas y marcos de trabajo que prefieran es un gran paso para cambiar el rumbo e inspirar una cultura de seguridad positiva y de base en una organización. Llevamos décadas intentando lo mismo y, evidentemente, el enfoque de formación de «talla única» no funciona. Al ayudar a ofrecer las herramientas y los conocimientos adecuados a los desarrolladores, estos pueden mejorar con éxito sus habilidades en materia de codificación segura, actuar con una mayor conciencia de seguridad y producir un estándar de código más alto.

Los esfuerzos para estar en sintonía deben provenir de ambos lados.

Es fácil que las personas con objetivos diferentes se malinterpreten o, en el peor de los casos, se vuelvan un poco desconfiadas. El objetivo de AppSec es mantenerse al día con la avalancha de código que se está produciendo y detectar cualquier problema de seguridad que pueda comprometer los datos, provocar accesos no autorizados y ataques malintencionados que puedan acabar con la confianza positiva de los clientes durante años.

Los desarrolladores, entre otras cosas, crean funciones dentro de los plazos. Tienen la tarea de hacer que el software sea funcional y atractivo, y de ser los creadores de experiencias digitales únicas que mantengan la lealtad de los clientes. Ya tienen muchas cosas con las que hacer malabares, y lanzarles una bola curva en forma de responsabilidad en materia de seguridad es una perspectiva desalentadora. La seguridad del código se considera un problema para AppSec, y si bien eso era algo que se podía lograr en los años 90 (ya sabes, antes nuestros coches podrían ser pirateados, y podríamos llevar toda nuestra vida en un superordenador de bolsillo (llamado teléfono inteligente), simplemente hay demasiado código y no hay suficientes personas para ejecutarlo a través del desafío de la seguridad.

Con una buena dosis de empatía y la posibilidad de hacer de la seguridad una prioridad desde el principio del proceso de creación del software, AppSec y los desarrolladores pueden encontrar formas de alinear sus objetivos. Al fin y al cabo, una cultura de seguridad positiva depende de ello, y los desarrolladores conscientes de la seguridad son el ingrediente secreto para detener las vulnerabilidades más comunes, incluso con escasez cada vez mayor de habilidades de ciberseguridad.

El respeto mutuo por el tiempo tiene inmensos beneficios.

Como dije antes, todo el mundo está muy ocupado cuando se trata de hacer realidad la magia (también conocida como software increíble). Los desarrolladores necesitarán asignar tiempo de trabajo para realizar una formación práctica y viable que les permita desarrollar sus habilidades de codificación segura, y cualquier programa de formación debe tener un diseño muy relevante.

AppSec pierde su tiempo solucionando lo mismo Los 10 mejores de OWASP vulnerabilidades una y otra vez, y los desarrolladores reducen las suyas con ejercicios de bajo compromiso que refuerzan la idea de que la seguridad es una tarea ardua.

Las experiencias de aprendizaje seleccionadas son vitales y ayudan a ir al grano impartición contextual y de tamaño reducido de la formación pertinente, justo en el momento en que se necesita.

Al organizar un curso de codificación segura personalizado que se adapta a los resultados deseados y a las vías de aprendizaje internas, se respetan el tiempo y el flujo de trabajo del desarrollador y, al mismo tiempo, se trabaja para lograr una reducción mensurable de las vulnerabilidades y los riesgos de ciberseguridad para la empresa. Es una victoria rápida en la lucha por acabar con las rivalidades indirectas y avanzar en el salvaje oeste de la ciberseguridad como un frente unido.

La última función de aprendizaje contextual de Secure Code Warrior, Cursos, ya está disponible.

‍