Si bien casi una de cada cinco empresas dice que está lanzando código 10 veces más rápido que en el pasado , más software significa más fallas de seguridad y más oportunidades para que los malos actores se aprovechen de ellas.
El ritmo más rápido y el aumento de los riesgos resaltan la necesidad de que los líderes de TI se tomen en serio la adopción de DevSecOps, un enfoque de gestión que hace que la seguridad sea una responsabilidad compartida entre los equipos de desarrollo, seguridad y operaciones de TI. Una indicación de que DevSecOps está ganando terreno en la empresa: casi la mitad de los equipos de desarrollo utilizaron herramientas de seguridad de aplicaciones en 2020, en comparación con poco menos del 30 % en 2015, según 451 Research , parte de S&P Global Market Intelligence.
DevSecOps es la metodología y la práctica de abordar la seguridad junto con el desarrollo y las operaciones desde el comienzo del proceso de desarrollo de software. La formación de estos equipos fomenta una responsabilidad compartida por la seguridad, así como un medio simplificado para identificar y corregir vulnerabilidades más rápidamente.
DevSecOps también crea una ventaja cultural para las organizaciones: promueve el intercambio de conocimientos y un entorno de todos para uno en el que los expertos del dominio aprenden unos de otros, dice Mandy Andress, directora de seguridad de la información de Elastic. Andress ha estado implementando prácticas y procesos de DevSecOps desde que se unió a la empresa en 2018.
Para los CISO que están considerando una transición a DevSecOps, aquí hay varias estrategias que los expertos recomiendan para guiar la implementación.
Adopte las tareas de seguridad antes
Históricamente, los ingenieros de software y los equipos de seguridad no han sido colaboradores cercanos. Para los desarrolladores, los profesionales de la seguridad están empeñados en ralentizar el rápido ritmo de los lanzamientos y actualizaciones de software. Los profesionales de la seguridad ven a los desarrolladores demasiado ansiosos por sacar el código sin tener en cuenta la gestión del riesgo.
DevSecOps fue concebido, en parte, para construir un puente entre las dos facciones. Un mandato central de DevSecOps es "desplazarse a la izquierda", lo que significa que las tareas de seguridad que podrían haber ocurrido más adelante en el ciclo de desarrollo, o en el extremo derecho de una línea de tiempo, se llevan a cabo al principio de la fase de diseño. Además, el desplazamiento a la izquierda consolida la ventaja cultural de integrar la seguridad en todos los aspectos del desarrollo y la implementación de productos.
Anteriormente, los equipos de seguridad no se involucraban para realizar pruebas de seguridad, una tarea que requería mucho trabajo, hasta que los desarrolladores escribieron su código. Con DevSecOps, esos equipos inician pruebas durante las primeras fases de desarrollo. Esto acelera el desarrollo general al identificar los agujeros de seguridad con suficiente antelación para evitar obligar a los ingenieros a volver atrás y realizar cambios sustanciales.
“La necesidad de que los desarrolladores y todos a lo largo del ciclo tengan habilidades básicas de seguridad se ha vuelto esencial”, dice Jayne Groll, directora ejecutiva del DevOps Institute, un grupo industrial que ofrece programas de capacitación y certificación para las prácticas de DevSecOps. “Ya no podemos ver la seguridad como una ocurrencia tardía”.
El valor de un campeón de alto rango
Al igual que cualquier cambio importante y amplio en el desarrollo de tecnología, DevSecOps debe ser impulsado por un ejecutivo de alto nivel, generalmente un CIO, CISO o un ejecutivo de ingeniería, dice Bill Curtis, director ejecutivo del Consorcio para la calidad del software de TI .
Si bien brindar acceso a las herramientas de seguridad de las aplicaciones es vital, también lo es el liderazgo sénior, asegurándose de que la seguridad sea una prioridad tan grande o mayor que las nuevas funciones. Un líder eficaz de DevSecOps puede insistir en que los equipos reserven tiempo (o incluso lanzamientos completos) solo para cerrar vulnerabilidades en lugar de introducir nuevas funciones, dice Curtis.
Compartir experiencia
Muchos equipos de desarrollo, seguridad y operaciones de TI necesitan ser inspirados, engatusados u obligados a compartir su experiencia, un desafío que las personas con habilidades altamente técnicas pueden encontrar difícil cuando trabajan fuera de su dominio.
Los líderes de equipo pueden ayudar, dice Groll, realizando sesiones para que todos los grupos entiendan el impacto comercial de los otros dos y asegurándose de que las métricas de todos tengan en cuenta la seguridad. Es más probable que los desarrolladores pidan consejo a sus contrapartes de seguridad, y es más probable que los equipos de seguridad lo den. “El mayor obstáculo para DevSecOps es tanto humano como técnico”, dice Groll. “Tenemos que sentirnos cómodos saliendo de nuestras zonas de confort tradicionales”.
“Solía ser que si tenías la tecnología correcta, eras bueno”, agrega Andress. “Los equipos de seguridad de hoy están mucho más motivados por la empatía y la comprensión del comportamiento humano”.
Mantente flexible
No existe un plan único para implementar DevSecOps, dice Andress. Más bien, los líderes deben establecer las barreras necesarias y dar a los equipos la libertad de operar dentro de ellas.
En Elastic, "pedimos a los equipos de seguridad que establezcan marcos sobre cómo deben operar las pruebas de seguridad y nos aseguramos de que los desarrolladores tengan las herramientas y los procesos adecuados para trabajar en estos marcos", dice Andress. “Entonces pueden determinar qué es lo mejor en términos de tiempo y qué procesos adoptar”.
La Marina de los EE. UU., por ejemplo, lanzó recientemente un programa DevSecOps con un proceso que se centró en cuestiones culturales en lugar de técnicas. El grupo nombró a tres líderes para defender las necesidades de productos, ingenieros y usuarios finales. Luego estableció el equipo multifuncional en su propia ubicación y realizó sesiones para desarrollar un "contrato social" sobre cómo interactuarían los miembros de diferentes disciplinas y cómo deseaban ser tratados. Usando el nuevo proceso en un primer proyecto, para crear una nueva herramienta para la programación de mantenimiento de aeronaves, la Marina completó un producto que cumplió con todos los requisitos de seguridad en solo seis meses.
Al igual que con cualquier cambio de cultura, la inercia corporativa puede interponerse en el camino. Eso es aún más cierto cuando se trata de fusionar tres culturas distintas en una sola. Pero dada la necesidad de mantener el ritmo de la innovación y mejorar la seguridad, es un desafío que muchas empresas ya no pueden posponer.