Cómo fomentar una cultura DevSecOps: implementaciones en el mundo real

A lo largo del proceso continuo de implementación y maduración de un modelo DevSecOps, compartir éxitos y aprendizajes puede ayudar a todos a mejorar. Estos son ejemplos de organizaciones que adoptaron DevSecOps y trabajaron para alcanzar mayores niveles de madurez.

DevSecOps en Auth0

• Crear una experiencia sin fricciones para los desarrolladores de la nube

• Aprovechar el análisis de datos

• Priorizar los riesgos en las primeras etapas del SDL

• Habilitación colaborativa y prácticas de desarrollo flexibles

Desde sus inicios, Auth0 ha aprovechado ampliamente la infraestructura de nube de AWS para ofrecer soluciones de gestión de identidad a sus clientes. Debido a su rápido crecimiento, tanto en tamaño organizacional como en la oferta de servicios, Auth0 ha tenido que afrontar el desafío de proteger su infraestructura de nube. Duncan Godfrey, director sénior de Seguridad y Cumplimiento, participó recientemente en el pódcast The Secure Developer y habló sobre su estrategia para garantizar la seguridad de ese entorno.

Un equipo dedicado a la seguridad de la nube dentro de Auth0 es responsable de proteger el entorno de AWS. Sin embargo, para evitar que el equipo adoptara el enfoque tradicional de SecOps, la automatización centrada en la supervisión ha sido fundamental. Según Godfrey: “El mandato de ese equipo es asegurarse de que recopilemos datos de todos los aspectos y rincones posibles de AWS y los incorporemos para analizarlos”. Gracias a este enfoque, el equipo mantiene contacto con los equipos de desarrollo que trabajan con un modelo DevOps. Al colaborar con ellos, pueden obtener una mayor visibilidad general. 

Para Auth0 y su equipo de seguridad de la nube, es fundamental crear una experiencia sin fricciones para los desarrolladores. La integración de seguridad comienza en las primeras etapas del SDL con un formulario breve que ayuda a determinar el nivel de colaboración necesario con el equipo de seguridad. Las funciones de alto riesgo, como exponer puntos de conexión públicos, requieren una mayor participación del equipo de seguridad. “Los guiamos para que, con suerte, desde el principio tengamos los requisitos y los controles adecuados, de modo que terminemos con software seguro y de calidad; luego, al final, ejecutamos algunas pruebas más”, explica Godfrey.

La cultura general de Auth0 se basa claramente en la habilitación colaborativa. Busca que los desarrolladores tengan libertad para crear software con métodos que se adapten a sus necesidades, a la vez que demuestran madurez en sus prácticas de seguridad. Esto ha ayudado a Auth0 a seguir aprovechando las nuevas tecnologías mientras mantiene una postura de seguridad sólida.

DevSecOps en Segment

• Ponerse en el lugar de los desarrolladores

• Adoptar la infraestructura como código para habilitar DevSecOps

• Asegurarse de que las nuevas herramientas sean fáciles de usar para los desarrolladores

• Recursos integrados de distintas áreas

En un episodio reciente del pódcast The Secure Developer, Leif Dreizler y Eric Ellett hablaron sobre la importancia que Segment, proveedor de una plataforma de datos de clientes, atribuye a la colaboración entre los equipos de desarrollo, seguridad y operaciones. Segment no trabaja con sprints en toda la organización; en cambio, los equipos operan de forma independiente. Sin embargo, mediante un modelo de consultoría, el equipo de seguridad se integra desde las primeras etapas del proceso de desarrollo para ofrecer análisis de modelos de amenazas y revisiones de diseño.

En Segment, la empatía forma parte de la cultura del equipo de seguridad. El equipo ha adoptado el concepto de “ponerse en el lugar de los desarrolladores”. Ellett explicó que el equipo de seguridad se esfuerza por entender cómo sus procesos afectan a otras áreas de la organización. Por ejemplo, cuando quisieron implementar la autenticación multifactor, Dreizler pasó un trimestre integrado en el equipo de desarrollo. Esto le brinda al equipo de seguridad un contexto invaluable sobre los desafíos que enfrenta el equipo de desarrollo y lo que intenta proteger.

