Argumentos para la seguridad continua

Por | 24 febrero, 2016

DevOps es un término que ha explotado en los últimos 5 años. Como miembro de esa comunidad desde sus comienzos, resulta interesante observar la evolución temporal del diálogo respecto a la misma. A muchos provoca reacciones adversas, pues estiman que es solo otra de las tantas palabras de moda, en especial porque los conceptos fundamentales descritos como “DevOps” son procesos que se han venido desarrollando normalmente desde hace años.

(No voy a molestarme en especificar “qué es DevOps”, existen gran cantidad de blogs donde puede encontrarse la definición con facilidad).

DevOps
Uno de los principios fundamentales de “DevOps” es el acortamiento de los procesos de retroalimentación (“feedback loop”) en los ciclos de desarrollo. Al reducirse ese tiempo, los equipos de desarrollo pueden acelerar su trabajo y hacerlo llegar más rápido a los clientes. Este principio se conecta directamente con las metodologías Agile utilizadas por los equipos de ingeniería de software.

Con el advenimiento de infraestructuras de nubes más accesibles y de variadas infraestructuras de herramientas operacionales alrededor de esos proveedores de infraestructura, los cuales han conseguido gran nivel de madurez, asistimos a un panorama en que “DevOps” ha llegado a ascender a la corriente principal (“mainstream”). Para las compañías emprendedoras de iniciativas de desarrollo de nuevos productos, el empleo de alguna forma de Configuración de Administración (“Configuration Management”) es una de las primeras opciones a considerar. De la misma manera, cada vez más se conoce de más empresas que desechan los centros físicos de datos para impulsar la flexibilidad y accesibilidad a los recursos públicos informáticos proporcionados por empresas tales como Amazon, Microsoft y Google.

La naturaleza inherente de estos proveedores de infraestructura como servicio (IaaS providers) es facilitar de la manera más sencilla y ágil el suministro de sistemas que satisfagan la necesidad de los clientes. La velocidad dirigida hacia el mercado es una ventaja competitiva fundamental en la que muchas compañías están trabajando a través del concepto de “Infraestructura como Código” actualmente. El abastecimiento de cientos o miles de instancias informáticas en pocos minutos es valorado hoy como una actividad cotidiana. Todos quieren moverse rápido.
Las ideas esbozadas giran en torno a las máximas de integración y creación de productos de forma continua. ¿Pero cómo monitorear permanentemente el estado de la seguridad operacional de todos estos procesos?

“Errar es de humanos. Propagar el error a todos los servidores de manera automática es #devops”.
— DevOps Borat (@DEVOPS_BORAT) February 26, 2011

Vivimos en un mundo donde el administrador de sistemas más joven puede hacer un pequeño cambio a un “cookbook” de Chef (“Chef Cookbook”), a un “manifest” de Puppet (“Puppet manifest”) o quizás a un playbook de Ansible (“Ansible playbook”) y ponerlos a producir en pocos minutos.

¿Pero cuál es el objetivo de ese cambio realmente? Cuando hoy los administradores de sistemas no quieren que el equipo de seguridad desacelere su flujo de trabajo; ni que sus modificaciones a la configuración de gestión pasen por la Junta de Control de Cambios. Su propósito verdadero es cambiar una variable, abrir una “pull request” (no encuentro forma de traducir este tecnicismo) y una vez mezcladas, que sus herramientas operacionales hagan el resto. Igual necesitan que esos resultados lleguen a los servidores de producción rápidamente. Es decir, el objetivo de los administradores de sistema es hacer su trabajo de la manera más rápida y sin interrupciones posible.

En este sentido, uno de los principios fundamentales de DevOps busca valorar la empatía entre equipos que tradicionalmente manejan incentivos diferentes en sus contenidos de trabajo (por ejemplo, los Devs [Desarrolladores] estiman los cambios constantes, mientras que los Ops[Operadores] aprecian la estabilidad). El requerimiento en la actualidad es conseguir ese mismo resultado (la empatía, la fluidez, la integración, la intercomunicación) en los equipos de Seguridad y los demás restantes dentro del negocio.

Cuando se está en un entorno de trabajo donde se desarrollan cambios ininterrumpidamente, surge también la necesidad de monitorear las implicaciones de seguridad de esas innovaciones operacionales. Por desgracia, es frecuente encontrar compañías donde ningún empleado puede afirmar con absoluta certeza cuáles modificaciones en la infraestructura tienen a la vez, riesgos adicionales para la esfera de la seguridad. Y si además esas empresas funcionan con una seguridad de red tradicional (antigua, desactualizada), que revisa y aprueba manualmente los cambios en la producción, el cuello de botella en el flujo de trabajo no se hará esperar.

Estas ideas son las que me motivaron a unirme a Threat Stack. Como veterano operador técnico en los últimos 15 años, considero que estos son los problemas más importantes a resolver en muchas entidades. Tener la oportunidad de ayudar a construir productos que permitan a las compañías continuar desactivando silos operacionales, y a la vez optimizar la velocidad de detección y respuesta frente a incidentes de seguridad, es absolutamente la profesión de mis sueños.
¿Cómo perfeccionar el monitoreo de seguridad y los tiempos de respuesta mientras se mantiene la habilidad de desarrollar innovaciones y la producción en general? Estos son problemas difíciles y Threat Stack se complace en ayudar activamente a sus clientes a resolverlos.

Escrito por: Pete Cheslock

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

This site uses Akismet to reduce spam. Learn how your comment data is processed.