¿Está su organización realmente preparada para DevSec? Póngalo a prueba.

Apenas hemos llegado a la mitad de 2020 y, sin embargo, ya estamos en camino de establecer un sombrío récord de violación de datos, viendo un aumento del 273% en los datos robados en comparación con la primera mitad de 2019. En estos días, es más preciso preguntarse cuántos datos no han sido robados todavía. Con acontecimientos mundiales como la pandemia del COVID-19, estos ataques no han hecho más que aumentar en frecuencia y potencia, con objetivos cada vez más vulnerables.

Esto es algo que todos sabemos desde hace tiempo: la seguridad ya no es opcional, y nuestro enfoque debe ser un ataque preventivo. Para que esto sea efectivo, todo el mundo en el SDLC debe ser consciente de la seguridad, especialmente los desarrolladores. Esta es la parte "DevSec" de DevSecOps, una metodología de desarrollo de software ideal para el clima, pero muchas organizaciones no están totalmente preparadas para ejecutarla con eficacia.

Con su organización en mente, piense en estas preguntas en el contexto de su función. ¿Cómo le iría cuando se le sometiera a la prueba de DevSec?

DevSec Self-Assessment: ¿Está su jardín de SDLC preparado para que florezcan ingenieros conscientes de la seguridad?

1. ¿Está la seguridad en primer plano en el proceso de desarrollo interno?
   Una serie de factores de riesgo de ciberseguridad pueden mantener al CISO medio despierto por la noche, pero la realidad preocupante es que mientras muchas empresas están haciendo de la seguridad una prioridad, su enfoque interno puede no ser lo suficientemente robusto como para mitigar un posible desastre (o, al menos, enormes dolores de cabeza para el equipo de AppSec y el retraso en el envío del software).
   DevSecOps puede ser el estado actual del nirvana de la seguridad, pero pocas empresas están trabajando con esta metodología. Si todavía estás en Agile - o incluso en Waterfall - entonces la seguridad es a menudo considerada como el dominio de los especialistas que están lejos del proceso y se activan tarde en el SDLC, apareciendo para arruinar el día de un desarrollador con hotfixes para su código. En un entorno como éste, va a ser un reto impulsar una cultura de DevSec: los desarrolladores adoran y dan prioridad a la creación de características, y simplemente no habrán tenido suficiente experiencia práctica con la seguridad para verla como una vía de mejora deseable. De hecho, sus contactos con ella pueden ser de frustración y negatividad. Esto debe remediarse rápidamente para inculcar un enfoque de primera línea a todos los que participan en el proceso de desarrollo de software.
   
2. ¿Su organización todavía está jugando a ponerse al día en lo que respecta al modelado de amenazas?
   Es una estadística aleccionadora que el 60% de las PYMES cierran el negocio en los seis meses siguientes a un ciberataque exitoso, y al igual que otros desastres, el impacto es mucho mayor si no se planifica adecuadamente.
   El modelado de amenazas es un elemento crucial de las mejores prácticas de seguridad, que permite a los profesionales de AppSec evaluar el alcance completo de la superficie de ataque y estructurar las defensas, contramedidas y planificación adecuadas. En las empresas que han adoptado plenamente el DevSecOps, la seguridad se habilita en una fase temprana de la cadena de producción continua (CI/CD), de manera que no se ralentiza la producción tanto como en el pasado. La seguridad, la codificación segura y la entrega continua forman parte del proceso, y los equipos de desarrollo reciben los recursos y la exposición necesarios para ser componentes principales del motor que escupe código hermético.
   
3. ¿Priorizan los directores de desarrollo las mejores prácticas de seguridad?
   Les guste o no, los directores de desarrollo son un modelo para su equipo. Y no se trata sólo de cosas de cultura y ambiente, como llevar chanclas a la oficina o cómo "gestionan hacia arriba". Sus prioridades de trabajo serán inevitablemente absorbidas por los miembros de su equipo, y si la seguridad no forma parte de los objetivos clave, o no se planifica en términos de formación y apoyo, entonces los ingenieros que están por debajo de ellos se perderán, y el negocio estará más en riesgo de lo que debería.
   
