Mejorar el canal DevOps: Cómo tratar la seguridad y proteger el canal de despliegue

En “The DevOps handbook” de Jez Humble, John Willis, Patrick Debois y Gene Kim publicado por IT Revolution Press en 2016, tratan dos temas en la parte VI del libro. Uno de ellos es como integrar los trabajos que incorporan seguridad a los sistemas en Dev y en Ops, el otro como proteger el entorno del canal de despliegue formado por servidores en los que residen los entornos en los que se construye y explota el software. En este post se hace un resumen de lo propuesto en este texto.

Tratando la seguridad

Un pretesto para no implementar los principios y patrones de DevOps es a menudo "la seguridad de la información y el cumplimiento de las normas no nos lo permiten". Paradójicamente Devops puede ser una de las mejores formas de integrar la seguridad de la información en el trabajo diario.

El ratio de ingenieros de desarrollo, de operaciones y de seguridad en una organización suele ser respectivamente de 100:10:1. Cuando seguridad no dispone de procesos de automatización y de gestión de la seguridad en el día a día de Dev y Ops, lo único que puede hacer es validar si lo desarrollado y desplegado cumple con ciertos niveles de seguridad. Esto no es muy útil ya que se obtiene información de cómo incorporar seguridad cuando todo está ya construido y es difícil o imposible de resolver.

Para que esto no ocurra se recomienda tomar las siguientes acciones:

• Integrar a seguridad en las demos

Invitando a los especialistas en seguridad a las demos cuando finalizan los sprints, se consigue que asesoren a los desarrolladores en etapas tempranas de la construcción del código. De esta forma, el desarrollo se hará teniendo en cuenta las  necesidades de seguridad. Esto es más sencillo y barato que esperar hasta que todo está construido y después modificarlo para incorporar seguridad.

• Integrar a ingenieros de seguridad en seguimiento de defectos y en reuniones Post-Morten

Tras el acaecimiento de un fallo se debe organizar una reunión post-morten para analizar qué motivos lo provocaron y que solución se ha adoptado. Mediante la información recopilada en estas reuniones la organización va atesorando una fuente de conocimiento que la ayudará a trabajar mejor en el futuro. El objetivo es que no se vuelvan a provocar fallos parecidos y si se producen saber cúal puede ser la solución a aplicar.
Con el objetivo de tener en cuenta en los aspectos de seguridad, es adecuado invitar a ingenieros de seguridad a estas reuniones post-morten.

• Añadir mecanismos y herramientas que ayuden a asegurar que las aplicaciones y entornos están seguros.

Se tienen que proporcionar librerías y servicios de seguridad que proporcionen autenticación, autorización, gestión de contraseñas, encriptación de datos, etc. Se pueden incluir:

    - Modos de acceso seguro (por ejemplo, 2FA, bcrypt password. logging)
    - Herramientas para almacenar y proteger tokens, contraseñas, etc. (Por ejemplo: usando                        herramientas cómo Vault, sneaker, Keywhiz, credstash, Trousseau, Red October)
    - Paquetes para securizar (por ejemplo, NTP para sincronización de la hora de servidores,                     versiones seguras de OpenSSL, OSSEC para detección de intrusos)

• Integrar a seguridad en el canal DevOps 

Antes de DevOps para conseguir aplicaciones seguras se revisaban las cuestiones de seguridad una vez que el desarrollo estaba completado. Normalmente el resultado eran informes con decenas o cientos de hojas en los que se indicaban las vulnerabilidades de la aplicación. Muchas veces abordar los cambión necesarios para eliminar todas estas vulnerabilidades era imposible. Solucionar esto se consigue integrando a los especialistas de seguridad en etapas tempranas del desarrollo y la implantación  que asesoren a Dev y Ops. 

• Asegurar la seguridad de la aplicación

Consiste en establecer los medios de aseguramiento necesarios para que cuando el código llegue a producción esté en las condiciones óptimas y cumpla con todas las normas de seguridad. Para ello es oportuno establecer validaciones y verificaciones que pueden ser:

- Análisis estáticos. Con alguna herramienta revisar el código buscando debilidades, puertas traseras y código potencialmente malicioso.

- Análisis dinámicos. Los análisis dinámicos monitorizan elementos tales como la memoria, el comportamiento funcional, los tiempos de respuesta y el rendimiento del sistema. Estos análisis emulan lo que suele hacer el software malicioso y detecta vulnerabilidades.
- Búsquedas de amenazas en dependencias. Los sistemas hacen uso de librerías de terceras partes. Es necesario comprobar que dichas librerías están libres de vulnerabilidades.
- Integridad del código y firma del desarrollador. El repositorio de código es muy vulnerable, los commits deberían estar firmados para asegurarnos que han sido realizados por las personas autorizadas.

• Asegurar la seguridad de la cadena de suministro de software

Los desarrolladores utilizan múltiples librerías que realizan funcionalidades que necesitan. Realmente en gran parte construyen sus sistemas ensamblando partes de librerías de terceros. La cadena de suministro que proporciona esas librerías también hay que asegurarla. Es necesario controlar que durante el proceso de adquisición de estas librerías no se produzcan brechas en la seguridad.

• Asegurar la seguridad del entorno

Se trata de establecer controles que monitoricen las instancias de producción, para controlar que todos los entornos están en el estado esperado. Esto se consigue a través de pruebas automatizadas para asegurar que las configuraciones de bases de datos, sistemas operativos, redes, etc. son las adecuadas. Estas pruebas buscan vulnerabilidades.