Sin embargo, el enfoque en la colaboración no termina ahí. Ellett explicó que también buscan impulsar iniciativas similares en la dirección opuesta. El plan es invitar a personas de otras áreas de la organización a trabajar junto al equipo de seguridad y entender también su realidad. Dreizler afirmó: “Creo que este debería ser el objetivo de DevSecOps. Algo parecido a DevOps, donde el personal de operaciones aprende a programar y ahora toda la infraestructura de Segment está definida como código”.

Segment también cree firmemente en crear el “camino pavimentado”. Uno de los principios que guía al equipo de seguridad de Segment es: “¿Usaría esta herramienta un desarrollador?”. En otras palabras, se centran en garantizar que la facilidad de uso permita adoptar los controles de seguridad. Según Dreizler, el objetivo final es: “Hacer que sea lo más fácil posible que las personas hagan lo correcto”.

Con este enfoque colaborativo y empático, Segment ha logrado fomentar una sólida cultura de colaboración en su organización: un ejemplo de cómo hacer realidad la promesa de DevSecOps, asegurándose de que todas las áreas estén alineadas con el objetivo de hacer lo correcto para la organización.

10X Banking adopta DevSecOps

• Transparencia sobre las vulnerabilidades de seguridad en toda la organización

• Reuniones diarias de seguimiento entre distintas áreas para reunir a todos

• Aprovechar la automatización para gestionar la implementación de código seguro

• Usar un juego de cartas sobre modelos de amenazas para involucrar a las partes interesadas en el proceso

Neil Drennan, de 10x Future Technologies, participó con Guy Podjarny en un episodio reciente del pódcast The Secure Developer. Drennan compartió cómo la organización aprovecha algunas estrategias de comunicación clave para fomentar la participación en las prácticas de seguridad mientras construye la primera plataforma bancaria nativa de la nube. Desde garantizar la transparencia y una comunicación eficaz hasta impulsar la colaboración en las actividades diarias y adoptar medidas de seguridad proactivas, 10x se enfoca en hacer que la seguridad sea responsabilidad de todos.

Durante la conversación, Guy y Neil empezaron a explorar cómo 10x logra que colaboren los equipos de seguridad externos y los equipos internos de plataforma. Neil explicó que en 10x todos pueden consultar el estado actual de las vulnerabilidades que registran las herramientas incorporadas al entorno. “Cuando usamos herramientas y generamos alertas sobre las vulnerabilidades detectadas, la información es transparente y está disponible para todos. Cualquier persona del equipo puede consultar el estado actual de las vulnerabilidades en toda la organización”, comentó Drennan. Esta transparencia es fundamental para garantizar que todos los equipos comprendan su papel en la responsabilidad compartida de entregar software seguro.

Sin embargo, la colaboración va más allá de tener visibilidad sobre las vulnerabilidades actuales. Mediante reuniones diarias de seguimiento que reúnen a personas de distintos equipos de la empresa, 10x se asegura de considerar diversas perspectivas al hablar sobre las vulnerabilidades de seguridad actuales. Neil comentó: “Revisamos [las vulnerabilidades actuales] en nuestra reunión diaria con todos los equipos, así que no se trata solo de una función de entrega. Todos nos reunimos cada mañana para hablar de aspectos funcionales, no funcionales y de seguridad”. Drennan señaló que esta estrategia es especialmente importante para la forma en que su organización enfrenta un panorama de amenazas cada vez más dinámico.

Drennan destacó la eficacia de estas interacciones: “Creo que eso ayuda mucho a que los equipos sean más eficaces, y contar con un canal de comunicación abierto entre ellos es sumamente importante”. Esto refuerza el concepto de responsabilidad compartida por el software seguro y garantiza que forme parte de la cultura de la organización. Es una excelente manera de fomentar la empatía y el entendimiento entre los distintos roles de la empresa.

Neil también describió cómo 10x se asegura de que la seguridad se considere desde las primeras etapas del proceso de entrega mediante el modelado de amenazas. En su informe State of DevOps de 2019, Puppet identificó que los esfuerzos colaborativos de modelado de amenazas tienen un impacto muy significativo en la postura de seguridad general de una organización. Para lograr que las partes interesadas participen activamente en esta actividad crucial, 10x usa juegos de cartas de modelado de amenazas para identificar amenazas según el modelo STRIDE. “Reunir a los equipos con sus mazos de cartas y hacer que representen distintos escenarios de vulnerabilidades de seguridad es una forma muy atractiva de entusiasmarlos con la seguridad y de ayudarlos a pensar continuamente en lo importante”, comentó Drennan.

