Las principales tácticas para tener éxito en Secure DevOps

El mundo cada vez más conectado de hoy, con acceso a dispositivos móviles y computación a escala en la nube, está generando disrupciones en los modelos y procesos comerciales. Para tener éxito, no tiene otra opción que ofrecer continuamente valor nuevo a los clientes a la velocidad cada vez mayor que exigen.

Mark Andreessen, el fundador de Netscape, dijo hace unos años que “el software se está comiendo el mundo, en todos los sectores”. Cada vez vemos más organizaciones que se transforman como empresas tecnológicas. La digitalización y la adopción de prácticas Agile y DevOps ha cambiado la forma en que creamos software.

De hecho, creamos software utilizando la metodología Waterfall durante mucho tiempo. Requirió una planificación extensa desde el principio y fue lento en la entrega de productos terminados. Con el tiempo, Agile reemplazó a Waterfall y, al hacerlo, cambió el enfoque para enviar incrementos más pequeños de software con requisitos que evolucionan a través del esfuerzo colaborativo de equipos autoorganizados y usuarios finales. Aprovecha la voz del cliente desde el principio y con frecuencia, lo que garantiza que la organización esté creando los productos y características correctos, además de entregarlos con calidad y previsibilidad.

DevOps combina estos beneficios al mejorar la colaboración entre los equipos de desarrollo de software y operaciones de TI. Esto acelera y mejora el proceso de entrega de software y fomenta la colaboración constante. El resultado son lanzamientos más confiables, que en última instancia ayudan a brindar una experiencia de usuario final excepcional. Las prácticas de DevOps se pueden resumir como “un enfoque impulsado por el negocio para ofrecer soluciones utilizando métodos ágiles, colaboración y automatización.”

Prácticas seguras de DevOps

La formalización del término DevOps se produjo en el Conferencia de velocidad 2009 donde John Allspaw y Paul Hammond de Flickr presentaron cómo realizan 10 implementaciones por día. Los conceptos mostrados por Allspaw y Hammond ahora son componentes estándar del movimiento DevOps. Su formalización, sin mencionar la adopción de prácticas Agile y DevOps, ha llevado a cambiar la forma en que generalmente se realiza la verificación de seguridad.

La noción de SecDevOps apareció por primera vez en un Publicación de blog de 2012 de Neil McDonald de Gartner. Abogó por que los esfuerzos de DevOps no deberían reducirse en favor de la seguridad y reconoció que la seguridad era necesaria. Su respuesta fue que la seguridad debe integrarse en el proceso DevOps. McDonald llamó a esto DevOpsSec, pero la mayoría de la gente ahora se refiere a él como SecDevOps o DevSecOps.

Secure DevOps está en la intersección de Dev, Ops & Sec. Doblar la seguridad en el espíritu de DevOps de mejorar gradualmente el software en compilaciones más pequeñas y rápidas ayuda a corregir fallas antes en el proceso de desarrollo. Secure DevOps aborda las siguientes áreas clave:

• Hacer software confiable
• Mantener la confidencialidad e integridad del sistema
• Gobernanza y cumplimiento
• Administracion de incidentes

Desafíos de seguridad de DevOps

Las prácticas de DevOps facilitan los ciclos de desarrollo condensados ​​y los plazos de lanzamiento de productos, al tiempo que mantienen las características y capacidades del producto en respuesta a los comentarios de los clientes y los objetivos comerciales cambiantes. También tienen un impacto considerable en las consideraciones de seguridad.

Ponerse al día con el acelerado ciclo de DevOps

Tradicionalmente, hemos visto que las pruebas de seguridad se realizaron hacia el final del ciclo de lanzamiento después de que se completaron todos los ciclos de implementación y prueba. Hay algunos campeones de seguridad de la información que auditan el lanzamiento en busca de vulnerabilidades de seguridad y publican muchas infracciones. A menudo, la reparación de estas vulnerabilidades también puede dar lugar a cambios en el diseño. Muchas veces, esto conduce a un retraso en el ciclo de lanzamiento, que tradicionalmente era de 4 a 6 meses. Por lo tanto, esta estrategia aún podría haber funcionado, pero ahora con la mayor adopción de prácticas ágiles, el ciclo de lanzamiento se ha reducido a límites de sprint de 2 a 3 semanas. Por lo tanto, realizar controles de seguridad cada pocos meses aumenta el riesgo de que los atacantes exploten las debilidades en la producción.

Si los controles de seguridad no están lo suficientemente automatizados, el ciclo de DevOps se ralentizará o la higiene de la seguridad se verá afectada. Este retraso de fase puede conducir a un código inseguro que abre vulnerabilidades y debilidades que los atacantes pueden explotar.

Comunicación efectiva entre el equipo de seguridad y desarrollo

Los equipos de seguridad y los desarrolladores intentan perseguir objetivos aparentemente contradictorios. Los desarrolladores quieren sacar el software de la canalización lo más rápido posible. Por otro lado, los equipos de seguridad quieren que los desarrolladores arreglen todas las vulnerabilidades de seguridad antes de lanzar el software. Ambos equipos deben trabajar juntos para evitar conflictos y garantizar que el software bien probado se publique con una respuesta rápida.

A menudo se ha visto que el equipo de seguridad no comunica ni realiza un seguimiento eficaz de los requisitos de seguridad con el equipo de desarrollo. Esto puede conducir a una ralentización del proceso ya que los desarrolladores no saben cómo manejarlos o no están familiarizados con los principios de seguridad. Los requisitos de seguridad deben ingresarse en la cartera de pedidos del producto al igual que los requisitos de características regulares. Esto ayudará a priorizar cada sprint.

Contenedores y entorno de nube

Un entorno DevOps típico se basa en la infraestructura y las implementaciones de la nube, lo que introduce muchas consideraciones de seguridad en la nube. Se utilizan muchas herramientas nuevas, de código abierto y aún inmaduras. En la canalización acelerada de DevOps, un simple error de configuración incorrecta o una mala práctica de seguridad, como compartir credenciales, puede crear escenarios desagradables.

Al mismo tiempo, un entorno DevOps típico puede aprovechar varias herramientas (Chef, Puppet, Ansible, Salt, etc.) que requieren la gestión de secretos. Los contenedores vienen con sus propios riesgos. El uso de tecnologías de contenedores como Docker o Kubernetes aporta una productividad excepcional a los equipos. Sin embargo, tales utilidades también pueden crear dolores de cabeza de seguridad. Sin controles y equilibrios adecuados, por ejemplo, los contenedores pueden presentar riesgos de seguridad, ya que no se escanean adecuadamente en busca de vulnerabilidades.

No hay duda de que la seguridad debe integrarse en el ciclo de vida de DevOps, pero debe hacerse de manera que no obstaculice la velocidad y la agilidad. Debe haber una colaboración adecuada entre el equipo de DevOps y el equipo de seguridad.

Para resumir, estas son las principales tácticas para tener éxito en DevOps seguras:

• Fail Fast a través de la automatización – Fallar las pruebas tan pronto como sea posible en la canalización de DevOps.
• Integrar la seguridad de las aplicaciones en las herramientas de desarrollo – Integre las herramientas dentro de su IDE.
• Soluciona fallas mientras escribes código – Los desarrolladores deben aprovechar las herramientas para encontrar y corregir errores de codificación mientras escriben el código.
• Adaptarse a las nuevas prácticas de desarrollo y tecnologías como la contenedorización, los microservicios y los patrones de diseño, como los conmutadores de funciones.
• No te detengas por falsas alarmas
• Proporcione visibilidad operativa para medir y evaluar los equipos en cuanto a cumplimiento y riesgo.