Command Line Heroes: segunda temporada: Sobre DevSecOps

DevSecOps

13 de marzo de 2018 | Command Line Heroes Team

DevOps

Seguridad

Automatización de la seguridad

Historia de la tecnología

Command Line Heroes • • Command Line Heroes: segunda temporada: Sobre DevSecOps

Command Line Heroes: segunda temporada: Sobre DevSecOps

About the episode

Las malas prácticas de seguridad y confiabilidad pueden causar interrupciones que afecten a millones de personas. Ya es hora de que la seguridad se vuelva parte del movimiento DevOps, porque cuando vivamos en un mundo DevSecOps, podremos dejar volar nuestra creatividad para mejorarla.

Antes los equipos encontraban un punto vulnerable al mes. Hoy, el desarrollo de software avanza rápidamente gracias a los procesos ágiles y los equipos de DevOps y Vincent Danen nos explica cómo eso nos ha llevado a un drástico aumento de los puntos vulnerables. Jesse Robbins, el ex maestro de los desastres en Amazon, explica cómo actualmente las empresas se preparan para los errores y problemas catastróficos. Y Josh Bressers, director de seguridad de los productos en Elastic, analiza el futuro de la seguridad en la tecnología.

No podemos tratar a los equipos de seguridad como si fueran gruñones malhumorados. Escucha el podcast para saber cómo hacen los equipos de DevSecOps para reunir a los héroes y mejorar la seguridad.

Command Line Heroes Team Red Hat original show

Transcripción

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 procesos de DevOps se aceleraron, la calidad del software en realidad mejoró. El problema es que simplemente hay mucho más software de lo que había antes.

Entonces, no es que tengamos más puntos vulnerables per cápita, es que tenemos más software per cápita. Y con más software, naturalmente vas a encontrar más puntos vulnerables.

Y aquí es donde entra la automatización. Cuando tienes más software siendo desarrollado más rápidamente, necesitas herramientas automatizadas para mantener el ritmo de los análisis de seguridad.

Tenemos que ser capaces de automatizar el análisis de seguridad tanto como sea posible. No podemos depender de revisiones manuales para cada pieza de código que sale por la puerta.

Pero la automatización es solo parte de la solución. También necesitamos cambiar la forma en que pensamos sobre la seguridad. En lugar de verla como algo que se agrega al final del proceso de desarrollo, necesitamos integrarla desde el principio.

La seguridad tiene que ser parte del DNA del desarrollo. No puede ser algo que pensamos al final. Tiene que estar incorporada en cada paso del proceso.

Esta idea de "shift left" - mover la seguridad hacia la izquierda en el ciclo de desarrollo - es fundamental para DevSecOps. En lugar de esperar hasta el final para pensar en seguridad, los equipos la consideran desde el diseño inicial.

Pero esto requiere un cambio cultural significativo. Los equipos de desarrollo tienen que estar dispuestos a ralentizar un poco su velocidad inicial para ganar velocidad sostenible a largo plazo.

Y los equipos de seguridad tienen que estar dispuestos a trabajar de manera más colaborativa, en lugar de actuar como guardias que bloquean releases.

Para entender mejor cómo se ve esto en la práctica, hablé con Jesse Robbins, quien tiene una perspectiva única sobre la confiabilidad y la seguridad de sistemas.

Soy Jesse Robbins, CEO de Orion Labs. Anteriormente fui VP de Operaciones en Amazon, donde me conocían como el "Master of Disaster" porque mi trabajo era literalmente romper cosas para ver cómo fallarían.

Jesse tiene un trasfondo interesante: antes de entrar al mundo tech, era bombero. Y esa experiencia le dio una perspectiva única sobre cómo prepararse para lo peor.

Como bombero, aprendes que los desastres van a suceder. Tu trabajo no es prevenir todos los incendios - tu trabajo es estar preparado para responder efectivamente cuando sucedan.

Esa mentalidad se tradujo perfectamente al mundo de la tecnología, especialmente cuando Jesse llegó a Amazon en los primeros días del cloud computing.

En Amazon, desarrollamos algo llamado "Game Day" - ejercicios donde deliberadamente rompíamos cosas en producción para ver cómo respondían nuestros sistemas y nuestros equipos.

Game Day se convirtió en una práctica fundamental en Amazon, y la idea se extendió por toda la industria. La premisa es simple: si no practicas respondiendo a desastres, no estarás preparado cuando sucedan realmente.

Lo que descubrimos es que los equipos que regularmente practicaban respondiendo a fallas eran mucho mejores manejando incidentes reales. Y también construían sistemas más resilientes, porque estaban constantemente pensando en qué podría salir mal.

Esta filosofía de "chaos engineering" - deliberadamente introducir fallas para probar la resiliencia del sistema - se ha convertido en una práctica estándar en muchas organizaciones.

Netflix popularizó esto con su "Chaos Monkey", que aleatoriamente termina servicios en producción. Suena loco, pero es increíblemente efectivo para encontrar puntos débiles antes de que causen problemas reales.

Pero Jesse enfatiza que la tecnología es solo parte de la ecuación. El aspecto humano es igualmente importante.

Los mejores sistemas de respuesta a incidentes no son solo sobre tener las herramientas correctas. Son sobre tener la cultura correcta - una cultura donde las personas se sienten seguras reportando problemas, donde se premia la transparencia, donde se aprende de los errores en lugar de castigarlos.