Al centrarse en los fundamentos de las personas, los procesos y la tecnología, 10x ha podido implementar prácticas únicas que han creado una cultura de seguridad en torno a la entrega de software. Su enfoque demuestra cómo estos tres elementos se complementan de forma colaborativa para garantizar que 10x entregue software eficiente, confiable y seguro.

Cómo abordar la cultura DevSecOps en Datadog

• Eliminar barreras y avanzar hacia la integración de la seguridad en las etapas del proceso de entrega

• Integrar personal de seguridad en los equipos de desarrollo para fomentar la empatía y la responsabilidad compartida

• Incorporar la seguridad como colaboradora funcional en la automatización del proceso de entrega

DataDog es un ejemplo de cómo la búsqueda de automatización y de integrar la seguridad en el proceso de entrega comienza por abordar primero los desafíos relacionados con las personas. La empresa creó un programa para fomentar la empatía entre áreas aisladas de la organización e impulsar una mejor colaboración. También involucró al equipo de seguridad como colaborador activo en la automatización y las herramientas del proceso de entrega. Cuando participó en The Secure Developer Podcast, Douglas DePerry era director de Seguridad de Producto en Datadog y compartió algunos de sus enfoques innovadores para resolver estos desafíos clave de DevSecOps.

A menudo, los intentos de avanzar hacia una forma más rápida y mejor de desarrollar software no funcionan. Cuando implementas en producción decenas de veces al día, es imposible revisar todo. Datadog integró ingenieros de seguridad en los equipos de desarrollo, a veces durante unas semanas y otras durante meses. Para ellos, crear conciencia es una prioridad. También buscan dejar claro que la seguridad es responsabilidad de todos: “Déjame ayudar a corregir algunos de estos problemas pequeños que quedaron pendientes o estos errores de seguridad”, además de enseñar y aprender sobre la marcha.

Según DePerry: “El equipo de seguridad debe escribir más código. Se necesita más automatización. Así se logra un efecto multiplicador y se puede seguir el ritmo al que se implementa el código”. Una forma en que Datadog abordó este desafío fue desarrollar una herramienta adaptada a sus necesidades, que ayudara al equipo de seguridad a proporcionar a los equipos de desarrollo mensajes prácticos y tareas de corrección basados en el código que escribían.

Datadog había invertido anteriormente en una herramienta de análisis estático de seguridad (SAST). Al principio, la incorporaron para demostrar el cumplimiento, pero, lamentablemente, no se adaptaba a sus necesidades ni se integraba bien en su proceso de DevOps existente. Así que innovaron y escribieron su propia herramienta para realizar análisis SAST y de composición de software (SCA). DePerry comentó: “Sin mucha creatividad, le pusimos Middleware a la herramienta, que básicamente era un framework al que podíamos agregar complementos. Así, teníamos un complemento para análisis estático y otro para detectar vulnerabilidades en las dependencias”.

DePerry también nos dijo: «Tienes que enfocarte en aquello que te afectará primero; pero ¿cómo decides realmente qué es? Y creo que, cuanto más puedas hacerlo —porque ahora mismo es difícil medir ciertas cosas—, más difícil o propenso a errores resulta. Por eso creo que los pronósticos, si se hacen correctamente, pueden ser de gran ayuda».

Cultura cloud native en Pivotal

• La importancia de convertir la seguridad en un cambio cultural durante las transformaciones cloud native

• Crear barreras de seguridad en lugar de bloqueos para guiar a los desarrolladores hacia una ruta segura

• Emparejar a desarrolladores y profesionales de seguridad para fomentar la empatía y la responsabilidad compartida

