Cambiar a la izquierda no es suficiente: por qué empezar a la izquierda es la clave para lograr la excelencia en la seguridad del software

En un mundo impulsado por la digitalización, corremos un riesgo cada vez mayor de robo de datos. Dado que las grandes organizaciones actúan como guardianas de nuestra valiosa información, muchas reconocen la necesidad de implementar estándares de seguridad estrictos.

Gran parte de la iniciativa en torno a «cambiar a la izquierda», es decir, introducir la seguridad mucho antes en el proceso de desarrollo, simplemente no avanza lo suficiente. Esto implica que todavía estamos iniciando el proceso por el camino equivocado y, en última instancia, dando marcha atrás para lograr el resultado de un software más seguro. Debemos empezar por la izquierda, promulgando un cambio cultural que involucre positivamente a los equipos de desarrollo y los dote de los conocimientos de los que carecen actualmente. Sin embargo, no todas las capacitaciones y herramientas son iguales.

En este artículo, analizamos las formas en que los líderes clave, como los gerentes de desarrollo y concientización sobre seguridad, pueden empoderar realmente a su cohorte de desarrolladores, transformándolos en la primera línea defensiva contra los costosos ciberataques.

Cambiar a la izquierda frente a empezar a la izquierda: una distinción importante.

En la era de las frecuentes filtraciones de datos que afectan a algunas de las organizaciones más confiables del mundo, los líderes de las empresas han recurrido al sector de la seguridad para que les brinde orientación sobre cómo evitar el desastre financiero, reputacional y espectacular que supone un ataque exitoso.

Durante bastante tiempo, los especialistas de AppSec (incluido yo mismo) hemos dicho que, de hecho, debemos «desplazarnos a la izquierda». De acuerdo con las mejores prácticas de DevOps y con mejores resultados en materia de seguridad del software, muchos de nosotros hemos dicho que la parte de seguridad de una compilación de software debe estar incluida en una fase más temprana del ciclo de vida del desarrollo del software (SDLC). No debería ser el último y costoso paso, sino que debería situarse más cerca del inicio del proceso, con la participación de los equipos de AppSec desde el principio, a medida que los proyectos de software vayan cobrando vida.

Esto no es mala consejo, y sin duda es mejor que la forma anterior de hacer las cosas (que, si la cantidad de datos robados que existen y la antigüedad de las vulnerabilidades utilizadas para el atraco son un indicio, no funciona de todos modos). Sin embargo, si realmente iniciado De izquierda a derecha, los resultados en materia de seguridad serían mucho más positivos.

Cambie a la izquierda, comience a la izquierda... ¿cuál es la diferencia? La diferencia radica en la forma en la que interactúas con tu equipo de desarrollo. En verdad, son la clave para ofrecer un software más seguro y mucho más económico de lo que pueden gestionar las cadenas de herramientas de ciclo avanzado y la revisión manual del código. En un mundo ideal, todos los desarrolladores que escriban software tendrían los conocimientos y las herramientas para programar de forma segura desde el principio. Detectarían las posibles fallas y las mitigarían antes de que se cometan (y, por lo tanto, sería mucho más costoso eliminarlas y corregirlas). Habría una reducción drástica de los errores de seguridad que hemos visto durante décadas, unos que sí Aún así responsable de permitir que los atacantes entraran por la puerta trasera. Se cerrarían esas ventanas de oportunidad en forma de inyección de SQL, secuencias de comandos entre sitios y autenticación interrumpida.

Sin embargo, en este momento, simplemente no se hace suficiente hincapié en la seguridad a nivel vocacional, y la formación de programación segura en el trabajo varía enormemente. Como resultado, los desarrolladores rara vez tienen lo que necesitan para que una organización pueda empezar por la izquierda. Es hora de que quienes ocupan puestos de liderazgo trabajen juntos y aboguen por una mayor concienciación sobre la seguridad, ya que su conocimiento directo y su contacto con los desarrolladores son fundamentales para impulsar programas que funcionen. Al fin y al cabo, los directores de desarrollo alguna vez estuvieron sentados en su posición, con las herramientas y con el espacio de seguridad difícil de manejar en el mejor de los casos.

A los desarrolladores no les encanta la seguridad (todavía)... pero puedes cambiar la conversación.

Ya sabes cómo funciona: si le dices «seguridad» a un desarrollador típico, es probable que te pongas los ojos en blanco en el mejor de los casos o te quedes perplejo en el peor. Por lo general, todo el tema de la seguridad se considera un problema de otra persona.