Esta idea de cultura sin culpa es fundamental para DevSecOps. Si las personas tienen miedo de reportar problemas de seguridad, esos problemas permanecerán ocultos hasta que sea demasiado tarde.

Y Jesse ha visto cómo esta mentalidad puede extenderse más allá de la tecnología hacia la sociedad en general.

Como bombero, trabajaba con comunidades para hacer preparación para desastres. La misma mentalidad que aplicamos en tecnología - practicar respuestas, construir resiliencia, crear cultura de preparación - se aplica a nivel comunitario.

Esto es particularmente relevante ahora, cuando la tecnología es tan fundamental para la sociedad. Cuando los sistemas tecnológicos fallan, puede afectar servicios esenciales como hospitales, sistemas de transporte, y redes de comunicación.

Tenemos una responsabilidad como industria de construir sistemas resilientes. No es solo sobre el uptime de nuestras aplicaciones - es sobre la infraestructura digital de la que depende la sociedad.

Esta responsabilidad se extiende a la seguridad también. Los ataques cibernéticos pueden tener consecuencias que van mucho más allá de una empresa individual.

Y aquí es donde volvemos a la importancia de integrar seguridad en DevOps. No es solo una buena práctica de negocio - es una responsabilidad social.

Pero, ¿cómo se ve esto en la práctica? ¿Cómo implementas realmente DevSecOps en una organización?

Para responder a esa pregunta, hablé con Josh Bressers, quien lidera seguridad de productos en Elastic y ha visto la evolución de las prácticas de seguridad de primera mano.

Una de las cosas más importantes que he aprendido es que DevSecOps no es solo sobre herramientas - es sobre personas y procesos.

Josh enfatiza que la implementación exitosa de DevSecOps requiere cambios en tres áreas: tecnología, procesos, y cultura.

En el lado tecnológico, necesitas herramientas que puedan integrarse en tu pipeline de CI/CD. Análisis estático de código, escaneo de dependencias, pruebas de penetración automatizadas - todas estas cosas tienen que suceder automáticamente.

Pero las herramientas por sí solas no son suficientes. También necesitas cambiar tus procesos para incorporar consideraciones de seguridad en cada etapa.

Los equipos de desarrollo necesitan entender las amenazas básicas de seguridad. Los equipos de operaciones necesitan entender cómo configurar sistemas de manera segura. Y los equipos de seguridad necesitan entender cómo trabajar de manera colaborativa en lugar de ser bloqueadores.

Y esto nos lleva al aspecto más difícil: el cambio cultural.

Tradicionalmente, la seguridad ha sido vista como el equipo que dice "no" a todo. Tenemos que cambiar esa percepción. La seguridad debería ser vista como un facilitador que ayuda a los equipos a construir cosas de manera segura.

Este cambio de mentalidad es crucial. En lugar de ver la seguridad como un obstáculo, necesitamos verla como un facilitador de velocidad sostenible.

Cuando tienes buenas prácticas de seguridad integradas desde el principio, puedes moverte más rápido a largo plazo porque no tienes que parar para arreglar problemas de seguridad más tarde.

Josh también señala que DevSecOps requiere nuevas métricas de éxito.

No podemos solo medir cuántas vulnerabilidades encontramos. Tenemos que medir qué tan rápido las arreglamos, qué tan bien prevenimos que lleguen a producción, y qué tan efectivamente respondemos cuando algo sale mal.

Estas métricas orientadas al rendimiento ayudan a cambiar la conversación de "¿es seguro?" a "¿qué tan rápido podemos hacer que sea seguro?"

Pero Josh también reconoce que estamos en las primeras etapas de la evolución de DevSecOps.

La industria de la seguridad está aún en pañales comparada con el desarrollo de software en general. Estamos apenas comenzando a entender cómo integrar efectivamente la seguridad en pipelines de desarrollo modernos.

Y eso significa que hay mucha experimentación e innovación sucediendo en este espacio.

Una de las áreas más emocionantes es el análisis de comportamiento. En lugar de solo mirar si alguien tiene las credenciales correctas, podemos mirar si se están comportando de manera normal.

Esta aproximación de análisis de comportamiento representa un cambio fundamental de seguridad basada en perímetro a seguridad basada en confianza.

Si sabemos cómo normalmente trabaja alguien - qué aplicaciones usan, a qué horas, desde dónde se conectan - podemos detectar cuando algo está fuera de lo normal y responder apropiadamente.

Pero esto también plantea preguntas importantes sobre privacidad y confianza.

Tenemos que ser muy cuidadosos sobre cómo implementamos estos sistemas. La seguridad no puede venir a costa de la privacidad o la autonomía de los empleados.

Y esto nos lleva de vuelta a la importancia de la cultura. Los sistemas de seguridad más sofisticados no funcionarán si las personas no confían en ellos o no entienden por qué existen.

Josh tiene una observación interesante sobre cómo la percepción de la seguridad está cambiando en las organizaciones.

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.

Sobre el podcast

Command Line Heroes

During its run from 2018 to 2022, Command Line Heroes shared the epic true stories of developers, programmers, hackers, geeks, and open source rebels, and how they revolutionized the technology landscape. Relive our journey through tech history, and use #CommandLinePod to share your favorite episodes.

DevSecOps