La adopción de DevSecOps y la transformación hacia tecnologías cloud native suelen ir de la mano. Para garantizar que la organización pueda adaptarse a estos nuevos paradigmas sin comprometer la seguridad, también debe atravesar una transformación cultural. Por su parte, la seguridad debe dejar atrás la idea de implementar controles como bloqueos en el pipeline de entrega. Gran parte de esto se puede lograr fomentando la empatía y la responsabilidad compartida entre desarrolladores y profesionales de seguridad.

Steve White, CISO de campo de Pivotal (ahora una subsidiaria de VMware), participó recientemente en el podcast Secure Developer. En su episodio, compartió algunas de sus ideas sobre la transformación a la nube, el papel de la seguridad en el pipeline de DevSecOps y cómo unir a los equipos de seguridad y desarrollo puede conducir a mejores resultados. Steve dedica gran parte de su tiempo a trabajar con líderes y ejecutivos de seguridad en la arquitectura de seguridad de ingeniería. También organiza talleres prácticos con representantes de las distintas disciplinas de DevSecOps para enseñarles cómo es la seguridad cloud native en la práctica.

Un elemento crucial para transformar una organización mediante la adopción de DevSecOps es asegurarse de ir más allá de las herramientas. «El primer principio del cambio en este ámbito es que no se trata solo de un cambio tecnológico, aunque sí debe haber cierta evolución tecnológica. Es un cambio cultural y de perspectiva que, en última instancia, representa la parte más importante de lo que debe suceder en la seguridad de la información, tal como ocurrió en el resto de la empresa», compartió White. Esto reconoce que DevOps ha impulsado muchos cambios culturales que el área de seguridad también debe alcanzar.

Una de las perspectivas clave que a los profesionales de seguridad les ha costado adoptar es cómo integrar las prácticas de seguridad en el pipeline. White afirmó: «La frase que me gusta usar es que estamos pasando de los bloqueos a las barreras de seguridad, ¿verdad? De ahora en adelante, la función de seguridad en la empresa debería ser proporcionar estas… Son como una red de protección, ¿no? Hay una barrera superior y otra inferior que te protegen de sobrepasar límites realmente peligrosos, pero dentro de esas barreras». Esta perspectiva destaca un aspecto clave para que seguridad adopte el movimiento DevOps de una forma creíble y, sobre todo, compatible.

Otra forma de generar credibilidad para el área de seguridad entre los desarrolladores que participan en la entrega de software es fomentar la empatía. Cuando los profesionales de seguridad y los desarrolladores colaboran en sus tareas diarias, pueden generar credibilidad y valorar el trabajo de los demás. White amplió esta idea: «Cuando hablo de trabajar en pareja, me gustaría que fuera en el sentido estricto de la programación en pareja: dos personas frente a una pantalla, trabajando juntas para resolver un problema. Si una es ingeniera de seguridad y la otra desarrolla funcionalidades, ambas aprenden mucho y aportan bastante a la conversación».

En general, White aborda algunos de los principios clave que deben formar parte de cualquier cultura DevSecOps. En algunos casos, cloud native impulsa la adopción de DevSecOps y, en otros, la adopción de DevSecOps impulsa la transformación a la nube. Es fácil ver cómo ambas van de la mano. Las organizaciones deben tener presente la relación entre las dos y prepararse para adoptar ambas como parte de un gran cambio en la cultura organizacional que permita obtener valor para el negocio.

DevSecOps en Cisco/Duo

• Acercar la seguridad al pipeline: «ir a donde trabajan» los desarrolladores

• Adelantar la seguridad para definir diseños seguros al identificar nuevas oportunidades tecnológicas

• Las métricas deben ser más sofisticadas y enfocarse en la mejora continua

La cultura DevSecOps se basa en la eficiencia en todo el pipeline: permite que los desarrolladores pasen del backlog al despliegue con la mayor eficiencia posible. Para que la seguridad forme parte del pipeline, las prácticas seguras deben integrarse sin fricciones. Para facilitarlo, adelantar la seguridad y definir diseños seguros lo antes posible ayuda a allanar el camino para los desarrolladores cuando comienzan a programar la funcionalidad que necesitan. Sin embargo, si no puedes medir eficazmente cómo afectan las prácticas a tu postura de seguridad, se vuelve sumamente difícil justificar que sigan integradas en el pipeline.

