DevSecOps

El 26 de junio de 1991, en Washington DC, gran parte de Maryland y Virginia Occidental en Estados Unidos, muchos lugares quedaron paralizados por una falla masiva en la red telefónica pública. A pesar de ello, a medida que la tecnología se vuelve más sofisticada y los sistemas de red son más interdependientes, aumenta la probabilidad de fallas recurrentes. No se puede decir que no hubo advertencias de que esto iba a pasar.

A principios de la década de los 90, 12 millones de personas en los Estados Unidos sufrieron enormes fallas en la red telefónica. La gente no podía llamar al hospital. Las empresas no podían llamar a los clientes. Los padres no podían llamar a las guarderías. Fue un caos y también un serio llamado de atención, un llamado de atención en un país cuya infraestructura dependía en gran medida de los sistemas informáticos que conectaban todo. Las redes informáticas eran cada vez más grandes, y luego cuando fallaron, sí, fallaron a fondo.

Una falla informática causó el colapso del sistema telefónico. Un error diminuto de una sola línea del código, y hoy en día las consecuencias de los pequeños errores como esos son más fuertes que nunca.

Esto es Command Line Heroes en español, un podcast original de Red Hat.

La seguridad y fiabilidad del software son más importantes que nunca. El viejo enfoque de cascada hacia el desarrollo, donde la seguridad simplemente se agregaba al final de las cosas, ya no es suficiente. Vivimos en un mundo DevOps donde todo es más rápido, más ágil y escalable, de maneras que ni siquiera podíamos imaginarnos cuando se cayó aquella red telefónica. Eso significa que nuestros estándares de seguridad y fiabilidad tienen que evolucionar para enfrentar los nuevos desafíos.

En este episodio, vamos a descubrir cómo integrar la seguridad en DevOps, y también vamos a explorar nuevos enfoques para lograr que las operaciones sean fiables y sólidas. Sabemos que incluso después de haber abordado todo eso, podríamos hablar de muchas otras cosas, porque en un mundo DevSecOps, todo cambia rápidamente tanto para los desarrolladores como para las operaciones.

Muy bien, vamos a empezar a explorar este nuevo territorio.

Bueno, para lograr que la seguridad y la confiabilidad de los sistemas estén al día, para prepararlas para un mundo DevOps, tenemos que hacer un par de ajustes fundamentales en la forma en que trabajamos. Primero, necesitamos adoptar la automatización. Piensa en la logística de la autenticación de dos factores. Piensa en la enorme tarea que representa. Es bastante obvio que no vamos a resolver nada si simplemente agregamos más personal, así que lo primero es adoptar la automatización.

Y probablemente lo segundo es menos obvio: hay que cambiar la cultura para que ya no tengamos que preocuparnos por la seguridad. Más adelante explicaré a qué nos referimos con cambiar la cultura, pero vamos a abordar estos dos pasos, uno por uno. Primero, adoptar la automatización.

Antes, para implementar una aplicación se necesitaba que las personas encargadas de la seguridad se pusieran a revisarla, porque era una tarea humana; y en caso de que no lo hayan notado... las personas pueden ser medio lentas. Por eso la automatización es indispensable para integrar la seguridad en DevOps. Vamos a pensar, por ejemplo, en el reciente informe de violación de datos de Verizon. Descubrieron que el 81 % de todas las violaciones relacionadas con la piratería informática involucran contraseñas robadas o débiles, así que el problema es muy sencillo. Solo que es un problema sencillo a gran escala. Y como dijimos antes, no vamos a resolver 30 millones de problemas de contraseñas simplemente agregando más personal, ¿verdad? El obstáculo es abordar la escala del problema, su enorme tamaño, y la respuesta es la misma siempre. Automatización y más automatización.

Si esperamos a que se involucre una persona, la solución no se va a multiplicar.

Vincent Danen es director de seguridad de productos en Red Hat y, durante los 20 años que ha estado en esto, ha visto cómo DevOps creó un entorno cada vez más rápido. Los equipos de seguridad han tenido que apresurarse para mantenerse al día.

Cuando comencé, cada mes aparecía un nuevo punto vulnerable; luego, cada dos semanas, y luego cada semana, y ahora encontramos cientos de ellos todos los días.

Lo interesante es que Vincent dice que, en realidad, a medida que los equipos de seguridad evolucionan aumentan los puntos vulnerables, no disminuyen.

Nunca vamos a llegar al punto en que digamos, ah, pues ahora sí ya estamos seguros, listo. Ya terminamos nuestro trabajo. No, el tema de la seguridad siempre va a estar presente. Simplemente es algo que se tiene que volver tan normal como respirar.

