Construir la confianza: El camino hacia una verdadera sinergia de seguridad entre AppSec y los desarrolladores

Una versión de este artículo apareció en Revista de Ciberdefensa. Se ha actualizado y sindicado aquí.

Una relación que se construye sobre la base inestable 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. Por lo general, la situación no es ideal y conduce a malos resultados en un mundo de dependencias tecnológicas de alto riesgo.

Los desarrolladores prosperan en la resolución de problemas, la creación de características y la creatividad en su trabajo. La seguridad de las aplicaciones, por otro lado, tiene la poco envidiable tarea de encontrar fallos de seguridad en su código, devolverlo para que se corrija y proporcionar auditorías e informes que estropean el brillo de los proyectos favoritos de los ingenieros. No es justo culpar únicamente a los desarrolladores -la seguridad no es su prioridad ni forma parte de sus KPI- ni se puede penalizar al sobrecargado equipo de AppSec por hacer simplemente su trabajo. Sin embargo, para las mejores prácticas de ciberseguridad, y mejores resultados de seguridad a nivel organizativo, realmente necesitan empezar a jugar bien.

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ñalan dónde te has equivocado, lo más probable es que su aportación no se vea con buenos ojos.

Rara vez se ve a menos que haya un problema, las connotaciones negativas de la presencia del equipo de seguridad tienden a causar cierta fricción. La relación ha estado fracturada durante bastante tiempo, con los desarrolladores viendo al equipo de AppSec como bloqueadores de su creatividad, proceso y envío puntual de características, mientras que AppSec se cansa mucho de señalar continuamente errores de seguridad comunes que han existido (al igual que su remedio) durante décadas.

Con plazos cada vez más imposibles, equipos con pocos recursos y un fuerte deseo de evitar el retrabajo, los desarrolladores suelen esperar hasta el último momento posible para enviar su código, haciendo que la ventana de oportunidad para la revisión e intervención de AppSec sea lo más pequeña posible. Un proceso disfuncional, y que tiene un impacto inaceptable de aumento del riesgo de ciberseguridad para la organización.

Para los especialistas en seguridad, es un caso de "no disparar al mensajero" - después de todo, su trabajo es encontrar errores y reportarlos para que puedan ser remediados - nada personal. El problema es que a menudo pueden hacer recomendaciones que no son las más adecuadas para la pila tecnológica de la empresa, por lo que pueden considerarse poco útiles en el panorama general del desarrollo de software interno.

La noción de AppSec como el villano es contraintuitiva para la mayoría de las metodologías de desarrollo, pero para DevSecOps, es un desastre. El estándar de oro se ha movido mucho más allá de Waterfall, Agile, e incluso DevOps, en un proceso que ve la seguridad como una responsabilidad compartida desde el principio del SDLC como vital.

Para que el DevSecOps funcione, los ingenieros de software deben tener una razón para preocuparse por la seguridad, y eso pasa por entender por qué es tan importante para ellos hacer su parte para asegurar el software del mundo. Los especialistas en seguridad que se esfuerzan por extender la rama de olivo, trabajan con los directores de desarrollo para satisfacer las necesidades del equipo y asumen un papel más de mentores para fomentar la concienciación sobre la seguridad tienden a ver los beneficios a largo plazo de sus esfuerzos... y pasan algo menos de tiempo rasgándose las vestiduras por otro error XSS.

Los desarrolladores deben estar capacitados para ofrecer mejores resultados de codificación segura.

Cuando se trata de aprender codificación segura durante la educación terciaria, para muchos ingenieros es inexistente. Y no es porque estuvieran ocupados jugando al beer pong y al WoW: simplemente no forma parte de la mayoría de las titulaciones de informática y TI.

Para ello, la formación en el puesto de trabajo es a menudo la primera que recibe un desarrollador en el arte de la seguridad del software, y rara vez le hace arder el mundo. Las horas de vídeos aburridos son un método de formación habitual, al igual que los ejercicios de cumplimiento de normas que son demasiado infrecuentes como para tener un impacto real en la enseñanza de los desarrolladores de cómo codificar de forma segura, o hacer algún progreso en la reducción de las vulnerabilidades comunes en el 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. Hablando desde un entorno de desarrollo, nos encanta resolver problemas y utilizar las herramientas, por lo que la mayoría de la formación estática pasa de largo mientras nos concentramos en algo más urgente (o, seamos sinceros, interesante).

Los especialistas en seguridad de las aplicaciones están en un lugar de influencia, y pueden forjar una situación beneficiosa a largo plazo defendiendo los intereses de los desarrolladores. Buscar una formación viable que sea relevante para el trabajo y que se imparta en sus lenguajes y marcos preferidos es un gran paso para cambiar la aguja e inspirar una cultura de seguridad positiva de base dentro de una organización. Llevamos décadas intentando lo mismo, y está claro que el enfoque de formación "de talla única" no funciona. Al ayudar a proporcionar las herramientas y los conocimientos adecuados a los desarrolladores, éstos pueden mejorar su capacitación en materia de codificación segura, actuar con un mayor sentido de la seguridad y producir un código de mayor calidad.

Los esfuerzos para llegar a la misma página deben venir de ambas partes.

Es fácil que personas con objetivos diferentes se malinterpreten o, en el peor de los casos, se vuelvan algo desconfiadas. El objetivo de AppSec es mantenerse al día con la avalancha de código que se produce, y encontrar cualquier problema de seguridad que pueda poner en peligro los datos, el acceso no autorizado y los ataques maliciosos que tienen el potencial de destruir el sentimiento positivo de los clientes durante años.

Los desarrolladores, entre otras cosas, construyen funciones con una fecha límite. Tienen la tarea de hacer que el software sea funcional y bonito, y de ser los creadores de experiencias digitales únicas que mantengan a los clientes fieles. Ya tienen mucho que hacer, y lanzarles una bola curva en forma de responsabilidad por la seguridad es una perspectiva desalentadora. Se considera que el problema de la seguridad del código es de AppSec, y aunque eso era algo factible en los años 90 (ya sabes, antes de que se pudieran hackear nuestros coches y de que pudiéramos llevar toda nuestra vida en un superordenador de bolsillo llamado teléfono inteligente), simplemente hay demasiado código y no hay suficientes personas que lo hagan pasar por el guante de la seguridad.

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

El respeto mutuo del tiempo tiene inmensos beneficios.

Como he dicho antes, todo el mundo está muy ocupado cuando se trata de hacer magia (es decir, software increíble). Los desarrolladores necesitarán un tiempo de trabajo asignado para realizar una formación viable y práctica que desarrolle sus habilidades de codificación segura, y cualquier programa de formación debería ser hiperrelevante por diseño.

El personal de seguridad de las aplicaciones pierde su tiempo solucionando las mismas vulnerabilidades del Top 10 de OWASP una y otra vez, y los desarrolladores tienen el suyo reducido con ejercicios de poco compromiso que refuerzan la idea en sus mentes de que la seguridad es una tarea.

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

Al crear un curso de codificación segura personalizado que se adapte a los resultados deseados y a los itinerarios de aprendizaje internos, se respeta el tiempo y el flujo de trabajo del desarrollador y, al mismo tiempo, se trabaja para lograr una reducción cuantificable de las vulnerabilidades y los riesgos de ciberseguridad para la empresa. Es una victoria rápida en la búsqueda de acabar con las rivalidades blandas y avanzar en el salvaje oeste de la ciberseguridad como un frente unido.

La última función de aprendizaje contextual deSecure Code Warrior, Coursesya está disponible.

‍