Michael Hanley, CISO de Cisco y exdirector de Duo Security, participó en el podcast The Secure Developer y compartió algunos de los enfoques que Cisco/Duo ha adoptado para abordar estos problemas. Michael se unió a Cisco como parte de la adquisición de Duo en 2018, donde pasó cinco años dirigiendo sus iniciativas de seguridad. Sus perspectivas sobre cómo integrar la seguridad en las herramientas que ya usan los desarrolladores, adelantar la seguridad para diseñar de forma proactiva y recopilar métricas significativas se basan en toda esa experiencia.

Al desarrollar una cultura DevSecOps, muchas organizaciones piensan en las herramientas necesarias para que el pipeline avance más rápido. Al principio del movimiento DevOps, el enfoque estaba en automatizarlo todo: los commits de código iniciaban compilaciones automatizadas, la promoción de código activaba pruebas de regresión automatizadas, etc. Sin embargo, tradicionalmente a seguridad le ha costado incorporar procesos y herramientas que se ajusten a este modelo, lo que termina generando más fricción.

Esta fricción frustra a los desarrolladores y puede dificultar la adopción de prácticas seguras. Hanley compartió que en Duo se enfocaron en integrarse con las herramientas existentes. Nos dijo: «…vamos a donde a nuestros ingenieros les resulta más fácil trabajar y colaborar con nosotros. Por ejemplo, usamos los mismos sistemas de tickets que para el control de código fuente y el resto del seguimiento de ingeniería, y solemos trabajar mucho con nuestros equipos de ingeniería en esos mismos espacios para facilitarles las cosas». Esta idea de acercarse a los desarrolladores en sus espacios habituales e integrarse con las herramientas que ya conocen es una forma eficaz de construir una verdadera cultura DevSecOps.

Sin embargo, Hanley también comentó otro concepto importante para incorporar la seguridad al pipeline: adelantarla. Aunque la idea no es nueva, en una cultura DevSecOps los equipos de seguridad deben adelantarla cada vez más. «…si lo comparo con el ciclo de vida de desarrollo de software que tenemos en Duo, diría que, en la etapa más temprana, el equipo de Labs participa para identificar estratégicamente nuevas oportunidades tecnológicas, pero también para definir desde el principio cómo deberían ser los parámetros de un buen diseño de seguridad…», dijo Hanley.

Este enfoque es importante y muy innovador. Al empezar a identificar los diseños de seguridad antes de que una historia de usuario siquiera llegue al backlog, las organizaciones pueden asegurarse de que los desarrolladores tengan requisitos de seguridad documentados desde la fase más temprana del pipeline. Así, el trabajo de diseño de seguridad no afecta la capacidad de entregar código rápidamente. La seguridad se convierte en un facilitador, porque los desarrolladores pueden pasar más rápido de esos diseños a la programación. Además, no tienen que preocuparse por omitir aspectos de seguridad que se conviertan en fallas por corregir en futuros sprints.

¿Cómo sabe una organización si estos enfoques están dando el resultado esperado? Aquí es donde las métricas son cruciales. «En general, tengo un verdadero problema con las métricas de seguridad y con contar errores de forma cuantitativa… No son lo suficientemente sofisticadas para describir muchos programas y, en particular, el nuestro», dijo Hanley. Muchas organizaciones enfrentan este problema. Un simple recuento de errores abiertos no tiene contexto. ¿Cuántas versiones se lanzaron y generaron esas vulnerabilidades? Si el número de vulnerabilidades es bajo, ¿se debe a que mejoró la seguridad o a que la aplicación no se ha probado en mucho tiempo? Los programas de métricas necesitan más contexto.

Hanley contó cómo Cisco/Duo usa un modelo de madurez para medir el éxito de su programa. «El modelo de madurez que usamos en Duo combina BSIMM y SAMM… Intentamos identificar cuáles son las métricas clave que se desprenden de él, cuál es el porcentaje de actividades… con cobertura al menos parcial y cuál es el porcentaje con cobertura completa», explicó Hanley.