Y resulta que lo que cuenta como problema para los equipos de seguridad y fiabilidad tiene cada vez más matices.

Actualmente, cuando buscamos esos problemas, detectamos cada vez más, y esa tendencia continuará a medida que encontremos nuevos tipos de puntos vulnerables y cosas que tal vez no creíamos importantes o que ni siquiera sabíamos que existían. Ahora nos enteramos de los problemas más rápido, y cada vez hay más. Entonces, el tamaño es exponencial. Es el conocimiento. Es el volumen del software. Es la cantidad de consumidores. Todo eso contribuye al aumento de la seguridad en esa área, y a los puntos vulnerables que encontramos.

Una vez que pensemos en la seguridad como un problema en evolución, en lugar de creer que se “resuelve” con el tiempo, el argumento que apoya la automatización, pues, se vuelve aún más fuerte.

Bueno, creo que, por un lado, con la automatización podemos integrar la seguridad en los canales de desarrollo muy rápido. Por otro lado, no es necesario que las personas realicen ese esfuerzo, ¿verdad? Las computadoras no necesitan dormir, así que la velocidad de procesamiento de los códigos solo depende de nuestros procesadores, y ya no tenemos que esperar a que una persona revise algunas líneas de código probablemente tediosas para buscar los puntos vulnerables.

Además, con la coincidencia de patrones y la heurística, podemos determinar lo que es vulnerable incluso al momento de escribir el código, o sea, desde el principio. Así que si tienes, por ejemplo, un complemento para tu entorno de desarrollo integrado o para la herramienta que usas para escribir tu código, mientras lo escribes puede decirte como, oye, esto se ve un poco sospechoso, o acabas de agregar un punto vulnerable, y entonces puedes corregir estas cosas incluso antes de que envíes el código.

Seguridad en constante movimiento. Eso es una gran ventaja.

Hay tantas cosas que aparecen todos los días, incluso cada hora. Con la integración y entrega continuas, escribimos el código, y se implementa 10 minutos después. Así que es muy importante obtener la validación de ese código automáticamente antes de que se implemente.

Hay una amplia gama de herramientas disponibles para que podamos lograrlo, ya sea mediante un análisis de código estático o con complementos para nuestro entorno de desarrollo integrado u otras muchas opciones.

Esas herramientas, ya que están listas, ayudan a mantener la seguridad como prioridad. El resultado: DevOps se reinventa como DevSecOps. La seguridad se integra al proceso.

De la misma manera en que los desarrolladores y operaciones se combinaban, se tomaron las dos disciplinas para generar una sola. Ahora tenemos DevOps, y creo que el tomar ese tercer componente de seguridad e integrarlo con el desarrollo y las operaciones es muy importante, porque el hecho de que la seguridad sea una opción adicional es lo que la vuelve tan reactiva, costosa, perjudicial o causa un riesgo para los consumidores. Y cuando lo integramos desde el principio, se hace el desarrollo y la seguridad se incorpora de principio a fin y las operaciones funcionan.

Por supuesto, como dijimos al comienzo del episodio, la automatización es solo la mitad del camino, y Vincent lo sabe.

No es solo una pieza. No podemos simplemente lanzar una herramienta a los canales de CI/CD y esperar que todo esté bien. Existe toda una gama de diferentes técnicas, tecnologías y comportamientos que se requieren para producir los resultados beneficiosos que queremos ver.

La automatización nos permite recorrer una parte del camino, pero tenemos que recordar el otro elemento, el que era un poco más confuso. Lograr que los desarrolladores y los de operaciones estén de acuerdo, para que ya no tengamos que preocuparnos por la seguridad.

Tenemos que cambiar la cultura, y algunas personas están aprendiendo a hacerlo de la manera menos dolorosa posible: con juegos.

Ahora vayamos al lado operativo de las cosas. En la actualidad, es muy fácil levantar una infraestructura enorme, pero eso no significa que debamos hacer un trabajo mal hecho. Debemos seguir trabajando en nuestros sistemas, garantizando que exista fiabilidad, resolviendo cómo prepararnos para lo inesperado. Esa es la mentalidad que Jesse Robbins intenta impulsar.

Hoy en día, Jesse es director ejecutivo de Orion Labs, pero antes se lo conocía como el maestro de los desastres en Amazon. Durante el tiempo que pasó ahí, Jesse era el gran mago que generaba conciencia sobre estos problemas. Y para ello utilizó ejercicios llamados Game Day. En dichos ejercicios, miles de empleados realizan simulacros de situaciones de desastre, para acostumbrarse a la idea de que las cosas se rompen y para entender muy bien el cómo y el porqué.

