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

En un mundo digitalizado, el riesgo de robo de datos es cada vez mayor. Dado que las grandes organizaciones actúan como guardianes de nuestra valiosa información, muchas reconocen la necesidad de aplicar estrictas normas de seguridad.

Gran parte de las iniciativas en torno al "giro a la izquierda", es decir, la introducción de la seguridad en una fase mucho más temprana del proceso de desarrollo, simplemente no mueven la aguja lo suficiente. Esto implica que seguimos comenzando el proceso de forma incorrecta y que, en última instancia, retrocedemos 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 arme con los conocimientos de los que actualmente carecen. Sin embargo, no todas las formaciones y herramientas son iguales.

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

Desplazamiento a la izquierda vs. inicio 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 fiables del mundo, los líderes de las empresas han recurrido al sector de la seguridad para que les oriente sobre cómo evitar el desastre financiero, de reputación y de espectáculo que supone un ataque con éxito.

Durante bastante tiempo, los especialistas en seguridad de aplicaciones (entre los que me incluyo) han aconsejado que debemos "cambiar a la izquierda". En consonancia con las mejores prácticas de DevOps, así como con los mejores resultados de la seguridad del software, muchos de nosotros aconsejamos que la parte de seguridad de una construcción de software debe venir antes en el ciclo de vida de desarrollo de software (SDLC). No debería ser el último y costoso paso, sino que debería acercarse más al inicio del proceso, con la participación de los equipos de seguridad de las aplicaciones en las primeras fases de los proyectos de software.

No es un mal consejo, y ciertamente es mejor que la antigua forma de hacer las cosas (que, si la cantidad de datos robados y la antigüedad de las vulnerabilidades utilizadas para robarlos son una indicación, no está funcionando de todos modos). Sin embargo, si empezáramos realmente por la izquierda, los resultados en materia de seguridad serían mucho más positivos.

Desplazamiento a la izquierda, inicio a la izquierda... ¿cuál es la diferencia? La diferencia radica en la forma de involucrar a su equipo de desarrollo. Verdaderamente, ellos son la clave para entregar un software más seguro, mucho más barato de lo que pueden gestionar las cadenas de herramientas de ciclo posterior y la revisión manual del código. En un mundo ideal, todos los desarrolladores que escriben software tendrían los conocimientos y las herramientas para codificar de forma segura desde el principio. Detectarían los posibles fallos y los mitigarían antes de que se comprometan (y, por tanto, sean mucho más caros de eliminar y arreglar). Se reducirían drásticamente los fallos de seguridad que hemos visto durante décadas y que siguen siendo los responsables de que los atacantes entren por la puerta de atrás. Se cerrarían esas ventanas de oportunidad en forma de inyección SQL, cross-site scripting y autenticación rota.

Sin embargo, en este momento, simplemente no hay suficiente énfasis en la seguridad a nivel profesional, y la formación en codificación segura en el trabajo varía mucho. Como resultado, los desarrolladores rara vez tienen lo que necesitan para que una organización comience a salir. Ha llegado el momento de que quienes ocupan puestos de liderazgo colaboren y aboguen por una mayor concienciación en materia de seguridad, ya que su conocimiento y contacto directo con los desarrolladores es vital para impulsar programas que funcionen. Al fin y al cabo, los responsables de desarrollo estuvieron una vez en su puesto, sobre las herramientas y con el espacio de seguridad difícil de navegar en el mejor de los casos.

Los desarrolladores no adoran la seguridad (todavía)... pero usted puede cambiar la conversación.

Ya sabes lo que pasa: si mencionas la palabra "seguridad" a un desarrollador típico, lo más probable es que se te mire con cara de asombro, en el mejor de los casos, o con perplejidad, en el peor. Por lo general, todo el tema de la seguridad se ve como un problema de otros.