También mencionó otro concepto importante que cualquier organización debería tener en cuenta sobre las métricas. Hanley explicó que su enfoque les ayudó a centrarse en un modelo de mejora continua. Muchas iniciativas de seguridad fracasan porque buscan alcanzar objetivos extraordinarios que simplemente no son realistas. En cambio, si enfocamos nuestras metas en mejorar en lugar de alcanzar un resultado final, dejamos espacio para cometer errores, adaptarnos e innovar. En última instancia, así es más fácil demostrar el valor para el negocio de las prácticas de seguridad.

Los conceptos que Hanley compartió a partir de su experiencia en Duo reflejan las necesidades que enfrenta cualquier organización que busque desarrollar una cultura DevSecOps.

Seguridad en la nube con 2nd Sight Lab

• Empoderar a los desarrolladores enseñándoles las mejores prácticas de seguridad en la nube

• Fomentar la empatía entre desarrolladores y profesionales de seguridad

• La gobernanza como componente de la seguridad en la nube

Como la transformación a la nube ocupa un lugar central en las estrategias de TI de la mayoría de las organizaciones, los desafíos de proteger esos entornos pueden intensificarse. Puede ser difícil permitir que los desarrolladores aprovechen las tecnologías cloud native sin poner en riesgo la seguridad. Además, es fundamental garantizar que las distintas disciplinas de la organización colaboren y comprendan el panorama general para proteger entornos complejos en la nube. Por último, monitorear el programa y aprender de los errores es esencial cada vez que transformamos el negocio de esta manera.

Guy Podjarny conversó con Teri Radichel, CEO de 2nd Sight Lab y autora de Cybersecurity for Executives in the Age of Cloud. Teri explicó cómo se adentró en el mundo de la seguridad en la nube después de sufrir una brecha en su anterior empresa de desarrollo y alojamiento de aplicaciones web. 2nd Sight Lab es una empresa de consultoría y capacitación en seguridad en la nube. Gran parte de lo que compartió Teri no provenía de implementar tecnología en la nube en una sola organización, sino de su trabajo de consultoría con varias organizaciones.

Un problema fundamental que surge al hablar de la nube y su transformación es definir qué significa «nube». En palabras de Teri: «Algunas personas dicen que es simplemente la computadora de alguien más, pero yo siempre digo que es más que eso, porque cuando trabajaba en un centro de alojamiento administrado, también era la computadora metálica de alguien más, ¿verdad?». Para algunas organizaciones, incluso el uso de soluciones de software como servicio (SaaS) puede formar parte de su estrategia de nube.

A la complejidad de entender qué es la nube se suma la naturaleza dinámica de las tecnologías cloud native, que hace que confiemos a los desarrolladores mucha responsabilidad en materia de seguridad. Teri habló de esta complejidad: «Si eres desarrollador y ahora te piden crear redes o configurar buckets de S3, balanceadores de carga o CDN, realmente tienes que investigar cuáles son las mejores prácticas». Para abordar esto, les dio un consejo a los desarrolladores: «Existen los CIS Benchmarks, que te indican las mejores prácticas para los tres principales proveedores de nube».

Por supuesto, otra clave para abordar la complejidad de la seguridad en la nube es lograr que los desarrolladores y los expertos en seguridad trabajen juntos para compartir conocimientos, comprender sus respectivos trabajos y avanzar hacia un objetivo común: crear software seguro. Radichel señaló que el equipo de seguridad debe asumir un papel activo en este sentido. «Creo que la seguridad cumple una función muy importante que no implica trabajar directamente con el teclado. No se trata de la seguridad de las aplicaciones ni de asegurarse de que tu código no tenga una vulnerabilidad de scripting entre sitios. La seguridad se trata de riesgos», compartió.

Por último, en cualquier transformación a gran escala, también es sumamente importante garantizar que los procesos y procedimientos definidos se sigan de manera coherente y que aprendamos de los errores. Radichel reconoce que «las personas también cometen errores, así que tienes que pensar en la gobernanza general de tu organización y en cómo vas a estructurarla para que las personas no puedan cometer esos errores, ¿verdad?»

En última instancia, aprovechar el modelo de responsabilidad compartida propio de una verdadera cultura DevSecOps impulsa mejores prácticas en toda la transformación a la nube. Las observaciones y sugerencias clave de Radichel demuestran la importancia de que todos los equipos que participan en el proceso de entrega trabajen juntos, compartan conocimientos y se enfoquen en un objetivo común.