Esta es una conversación con Jesse, donde habla sobre cómo la fiabilidad y la resiliencia se integran del lado de las operaciones.

Fantástico. Entonces, eres conocido por muchas cosas, pero una de ellas es el ejercicio de Game Day, que organizaste en Amazon. ¿Qué es? ¿Qué es Game Day?

Game Day era un programa que diseñé, donde descomponíamos ciertas cosas a gran escala para poder evaluar la preparación operativa de los sistemas más vulnerables. Si te gusta la herramienta que ahora se llama Chaos Monkey, de Netflix y de otros, pues el precursor definitivamente fue Game Day, que era el nombre de mi programa. Su objetivo principal era desarrollar una cultura de excelencia operativa, desarrollar la capacidad de probar sistemas a gran escala en el momento en que se descomponen y aprender cómo sucede para mejorarlos. Y también desarrollar una cultura capaz de responder y recuperarse de incidentes en esas situaciones. Y todo se modelaba y aún se modela a partir del sistema de comando de incidentes, que es lo que los departamentos de bomberos usan en todo el mundo para manejar incidentes de cualquier tamaño.

Nació de...

Una nota loca al margen, Jesse se capacitó para ser bombero en 2005. Y allí es donde conoció ese sistema de comando de incidentes que terminó inspirando Game Day. Así que todos los desarrolladores que hacen esos ejercicios de desastres tendrán que agradecerle a Jessie y a su pasión por la lucha contra incendios y la gestión de emergencias. Bien, volvamos a nuestra conversación.

La resiliencia es la capacidad de un sistema para adaptarse al cambio, para responder ante fallos y alteraciones, y eso incluye tanto a las personas como todo lo que desarrollen para lograr adaptarse. Y una de las mejores maneras de lograr eso, de lograr desarrollar una cultura que pueda responder a esos tipos de entornos y que realmente comprenda cómo funcionan, es proporcionar ejercicios de capacitación a las personas. Y esos ejercicios pueden ser tan sencillos como reiniciar un servidor o tan complicados como apagar centros de datos completos para provocar fallas de gran escala, y cualquier ejercicio intermedio. Y entonces, antes que nada, Game Day es un proceso en el que uno se prepara para esas fallas, y para ello se reúne a toda la organización para hablar sobre cómo fallan los sistemas, para pensar en lo que saben las personas y para ver cómo esperan que suceda el fallo. Y muchas veces ese ejercicio por sí solo es una de las partes más valiosas del comienzo de un Game Day.

Pero luego realizas un ejercicio en el que descompones algo. Puede ser grande o pequeño. O puede ser algo que se descomponga todo el tiempo. Y entonces puedes estudiar la forma en que todos responden, la manera en que evolucionan las cosas. Puedes ver al sistema descomponerse, y puede ser algo que pueda descomponerse sin causar problemas, por ejemplo algún elemento que todo el mundo conozca bien, o algo que exponga lo que llamamos un defecto latente. Los defectos latentes son los problemas que se ocultan en el software, la tecnología o los sistemas a escala, y que solo podemos identificar cuando sucede algo extremo o inesperado. Está diseñado para capacitar a la gente y diseñar sistemas que nos permitan saber cómo van a trabajar bajo estrés y tensión.

Y Game Day... “¿Qué te inspiró a crearlo, fue en respuesta a algún problema específico? ¿O cómo surgió?”

Game Day comenzó durante un período en el que yo sabía, por mi puesto, por mi experiencia única como bombero y director de emergencias, que era importante cambiar el enfoque cultural de concentrarse en evitar los fracasos, y más bien aceptar que suceden. Y parte de lo que inspiró eso fue mi propia experiencia, comprender cómo fallan los sistemas, los edificios y la infraestructura cívica, y cómo ocurrieron los desastres, y la presión que eso ejerce sobre las personas. Y si observamos la complejidad y la escala operativa que tenemos en el área laboral en la que estaba, la única manera en la que realmente podemos diseñar, cambiar y convertirnos en un entorno de alta fiabilidad y siempre activo es adoptando en serio el enfoque de servicio contra incendios. Donde sabremos que habrá fallas. No es cuestión de preguntarse si va a pasar, es cuestión de cuándo va a pasar. Y, luego, como diría mi antiguo jefe de bomberos, tú no elijes el momento, el momento te elige a ti. Tú solo decides qué tan preparado estás para cuando suceda.

