Cómo los equipos de DevOps y seguridad pueden trabajar mejor juntos

El desarrollo de software ágil lleva con nosotros durante casi dos décadas desde que se publicó el Manifiesto original. Los equipos de desarrollo de software y de TI se esfuerzan por conseguir un mejor software que responda a las necesidades de los clientes, en línea con los principios de la agilidad. Sin embargo, todavía existen problemas en torno a los procesos y políticas del software. 

DevOps puede ayudar aquí, con equipos que colaboran en cómo sacar el software de forma más rápida y eficiente. Sin embargo, para los equipos de seguridad de TI, el auge de DevOps también ha provocado problemas en la gestión de la seguridad y el riesgo.

Construyendo mejores procesos a través de los equipos

Uno de los mayores problemas para los equipos de seguridad de TI es involucrarse lo suficientemente pronto en el proceso de desarrollo. Para muchos, la seguridad es algo que se aplica una vez que las aplicaciones han sido construidas y están entrando en producción. Sin embargo, este es un enfoque anticuado que se mantiene desde los días en que el desarrollo se llevaba a cabo en fases de cascada y las aplicaciones se mantenían detrás de fuertes implementaciones de seguridad perimetral.

Hoy en día, casi todo el software incluirá algunos elementos de nube, integración de API o código de terceros. Se ha vuelto más fácil mezclar componentes de software para crear nuevos servicios en lugar de desarrollarlos desde cero. De hecho, cualquier equipo que intente implementar su propia criptografía o seguridad en lugar de utilizar productos listos para usar, se creará problemas masivos con el tiempo. La combinación de los mejores servicios de su clase, componentes de código abierto y código interno puede ofrecer mejores resultados más rápidamente.

Sin embargo, el primer problema en este enfoque es la visibilidad – con tantas partes involucradas en cada aplicación, mantener cada una actualizada y segura es una tarea de Sísifo que nunca termina. Para aquellos que utilizan contenedores para ejecutar aplicaciones basadas en microservicios, esto puede ser aún más difícil. Por ejemplo, los contenedores pueden diseñarse para que existan mientras haya demanda del servicio, y luego apagarse y “destruirse” una vez que esos niveles de demanda disminuyan. Mientras se esté ejecutando la instancia de la aplicación, los componentes existirán. En ese punto es cuando son vulnerables.

Para cualquier aplicación basada en la nube, obtener información precisa sobre lo que se está ejecutando en cualquier momento debería ser un paso necesario. Para los equipos de seguridad de TI, estos datos deberían proporcionarles una visión de los riesgos reales de cualquier servicio, mientras que los desarrolladores pueden utilizar estos datos para controlar realmente las instancias de sus aplicaciones en los debates sobre el rendimiento. 

La segunda área en la que esta información puede ser esencial se refiere al seguimiento de la responsabilidad de esos activos a lo largo del tiempo. Cuando las aplicaciones se ejecutan en la nube, estarán en la infraestructura de otra empresa: esa organización puede proporcionar todo lo necesario para ejecutar el servicio o permitir que los desarrolladores configuren y ejecuten sus propias instancias sobre la infraestructura base de la nube. 

Cuando la seguridad se involucra con los equipos de DevOps, ya sea a través de la colaboración ad hoc o de procesos más formales de DevSecOps, es esencial que la seguridad no parezca perturbar el flujo de desarrollo de software. En su lugar, debería estar integrada en el proceso de creación de código existente a través de plug-ins directos y herramientas que los desarrolladores están utilizando todos los días. Esto ayuda a los desarrolladores a ver que la seguridad beneficia directamente a la eficiencia de su código, en lugar de detener el proceso o actuar como un bloqueador.

Al mismo tiempo, el modelo de responsabilidad compartida de la nube significa que los desarrolladores y los equipos de seguridad deben trabajar juntos para determinar quién mantendrá los activos actualizados. No es importante quién hace esto – lo que es importante es que se haga.

Planificar con antelación en torno a la colaboración

Mirando hacia el futuro en torno a DevOps, los desarrolladores continuarán asumiendo una mayor responsabilidad en todo el proceso de creación y ejecución de software a lo largo del tiempo. Para los equipos de seguridad, involucrarse más temprano en el proceso debería ayudar a integrar herramientas de seguridad como el escaneo de vulnerabilidades de software o la gestión de contenedores. Esto no significa decirle a los equipos de software exactamente qué hacer, sino que debe ayudar a los equipos de desarrolladores a priorizar su trabajo y a ser conscientes de los problemas antes de que lleguen a las instancias de producción.

Proporcionar una mayor visibilidad de los posibles problemas de seguridad desde el principio puede incluir la búsqueda de fallos comunes y software obsoleto en las imágenes hasta la aplicación de las mejores prácticas en las aplicaciones web. Al ofrecer más orientación sobre cuestiones en una fase más temprana del proceso de desarrollo, éstas pueden solucionarse antes de pasar a las fases de prueba posteriores o a una distribución más amplia. 

Para los equipos de seguridad que buscan involucrarse más en DevOps, concentrarse en la seguridad por sí misma puede ser contraproducente. En cambio, si se proporciona a los desarrolladores más información sobre sus aplicaciones, se garantizará que todos trabajen con los mismos objetivos.

La entrada Cómo los equipos de DevOps y seguridad pueden trabajar mejor juntos aparece primero en Globb Security.