Un desarrollador tiene la responsabilidad principal de crear un software que sea funcional, repleto de funciones innovadoras y entregado dentro de un plazo de proyecto ajustado. La seguridad rara vez es una prioridad a nivel de programación, e incluso puede considerarse un tedioso obstáculo para acelerar la entrega y dar rienda suelta a la creatividad. AppSec tiene la tarea de comprobar meticulosamente el código, hacer pruebas con bolígrafos y, a continuación, dar a conocer las malas noticias: la presencia de vulnerabilidades de seguridad en un código que, con frecuencia, ya está codificado y que, por lo demás, funciona bastante bien. Se trata de un proceso caro en un entorno en el que a menudo se agotan los recursos y el tiempo necesarios, ya que la configuración puede provocar divisiones entre dos equipos que, en última instancia, tienen el mismo objetivo, pero hablan idiomas completamente diferentes.

Ahora, en este clima, es probable que la recepción de la formación obligatoria en materia de seguridad sea bastante fría. Sin embargo, la capacidad de despertar una mentalidad de seguridad en todos los desarrolladores no es una quimera. Con la formación y el soporte adecuados, pueden empezar a incorporar la seguridad a su software y asumir la responsabilidad de los resultados de seguridad que pueden controlar. Si los desarrolladores pueden solucionar por sí mismos los errores más comunes, se liberará a los costosos especialistas para resolver los problemas realmente complejos. Y si estás en la posición de gestionar un equipo de desarrollo, puedes ser fundamental para ayudar a cerrar esta brecha y ayudar a tu equipo a ver los beneficios.

No todos los entrenamientos son iguales.

¿Cuándo fue la última vez que te emocionaste mucho por aprender algo nuevo? Cuando lo hiciste, es probable que no te vengan a la mente palabras como «obligatorio», «cumplimiento» o «diecisiete horas de vídeo».

Los desarrolladores no son diferentes. Son inteligentes, creativos y les encanta resolver problemas. Es muy poco probable que ver un sinfín de vídeos sobre las vulnerabilidades de seguridad les atraiga, haga que el contenido sea memorable o acabe dedicándose específicamente a sus funciones y responsabilidades diarias. Cuando era instructor de SANS, muy pronto me di cuenta de que la mejor formación era la práctica, ya que obligaba a los participantes a analizar y a enfrentarse a desafíos intelectuales, utilizando ejemplos del mundo real que ponían a prueba su cerebro y se basaban en el aprendizaje previo. La gamificación y la competencia amistosa también son herramientas poderosas para que todos se familiaricen con los nuevos conceptos, sin dejar de ser útiles y prácticos en su aplicación.

Otro factor que asusta es que gran parte de la formación en seguridad no se supervisa. A nadie le gusta sentir que el Gran Hermano nos observa, pero ¿de qué sirve dedicar tiempo, dinero y esfuerzo a la educación si nadie comprueba si es relevante?

La solución adecuada puede hacer que la codificación segura sea divertida, relevante, atractiva y medible. Desafíe a sus desarrolladores, trátelos bien y conviértalo en un evento especial. La formación basada en juegos ilumina los centros de recompensa del cerebro y, al ofrecer un incentivo para seguir aprendiendo, superar los límites del conocimiento y, sencillamente, crear un estándar de software más alto, es una situación en la que todos salen ganando.

Control de salud de la cultura de seguridad: ¿la suya está en soporte vital?¿t?

Crear software seguro en un entorno con una cultura de seguridad deficiente es como intentar ganar una maratón con una roca encadenada al tobillo: prácticamente imposible e innecesariamente difícil.

La formación basada en juegos, los torneos cara a cara y el compromiso de ayudar a los desarrolladores a aumentar su seguridad ayudan enormemente a impulsar una cultura de seguridad positiva, ya que los equipos de desarrollo y AppSec obtienen mucha más información sobre el trabajo diario de los demás. Las mejores relaciones crecen y prosperan, y el presupuesto de seguridad (a menudo limitado) no se gasta en arreglar el escenario del «Día de la Marmota», en el que se repiten los mismos pequeños y molestos errores una y otra vez.

También hay otro poderoso subproducto: el descubrimiento de los campeones de la seguridad que no sabías que tenías. Una formación adecuada que involucre a todos y, al mismo tiempo, permita una evaluación exhaustiva, puede descubrir a aquellos que no solo tienen aptitudes para la seguridad, sino que muestran una pasión por ella de manera activa. Estos campeones son fundamentales para mantener el impulso y actuar como punto de contacto entre los equipos, supervisar a los compañeros y defender las políticas de mejores prácticas. La implementación de un programa de promoción sólido, que incluya el reconocimiento y el apoyo de los ejecutivos, es un tanto a favor de la organización, además de tener un aspecto impresionante en el currículum de la persona e impulsar su futura carrera.

Cuando se compromete con una cultura de seguridad positiva, la responsabilidad se comparte y se puede lograr un mayor nivel de excelencia en el software seguro. En última instancia, todas las personas que participan en el ciclo de vida del desarrollo de software deben seguir un mantra sencillo: si no se trata de un software seguro, no es un buen software.

Difunde la palabra.