Ay, ese está bueno. Entonces, cuando recién comenzaste a organizar los Game Day y a pensar en cómo prepararse para las situaciones de desastre, ¿todos estaban de acuerdo o hubo algún rechazo?

Todos pensaban que estaba loco. Así que, sí, definitivamente hubo quienes se resistieron. Y es interesante, porque había una forma muy sencilla de superar esa resistencia, que es empezar por crear lo que yo llamo "campeones". Hay que enseñarle a la gente, a un grupo pequeño, cómo trabajar de una manera muy segura, y luego les das una pequeña introducción, y usas un conjunto de indicadores con los que puedas decir, mira, solo vamos a medir cuánto dura el apagón, cuántos minutos de tiempo de inactividad tiene mi equipo, que ya tiene cierta capacitación y funciona de tal o cual manera. En comparación con tu equipo, por ejemplo, que no está formado en esto y que parece creer que este tipo de capacitación y ejercicios no es valioso o no es importante.

Y una vez que haces ese tipo de cosas, básicamente terminas con lo que yo llamo un caso convincente. Entonces, a menudo habrá un apagón u otro problema en el que la organización se dé cuenta repentina y claramente de que no pueden seguir haciendo las cosas como las hacían antes. Y ese incidente se convierte en el método que se utiliza para convencer a los escépticos. Usas una combinación de datos e información de desempeño por un lado, junto con indicadores, y por otro, una excelente narración, y luego esperas que ocurra el terrible incidente y dices: "Toda la organización necesita esta habilidad si vamos a operar a escala web o a escala de Internet".

Ajá (afirmativo). Y esto no solo se mantuvo dentro de Amazon. Se extendió. Muchas otras empresas lo están haciendo. Muchas personas han terminado adoptando este conocimiento y este proceso para estar preparados. ¿Cuál es el siguiente paso? ¿Cómo seguimos llevando el conocimiento de Game Day hacia futuros proyectos y empresas?

Me gusta referirme a eso como una evolución convergente. Actualmente todas las organizaciones grandes que operan en la web han adoptado alguna versión de la base de gestión de incidentes por la cual sin duda abogué, y han diseñado sus propias pruebas de Game Day. Netflix lo llama Chaos Monkey. Google tiene su programa Dirt.

Entonces, ¿qué esperanzas y sueños tienes para Game Day en el futuro?

En primer lugar, lo que me entusiasma es que ahora vemos la evolución de la idea de que los núcleos y los sistemas no están conectados... ...al concepto de que los sistemas están interconectados y son interdependientes; y los diseñan y los operan personas inteligentes de todo el mundo que intentan hacer grandes cosas.

Hace años, en mis inicios, cuidar las operaciones era un problema. No era interesante. Y de repente, nos damos cuenta de que podemos propagar la idea de que la única manera de diseñar y ejecutar una tecnología significativa en un mundo conectado es que los desarrolladores y la gente de operaciones trabajen juntos.

Así que mi esperanza para el futuro es... en primer lugar, estamos viendo cada vez más personas que adoptan estas ideas y se informan sobre ellas. Y comprenden que cuando se diseña algo de lo que depende la gente, se tiene la obligación de asegurar que sea confiable, utilizable, seguro, que sea algo que la gente pueda usar como parte de su vida diaria.

Pero también vemos surgir una nueva disciplina. Se está estudiando, sabes, se escriben tesis de doctorado al respecto. Se está desarrollando de forma constante.

Eso es maravilloso.

Se escriben libros, hay muchísimos recursos nuevos, no son solo dos personas que dan una conferencia para explicar cómo creen que debería funcionar el mundo. Por eso, la esperanza que me inspira es, por un lado, entender que si se diseña software y tecnología para el uso de la gente, realmente nos volvemos parte de la infraestructura cívica. Entonces, las habilidades que como bombero he tratado de aportar a la tecnología y las habilidades que ahora surgen y que están llevando todo esto a otro nivel son parte de los cimientos para diseñar cosas en las que la gente confíe para su día a día.

Según la perspectiva de Jesse, los ejercicios como Game Day o Chaos Monkey son una parte fundamental del crecimiento de nuestra cultura tecnológica, pero también son indispensables para la sociedad en general. Ya era evidente en la década de los 90, cuando las redes telefónicas comenzaron a colapsarse.

La vida moderna como la conocemos casi se detiene.