• Vigilar la información de seguridad añadida a la telemetría de producción 

A veces los controles de seguridad son inefectivos para detectar brechas en el momento oportuno. Esto puede deberse a que tenemos puntos ciegos en nuestra monitorización o porque nadie examina la telemetría a diario.

Marcus Sachs, uno de los investigadores de brechas en seguridad de Verizon Data dijo en 2010, "Año tras año, en la vasta mayoría de las brechas en la seguridad de los datos, las organizaciones las detectan pasados meses. Y lo que es peor las brechas se detectan desde fuera de la organización porque algún socio o cliente es víctima de alguna transacción fraudulenta. Una de las causas de que esto ocurra es que nadie en la organización revisa regularmente los ficheros de log."

• Crear telemetria para controlar la seguridad de los entornos

Dentro del programa de mediciones a obtener, es interesante obtener medidas dedicadas a mantener los sistemas seguros. Se pueden medir:

- Cambios a los sistemas operativos
- Cambios a los grupos de seguridad
- Cambios a las configuraciones
- Cambios a la infraestructura de la nube 
- Intentos XSS (“cross-site scripting attacks”)
- Intentos SQLi (“SQL injection attacks”)
- Errores de servidor Web (4XX y 5XX)

Estas medidas pueden servir para detectar vulnerabilidades. Por ejemplo, se han detectado en marzo el doble de cambios en configuraciones que en febrero. Esta información sirve para indicar que hay que vigilar si es correcto que se haya duplicado el número de cambios. 

• Proteger los entornos y servidores

La infraestructura que soporta la integración continua y el despliegue continuo presenta una nueva área de vulnerabilidad a los ataques. Por ejemplo si alguien compromete algún servidor que aloja las credenciales para el sistema de control de versiones, puede ocurrir que alguien robe el código fuente. Peor todavía si en estos servidores hay permiso de escritura, un atacante podría inyectar cambios maliciosos en el repositorio de código.

Protegiendo el canal de despliegue

• Integrar seguridad y cumplimiento en el proceso de cambios

En las organizaciones suele existir un proceso para gestionar los cambios y que estos no disturben el normal suceder de los acontecimientos. ITIL clasifica los cambios en tres tipos: estándar, normal o urgente. Cada uno de ellos implica un nivel de riesgo distinto. Los cambios pequeños que implican poco riesgo se deberían automatizar o por lo menos eliminar la necesidad de aprobaciones por parte de comités o personas antes de su implantación, esto se suele convertir en cuellos de botella o traducir en tiempos de entrega largos. Los normales, sí se tratan a través de algún proceso de aprobación y los urgentes tendrán un proceso aparte donde se intente que no conduzcan a resultados no deseados.

•  Re categorizar la mayoría de los cambios de bajo riesgo como cambios estándar

Teniendo un canal DevOps que funciona adecuadamente, el área de TI tendrá buena reputación. Los despliegues y puestas en marcha se harán de forma rápida y segura. Se dispondrá de una historia de cambios de éxito y en el caso de problemas de un tiempo de resolución pequeño.
Estando en esta situación es bueno intentar que clasifiquemos de estándar todos los cambios que podamos. Esto es porque no hay mucho riesgo de que produzcan problemas y si los producen se resolverán de forma inmediata.

• Qué hacer cuando los cambios se catalogan como cambios normales

Para aquellos cambios que no se puedan clasificar de estándar se seguirá realizando las aprobaciones que se requieran, pero es importante asegurarse de que se automatiza todo lo que se pueda para que los despliegues sean lo más rápidos posible.
Para su correcta gestión debemos añadir a estos cambios toda la información que sea necesaria para que las aprobaciones sean lo más ágiles posible.
Es importante mantener un historial de cambios ejemplar, de esta forma podemos ganar la confianza de la organización y convertir una gran mayoria de los cambios en cambios estándar.

• Reducir la división de tareas

La separación de tareas a menudo reduce el feedback que los ingenieros reciben de su trabajo. Esto hace que sea más difícil que se sientan responsables de su trabajo. Se debe intentar donde se pueda evitar la separación de tareas, en su lugar preparar formas de trabajo colaborativas, por ejemplo pair programming, peer review, sesiones de trabajo de ingenieros dev y ops conjuntas.

• Proveer documentación y pruebas para auditores y agentes responsables de cumplimiento

Bill Shinn es arquitecto de soluciones de seguridad de Amazon Web Services y dice " En DevOps se trata de tender un puente entre Dev y Ops. Además existe el reto todavía más grande de tender el puente entre DevOps y los auditores y agentes de cumplimiento. Por ejemplo, cuantos auditores entienden el código y cuantos desarrolladores se han leído la norma NIST 800-37 del instituto de estándares y tecnología de Estados Unidos.
Hay que buscar los medios para suministrar la información a auditores y agentes dentro del canal DevOps.

Conclusiones

Los principios DevOps se pueden aplicar a la seguridad de la información, haciendo que el trabajo de los ingenieros de seguridad se integre en el de los de desarrollo y operaciones. Esto se consigue haciendo que la seguridad sea parte del trabajo diario de todos. Además se integran los controles de seguridad en los planes de métricas que debe utilizar el canal DevOps para mantener los entornos en un estado protegido y con un bajo perfil de riesgo.

Que con buenas prácticas DevOps la seguridad mejore hace que cuidemos mejor de los datos, también que sea posible recuperarse de los incidentes que producen las brechas de seguridad antes de que sean catastróficos y lo más importante de todo que la seguridad de nuestos datos y sistemas sea mejor que ha sido nunca.