4. ¿Se les da a los desarrolladores una razón para preocuparse porla seguridad?
   En mi experiencia, la forma más rápida de poner a alguien fuera de juego es decirle que tiene que hacer algo que es ajeno a su enfoque actual, sin decirle por qué.
   
   Que se les diga que "cambien" implica que el enfoque anterior era erróneo, cuando en muchos casos, se trata simplemente de una mejora que, con suerte, hará las cosas más fáciles y eficientes más adelante. Para adoptar realmente el movimiento DevSec, los desarrolladores deben tener una razón para preocuparse por la seguridad en primer lugar; después de todo, en la mayoría de las organizaciones, sigue siendo en gran medida "un problema de otros" (es decir, de los magos de AppSec encerrados en otra habitación, muy, muy lejos).
   
   DevSecOps simplemente no funciona si la seguridad no es una responsabilidad compartida. Los desarrolladores necesitan las herramientas, el apoyo y la formación adecuados para hacer su parte... y esto requiere tiempo para desplegar y perfeccionar como parte de un programa de seguridad global. El peor enfoque es el que abruma y aliena, lo que puede ocurrir cuando los desarrolladores tienen demasiadas prioridades que compiten entre sí y ninguna ayuda para gestionarlas sin volverse locos. Se trata de un cambio cultural, y no es de un día para otro.
   
5. ¿Confía usted en un puñado de unicornios mágicos de la seguridad para que se encarguen de la tarea de muchos?
   Los profesionales de la seguridad son muy escasos, y necesitamos muchos más de los que hay actualmente. Esto es un hecho, pero cada vez hay más desarrolladores que pasan a desempeñar funciones más centradas en la seguridad. Normalmente, pueden tener títulos como "ingeniero de seguridad" o "ingeniero de DevOps" (poco a poco, veremos cómo este título se convierte en ingeniero de DevSecOps, con un poco de suerte). Un ingeniero de DevOps es capaz de desarrollar características para prácticamente cualquier aplicación, mientras que el despliegue utilizando una verdadera tubería de CI / CD. Lo hacen todo de principio a fin, y normalmente vienen con una buena dosis de conciencia de seguridad. En ese sentido, son algo mágico y, por tanto, poco frecuente.
   
   Sin embargo, algunas empresas cometen el error de contratar a estos ingenieros especializados, colocándolos en un equipo y esperando que se ocupen de todos los problemas de seguridad, en cada etapa del proceso de desarrollo, y que esto sea la única solución. Sobrecargue a sus magos de DevSecOps y acabará donde empezó: enviando código inseguro sin las comprobaciones, los equilibrios y la precisión de seguridad para los que fueron contratados en primer lugar. Es de suma importancia que el equipo de desarrollo en general esté capacitado y se nutra de un entorno de seguridad positivo para que esté equipado para compartir la carga de manera significativa.

Encuentre el cambio que quiere ver en su organización.

Si implementa una formación sólida como parte de su programa de seguridad, descubrirá algunas joyas ocultas en su cohorte de desarrollo. Estas son las personas que, a pesar de las experiencias negativas que puedan haber tenido en su trabajo diario, tienen algo de pasión por la codificación segura y las mejores prácticas de seguridad. Estas personas son los principales candidatos a campeones de la seguridad dentro del equipo; un punto de contacto entre la seguridad y la ingeniería que da un gran ejemplo a los demás, mantiene la concienciación y ayuda en las iniciativas de compromiso. Sus habilidades interpersonales también son muy importantes para difundir la alegría de la seguridad a lo largo y ancho, y para defender las necesidades de los desarrolladores ante la dirección y el equipo de seguridad.

La conversación "¿qué me aporta?" es un paso positivo.

Incluso el más noble de los humanos necesita algo de "zanahoria" para sumergirse en un territorio desconocido, o en una actividad que puede no tener la más agradable de las curvas de aprendizaje.
Dar el salto de "dev" a "DevSec" es un impulso impresionante para la carrera de un desarrollador. Los desarrolladores concienciados con la seguridad se han esforzado por comprenderla, asumir la responsabilidad de la misma en las áreas que pueden controlar y operar con el entendimiento de que el único código de calidad es el código seguro. Por lo general, los desarrolladores quieren mejorar, abordar nuevos problemas y crear características envidiables que les ayuden a destacar entre sus compañeros. Si se les ofrece una vía para alcanzar un nivel superior de desarrollo de software, todos saldrán ganando.

Nunca es demasiado tarde para crear el equipo de ensueño de DevSec.

Si dirige a los desarrolladores, dirige un equipo de concienciación sobre la seguridad de las aplicaciones o es una de las muchas mentes que trabajan arduamente para idear estrategias de programas de seguridad, ahora es el momento de ir más allá del "cambio" a la izquierda. Con la formación, las herramientas y el entorno adecuados, puede crear una incubadora de seguridad para los desarrolladores que dará grandes beneficios a todas las partes. Si esta lista de comprobación ha puesto de manifiesto algunas áreas de mejora, entonces tiene una gran oportunidad de preparar a su organización para un departamento de ingeniería dirigido por DevSec que pueda reducir el riesgo desde el principio del SDLC.