Y eso genera un deber que tenemos que cumplir. El deber de preocuparnos por la seguridad y la fiabilidad, por la resiliencia de las cosas que diseñamos. Pero si hablamos de incorporar seguridad en DevOps, es evidente que acabamos de empezar.

La seguridad es una de las... como industria, apenas está en pañales.

Ese era Josh Bressers. Es jefe de seguridad de productos en una empresa emergente de software de búsqueda de datos llamada Elastic. Para Josh, si bien la industria informática ha estado madurando durante aproximadamente medio siglo, parecería que el tipo de seguridad del que hemos estado hablando aquí acaba de surgir.

En términos prácticos, yo diría que quizás como profesión, la seguridad sigue siendo muy nueva, y hay muchas cosas que no comprendemos.

Sin embargo, lo que sí entendemos es que en un mundo de DevSecOps hay oportunidades bastante buenas para ser creativos con lo que la seguridad puede lograr.

Hace poco hablé con alguien sobre cierto concepto en el que utilizan el comportamiento del usuario para decidir si debe poder acceder al sistema. Todo el mundo tiene ciertos comportamientos, ya sea de dónde vienen, la hora del día en que ingresan a un sistema, la forma en que escriben, la forma en que mueven el ratón. Así que, realmente es una de esas ideas que creo que podría tener resultados muy buenos si lo hacemos bien, porque podemos prestar atención a lo que hacen las personas. Entonces, digamos que estoy actuando de manera extraña, pero es simplemente porque me torcí la muñeca. Pero los demás no saben.

Entonces, el sistema podría decir, hay algo extraño, queremos que inicies sesión con tu autorización de dos factores y también te vamos a enviar un mensaje de texto o algo así. ¿No? Así que pasamos de usar solo el nombre de usuario y la contraseña a algo más interesante. Entonces creo que va a ser realmente indispensable que analicemos muchos de esos problemas de maneras nuevas y únicas. Y en muchos casos, todavía no llegamos a eso.

Para llegar ahí, necesitamos dar los dos grandes pasos que hemos descrito. Paso uno, la automatización, que es tan importante porque...

Los seres humanos son pésimos para hacer lo mismo una y otra vez.

Claro. Y luego tenemos el paso dos, la cultura; todos nosotros tenemos un papel que desempeñar en la seguridad y una responsabilidad al respecto, sin importar cuál sea nuestro cargo.

Cuando la mayoría de la gente piensa en el equipo de seguridad, no piensa en gente feliz y amable, ¿verdad? En general, se habla de personas terribles, gruñonas y molestas, y si te las encuentras te van a arruinar el día. Y nadie quiere eso, ¿verdad?

Pero podemos superar ese prejuicio, tenemos que hacerlo; piénsalo así: cada día ocurren más amenazas a la seguridad y cada día la infraestructura de TI crece y se vuelve más poderosa. Si juntamos esos dos hechos nos daremos cuenta de que más nos vale vivir en un mundo que adopte la seguridad. Un mundo DevSecOps donde los desarrolladores y la gente de operaciones organicen más juegos de seguridad, más juegos de fiabilidad... Hablamos de un futuro en el que la automatización se incorpore en cada etapa, y las actitudes de todo el mundo hacia estos problemas se vuelvan más integrales. Así es como vamos a mantener seguros los sistemas del mañana. Así es como vamos a garantizar que los teléfonos sigan sonando, que las luces sigan encendiéndose, que toda la vida moderna funcione bien y tenga la solidez necesaria. Si vemos la lista de Forbes de las 2000 empresas del mundo, es decir, las 2000 empresas públicas más importantes, resulta que un cuarto de ellas ya adoptó DevOps. Los lugares de trabajo ágiles e integrados se están convirtiendo en la norma. Y probablemente en unos años, pensar en términos de DevSecOps se convierta en lo natural. Queremos ir lo más rápido posible, pero este largo camino es más rápido si cada elemento del equipo se une a la carrera.

En el siguiente episodio nos golpea una explosión de datos. La humanidad está cerca de almacenar alrededor de 40 zettabytes de información en servidores que, en su mayoría, ni siquiera existen aún. Pero, ¿cómo podemos lograr que todos esos datos sean útiles? ¿Cómo utilizamos la informática de alto rendimiento y los proyectos de código abierto para que nos sirvan esos datos? Lo averiguaremos en el episodio 6 de Command Line Heores en español.

Command Line Heroes en español es un podcast original de Red Hat. Escúchalo gratis en Spotify, Apple Podcasts, Google Podcasts o donde más te guste. Sigan programando.