Un desarrollador tiene la responsabilidad principal de construir un software que sea funcional, rebosante de características innovadoras y que se entregue dentro de un apretado calendario de proyectos. La seguridad no suele ser una prioridad a nivel de codificación, e incluso puede considerarse un tedioso obstáculo para la entrega rápida y la creatividad. El departamento de seguridad de las aplicaciones tiene la tarea de comprobar meticulosamente el código, realizar pruebas de penetración y, a continuación, informar de las malas noticias: la presencia de vulnerabilidades de seguridad en un código que, a menudo, ya está comprometido y que, por lo demás, funciona bastante bien. Se trata de un proceso costoso en un entorno que a menudo tiene pocos recursos y tiempo, y cuya configuración está destinada a provocar una ruptura entre dos equipos que, en última instancia, tienen el mismo objetivo, pero que hablan idiomas completamente diferentes.

Ahora, en este clima, es probable que la recepción de la formación obligatoria en seguridad sea bastante fría. Pero el poder de encender una mentalidad de seguridad en cada desarrollador no es una quimera. Con la formación y el apoyo adecuados, pueden empezar a incorporar la seguridad a su software y asumir la responsabilidad de los resultados de seguridad que pueden controlar. Si los propios desarrolladores pueden ocuparse de los errores comunes, eso libera a los costosos especialistas para que solucionen los problemas verdaderamente complejos. Y si usted está en la posición de dirigir un equipo de desarrollo, puede ser fundamental para ayudar a cerrar esta brecha y ayudar a su equipo a ver los beneficios.

No toda la formación es igual.

¿Cuándo fue la última vez que se entusiasmó por aprender algo nuevo? Cuando lo hiciste, probablemente no te vinieron a la cabeza palabras como "obligatorio", "cumplimiento" o "diecisiete horas de vídeo".

Los desarrolladores no son diferentes. Son inteligentes, creativos y les encanta resolver problemas. Es bastante improbable que ver interminables vídeos sobre vulnerabilidades de seguridad vaya a engancharles, que el contenido sea memorable o que acabe siendo específico para sus funciones y responsabilidades diarias. En mi tiempo como instructor de SANS, se hizo evidente muy pronto que la mejor formación es la práctica, obligando a los participantes a analizar y a ser desafiados intelectualmente, utilizando ejemplos del mundo real que ponen a prueba su cerebro y se basan en el aprendizaje previo. La ludificación y la competición amistosa son también herramientas poderosas para que todo el mundo asuma 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 está supervisada. A nadie le gusta tener la sensación de que el Gran Hermano está mirando, pero ¿de qué sirve gastar tiempo, dinero y esfuerzo en la formación si nadie comprueba si es pertinente?

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 gamificada enciende los centros de recompensa del cerebro y ofrece un incentivo para seguir aprendiendo, superar los límites del conocimiento y, sencillamente, construir un software de mayor calidad.

Chequeo de la cultura de seguridad:¿Estála suya consoportevital?

Crear un 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 gamificada, el cara a cara en tournaments y el compromiso de ayudar a los desarrolladores en su crecimiento en materia de seguridad ayudan enormemente a impulsar una cultura de seguridad positiva, ya que los equipos de seguridad de las aplicaciones y los equipos de desarrollo adquieren mucha más información sobre el trabajo diario del otro. Las relaciones crecen y prosperan, y el (a menudo limitado) presupuesto de seguridad no se agota en arreglar un "Día de la Marmota" con 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 todo el mundo, al tiempo que permite una exhaustiva assessment, puede descubrir a aquellos que no sólo tienen una aptitud para la seguridad, sino que muestran activamente una pasión por ella. Estos campeones son vitales para mantener el impulso y actuar como punto de contacto entre los equipos, supervisar a los compañeros y mantener las políticas de mejores prácticas. Poner en marcha un sólido programa de campeones, que incluya el reconocimiento y el apoyo de los directivos, es un orgullo para la organización, además de quedar muy bien en el currículum de la persona y reforzar su futura carrera.

Cuando uno se compromete con una cultura de seguridad positiva, la responsabilidad es compartida y se puede alcanzar un mayor nivel de excelencia en el software seguro. En última instancia, cada persona del ciclo de vida del desarrollo de software debe adherirse a un sencillo mantra: si no es un software seguro, no es un buen software.

Corre la voz.