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

Una versión de este artículo apareció en Cyber Defense Magazine. Ha sido actualizado y distribuido aquí.

Una relación construida sobre los cimientos inestables de la desconfianza es, bueno, mejor abordarla con expectativas bajas. Lamentablemente, este puede ser el estado de la relación laboral entre los desarrolladores y el equipo de AppSec dentro de una organización. Generalmente fría y marcada por una tendencia a estorbarse mutuamente, la situación no es ideal y conduce a resultados deficientes en un mundo de dependencias tecnológicas de alto riesgo.

Los desarrolladores prosperan resolviendo problemas, creando funcionalidades y mostrando creatividad en su trabajo. AppSec, por otro lado, tiene la poco envidiable tarea de encontrar fallos de seguridad en su código, devolverlo para que lo corrijan y proporcionar auditorías e informes que empañan el brillo de los proyectos favoritos de los ingenieros. No es justo culpar únicamente a los desarrolladores (la seguridad no es su prioridad ni parte de sus KPI), ni tampoco se puede penalizar al sobrecargado equipo de AppSec por hacer simplemente su trabajo. Sin embargo, para lograr las mejores prácticas de ciberseguridad y mejores resultados de seguridad a nivel organizacional, realmente necesitan empezar a llevarse bien.

Y todo empieza con la confianza.

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

Si tus únicas interacciones con alguien ocurren cuando te señalan dónde te has equivocado, es muy probable que sus aportaciones no sean bien recibidas.

Al aparecer rara vez a menos que haya un problema, las connotaciones negativas de la presencia del equipo de seguridad tienden a causar fricción. La relación ha estado fracturada durante bastante tiempo, con los desarrolladores viendo al equipo de AppSec como un obstáculo para su creatividad, sus procesos y la entrega puntual de funcionalidades, mientras que AppSec se cansa de señalar continuamente fallos de seguridad comunes que han existido (al igual que sus soluciones) durante décadas.

Con plazos cada vez más imposibles, equipos con pocos recursos y un fuerte deseo de evitar el retrabajo, los desarrolladores a menudo esperan 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. Es un proceso disfuncional que tiene un impacto inaceptable al aumentar el riesgo de ciberseguridad para la organización.

Para los especialistas en seguridad, es un caso de "no disparen al mensajero": después de todo, su trabajo es encontrar fallos e informarlos para que puedan ser remediados; no es nada personal. El problema es que a menudo pueden hacer recomendaciones que no se ajustan bien a la pila tecnológica de la empresa, por lo que pueden considerarse poco útiles en el panorama general del desarrollo de software interno.

La idea 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 ha ido mucho más allá de Waterfall, Agile e incluso DevOps, hacia un proceso que considera la seguridad como una responsabilidad compartida desde el principio del ciclo de vida de desarrollo de software (SDLC) como algo vital.

Para que DevSecOps funcione, los ingenieros de software necesitan una razón para preocuparse por la seguridad, y eso proviene de entender por qué es tan importante que hagan su parte para asegurar el software del mundo. Los especialistas en seguridad que se esfuerzan por tender puentes, trabajar con los gerentes de desarrollo para satisfacer las necesidades del equipo y asumir un papel más de mentoría en el fomento de la conciencia de seguridad tienden a ver beneficios a largo plazo de sus esfuerzos... y pasan un poco menos de tiempo arrancándose los pelos por otro error XSS más.

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

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

Con ese fin, la formación en el trabajo suele ser el primer contacto que tendrá un desarrollador con el arte de la seguridad del software, y rara vez resulta inspirador. Las horas de vídeos aburridos son un método de formación común, al igual que los ejercicios de cumplimiento de "marcar la casilla" que son demasiado infrecuentes para tener un impacto real en la enseñanza de cómo codificar de forma segura o para avanzar en la reducción de vulnerabilidades comunes en el software de una organización.

Tanto el equipo de AppSec como el grupo de desarrollo están increíblemente 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 ponernos manos a la obra, por lo que la mayor parte de la formación estática simplemente pasa de largo mientras nos concentramos en algo más urgente (o, seamos sinceros, interesante).

Los especialistas en AppSec están en una posición de influencia y pueden forjar una situación beneficiosa para todos a largo plazo abogando por los mejores 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 las cosas e inspirar una cultura de seguridad positiva y desde la base dentro de una organización. Hemos intentado lo mismo durante décadas y, claramente, el enfoque de formación de "talla única" no funciona. Al ayudar a proporcionar las herramientas y el conocimiento adecuados a los desarrolladores, estos pueden mejorar con éxito sus habilidades en codificación segura, actuar con un mayor sentido de conciencia de seguridad y producir un estándar de código más alto.

Los esfuerzos para estar en la misma sintonía deben provenir de ambas partes.

Es fácil que personas con objetivos distintos se malinterpreten o, en el peor de los casos, empiecen a desconfiar. El objetivo de AppSec es seguir el ritmo del aluvión de código que se genera y detectar problemas de seguridad que puedan derivar en filtraciones de datos, accesos no autorizados y ataques malintencionados capaces de destruir la confianza de los clientes durante años.

Los desarrolladores, entre otras cosas, crean funciones cumpliendo plazos. Su tarea es hacer que el software sea funcional y atractivo, siendo los artífices de experiencias digitales únicas que fidelizan a los clientes. Ya tienen mucho entre manos, y plantearles el reto de asumir la responsabilidad de la seguridad es una perspectiva desalentadora. Se considera que asegurar el código es problema de AppSec, y aunque eso era algo factible en los 90 (ya sabes, antes de que nuestros coches pudieran ser hackeados y nuestras vidas enteras pudieran llevarse en un superordenador de bolsillo llamado smartphone), simplemente hay demasiado código y muy pocas personas para someterlo al examen de seguridad.

Con una buena dosis de empatía y la capacitación necesaria para priorizar la seguridad desde el inicio del proceso de creación de software, AppSec y los desarrolladores pueden alinear sus objetivos. Al fin y al cabo, una cultura de seguridad positiva depende de ello, y los desarrolladores concienciados con la seguridad son el ingrediente secreto para detener las vulnerabilidades comunes, incluso ante una escasez de competencias en ciberseguridad cada vez mayor.

El respeto mutuo por el tiempo tiene inmensos beneficios.

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

AppSec pierde el tiempo corrigiendo las mismas vulnerabilidades del OWASP Top 10 una y otra vez, y los desarrolladores ven cómo el suyo se consume con ejercicios poco atractivos que refuerzan la idea de que la seguridad es una tarea tediosa.

Las experiencias de aprendizaje seleccionadas son vitales y ayudan a ir al grano mediante una entrega contextual y breve de formación relevante, justo en el momento en que se necesita.

Al crear un curso de codificación segura personalizado, adaptado a los resultados deseados y a las rutas de aprendizaje internas, se respeta el tiempo y el flujo de trabajo del desarrollador, al tiempo que se trabaja para lograr una reducción medible 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 y avanzar hacia el salvaje oeste de la ciberseguridad como un frente unido.

La nueva función de aprendizaje contextual de Secure Code Warrior, Courses, ya está disponible.

‍