Fundamentos de seguridad en la nube, parte 3: Empodera a tus desarrolladores

En nuestra publicación anterior, donde analizamos Los 5 fundamentos de seguridad en la nube, vimos el valor de la prevención y el diseño seguro. Mapear las relaciones entre los recursos y aplicar barreras de seguridad durante todo el desarrollo ayuda a reducir considerablemente la superficie de ataque disponible. Pero ¿quién aplicará estas barreras cuando el equipo de seguridad esté ocupado con otras tareas? Aquí es donde los desarrolladores deberían poder intervenir. Veamos otro elemento fundamental de la seguridad en la nube: empoderar a los desarrolladores. 

En 2013, los autores Gene Kim, Kevin Behr y George Spafford escribieron el libro sobre DevOps: The Phoenix Project. El objetivo del libro era promover DevOps, pero su trabajo resultó ser más profético de lo que imaginaron, sobre todo en lo que respecta a la seguridad en la nube. 

DevOps buscaba integrar mejor a los equipos de operaciones de TI en el ciclo de vida del desarrollo de software (SDLC) y permitir que los equipos crearan e implementaran una mejor infraestructura a un ritmo más rápido. Los equipos de operaciones de TI aprendieron a entender las presiones del desarrollo, pero quizás lo más importante fue que los desarrolladores aprendieron a planificar y desarrollar aplicaciones e infraestructura en conjunto, con una visión más integral.

Es probable que hayas escuchado un término nuevo: DevSecOps. Este término surgió por muchas razones, pero hay una que destaca entre las demás. Gene Kim explica:

La proporción de ingenieros de Desarrollo, Operaciones y Seguridad de la Información en una organización tecnológica típica es de 100:10:1. Cuando el equipo de seguridad de la información está tan superado en número, sin automatización ni integración de la seguridad de la información en el trabajo diario de Desarrollo y Operaciones, solo puede hacer verificaciones de cumplimiento, lo opuesto a la ingeniería de seguridad.

En esencia, esta proporción revela la prioridad número uno de muchas empresas: crear software, no protegerlo. La solución es empoderar a los desarrolladores para que incorporen la ingeniería de seguridad en sus flujos de trabajo de desarrollo.

En este artículo, presentamos tres principios que los líderes de la nube pueden usar para empoderar a sus desarrolladores y lograr una postura de seguridad más sólida y menos costosa.

1. Usa infraestructura como código siempre que sea posible

El software no solo conquistó el mundo: también conquistó la nube.

Ahora la infraestructura en la nube puede ser 100 % software; de hecho, para los clientes de la nube, la infraestructura en la nube es 100 % software. Con herramientas de infraestructura como código, como Terraform y AWS CloudFormation, los desarrolladores pueden crear y administrar entornos en la nube mediante programación.

En el pasado, la seguridad en la nube era una actividad aislada, como la mayoría de las funciones de seguridad. Los equipos de seguridad se veían obligados a usar herramientas de administración de la postura de seguridad en la nube (CSPM) para analizar los entornos en ejecución que aprovisionaban los equipos de ingeniería. Luego, los equipos de seguridad identificaban errores de configuración, los priorizaban según su gravedad y asignaban tareas de corrección a los equipos de DevOps.

Pero salió a la luz un problema importante: los errores de configuración, al igual que otros problemas de seguridad, solo se pueden detectar después de que ocurren. Un estudio de IBM de 2017 explicó una de las razones por las que esto es problemático: “Corregir un error de software detectado durante la fase de pruebas puede costar hasta 15 veces más que corregir el mismo error si se detecta durante la fase de diseño”.

La infraestructura como código cambia la conversación. Al permitir que los equipos de desarrollo definan mediante código la configuración de sus entornos en la nube, las empresas pueden adelantar la seguridad, es decir, trasladar el trabajo de seguridad a etapas más tempranas del SDLC de la infraestructura en la nube.

Así, las verificaciones de seguridad pueden realizarse antes de la implementación. El resultado: menos errores de configuración en tiempo de ejecución, menos errores en producción y una postura de seguridad mucho más sólida, en menos tiempo.

2. Prioriza las integraciones con herramientas para desarrolladores

A veces, la seguridad tiene mala reputación entre los desarrolladores porque suele consistir en una serie de pasos que las empresas agregan al final del SDLC, lo que obliga a los desarrolladores a realizar mucho trabajo manual. No solo es más difícil detectar errores y otros defectos en etapas posteriores, sino que también es más difícil identificarlos y corregirlos, y a menudo se necesita un retrabajo costoso y que consume mucho tiempo.

La clave está en encontrar herramientas que ofrezcan integraciones completas y relevantes, y usarlas para incorporar capacidades de seguridad al flujo de trabajo de desarrollo. El objetivo no es cambiar la forma de trabajar de los desarrolladores, sino integrar la seguridad en la forma en que ya trabajan.

Enfócate en integrar las verificaciones de seguridad con las herramientas para desarrolladores, los repositorios de código fuente y las cadenas de herramientas de CI/CD. Además, cuando busques herramientas de seguridad, considera tanto la variedad de integraciones disponibles como su calidad. Ambas serán necesarias para que la seguridad sea una parte integral del flujo de trabajo de desarrollo. Las herramientas de seguridad para desarrolladores solo sirven si tus desarrolladores las usan.

3. Ofrece orientación útil a los desarrolladores

DevSecOps no es solo un beneficio adicional. Cuando los desarrolladores cuentan con infraestructura como código e integraciones estrechas con herramientas de seguridad, pueden mejorar cada vez más en ingeniería de seguridad. A medida que los empoderas y les das las herramientas para aprovechar ese poder, sus capacidades empiezan a escalar.

Con infraestructura como código, los desarrolladores pueden aprender a crear entornos seguros desde el punto de vista de la arquitectura. Y cuando las empresas incorporan enfoques de DevSecOps en sus programas de seguridad en la nube, los ingenieros reciben automáticamente comentarios y orientación de seguridad mientras escriben código.

Con el tiempo, los desarrolladores pueden mejorar sus habilidades de ingeniería de seguridad, lo que significa que eventualmente introducirán menos problemas durante el desarrollo. Incluso cuando surgen problemas en tiempo de ejecución, pueden identificar mejor en qué parte de la infraestructura aplicar las correcciones.

La clave es que los equipos de seguridad actúen como proveedores internos de herramientas para los desarrolladores. La mejor versión de esta práctica se da cuando los equipos de seguridad colaboran estrechamente con los equipos de desarrollo e ingeniería de la nube para entender sus casos de uso y flujos de trabajo. A partir de ahí, pueden crear, comprar e integrar herramientas que proporcionen comentarios útiles y oportunos, además de instrucciones específicas para corregir los problemas.

Más pronto, más rápido, mejor y con más fuerza

Cuanto antes puedas corregir errores de configuración, errores de software y vulnerabilidades, mejor.

FormHero, que contaba con una sola persona dedicada a seguridad a tiempo completo junto a un equipo de desarrollo de 10 personas, comprobó que este principio era cierto al buscar herramientas para reducir el tiempo de corrección.

Ryan Kimber, fundador y director ejecutivo, afirma: “Si no abordas los problemas durante el flujo de trabajo de desarrollo y los detectas y resuelves en control de calidad, tardarás 10 veces más en corregirlos”.

Con infraestructura como código, herramientas de seguridad con integraciones estrechas y orientación automática para desarrolladores, los líderes de la nube pueden lograr esta mejora de 10 veces y ampliarla a todos sus entornos en la nube, para obtener una seguridad más sólida y menos costosa.