Una introducción al podcast de Edgio Beyond the Edge Episodio 4: DevSecOps: Gire a la izquierda para evitar cambiar la hoja de ruta de su producto a la derecha, organizado por Lauren Bradley, gerente de campaña global de Edgio.
Lauren Bradley: Hey ahí, y bienvenidos a Beyond the Edge, donde profundizamos en los entresijos de los negocios digitales modernos. Soy Lauren Bradley, su copiloto para este episodio, y hoy, vamos a explorar el tema de cambiar a la izquierda, específicamente cómo la cultura y la tecnología cambian a medida que las aplicaciones web y la protección de API se convierten en una parte nativa e inherente de su ciclo de vida de DevOps.
Comencemos con una estadística impactante del Instituto Ponemon. Hoy en día, la mayoría de las empresas tarda más de 200 días en detectar una violación. Si no estás detectando una violación lo suficientemente rápido, te va a costar mucho. IBM encontró que el costo de los bugs fijos encontrados durante la etapa de prueba puede ser 15 veces más que los encontrados durante el diseño.
Así que, para decirlo de manera simple, cuanto más esperes para detectar un problema, más te va a costar. Y, no solo estamos hablando de dinero, el retrabajo, el tiempo y la energía pueden, en última instancia, cambiar las hojas de ruta de los productos. Entonces, ¿cómo puedes desplazarte a la izquierda y evitar desperdiciar valiosos recursos y estancar tu progreso?
Nos acompañan Michael Grimshaw, Director de Ingeniería de Plataformas de Edgio, y Richard Yew, Director Senior de Gestión de Productos de la Plataforma de Seguridad de Edgio. Bienvenidos, Michael y Richard. Es genial tenerte puesto.
Michael Grimshaw: Gracias, Lauren. Genial estar aquí. Gracias.
Lauren Bradley: ¿Podrían hablarme un poco sobre ustedes mismos y sus pensamientos iniciales sobre este tema? Mike, empezaremos contigo.
Michael Grimshaw: Absolutamente. En primer lugar, permítanme comenzar agradeciendo, agradeciéndole a usted, Lauren, por tener tanto interés. En este tema tan importante y, y usted está profundizando y aumentando y las conversaciones que hemos tenido y estamos teniendo sobre esto, incluyendo este año aquí está, es solo un invaluable e imperativo para el trabajo que estamos haciendo en la industria.
Michael Grimshaw: Este entendimiento debe ser compartido a lo largo y ancho y, y realmente apreciar el interés. Mi nombre es Michael Grimshaw. Soy el Director de Ingeniería de Plataformas aquí en Edgio. Para aquellos de ustedes que no están familiarizados con, o súper familiarizados con la plataforma en términos de industria, realmente está pensando en términos de la unificación de sus aplicaciones e infraestructura en unidades coherentes.
Y, vengo a la plataforma con una gran experiencia en seguridad, y este es un área que me apasiona porque mueve la aguja de una manera tan grande, en cuanto a seguridad, en cuanto a rentabilidad, y tantas de las áreas que son tan importantes para nuestra industria.
Y puedo seguir con DevSecOps, pero déjenme entregarlo a Richard para su introducción.
Richard Yew: Muchas gracias, Michael. Sí. Sí. Este es un tema muy importante. Es muy cercano y querido en mi corazón porque personalmente he vivido a través de todo el proceso del ciclo de vida del desarrollo de software, así como traducirlo al negocio.
Ahora, hablando de lo que hago… Obviamente, como mencionó Lauren, dirijo nuestras organizaciones de gestión de productos de seguridad en Edgio. Por lo tanto, mi vida cotidiana implica trabajar con el equipo de I+D, el equipo de ingeniería para garantizar que estamos entregando valor a nuestros clientes. Y, ya sabes, todo lo que obviamente incluiría, como optimizar nuestra práctica de desarrollo, nuestra seguridad, práctica de CI CD. para garantizar que realmente somos capaces de entregar productos seguros.
Correcto. Eso realmente proporciona valor a nuestros clientes, los entrega a tiempo, dentro de los presupuestos, y asegura que proporcionamos una gran experiencia a nuestros clientes. Entonces, mi objetivo en esto es mirar realmente a todo el DevSecOps, ya saben, desde una perspectiva de las personas, el proceso en lugar de la tecnología y cómo podemos implementar las mejores prácticas, para, la industria.
¿Qué es DevSecOps?
Michael Grimshaw: A tu punto, Richard, déjame robar la pelota allí si no te importa.
Y solo creo que estandarizemos lo que queremos decir con DevSecOps y SHIFT left shift, ¿verdad? Estaba Gartner, aquí están las cosas para algunas personas que escuchan en este DevSecOps, y los términos shift left, shift right, etc. podrían sonar relativamente nuevos. Esto no es nuevo, ya sabes, no es como, oh, la cosa más nueva más caliente que acaba de golpear hace un año.
No, esto ha estado horneando en la industria durante bastante tiempo. Y de hecho, Gartner tenía un informe de 2017 sobre el ciclo de vida de DevSecOps. Era realmente una extensión de DevOps, la tendencia DevOps en la industria, que se extendía para incluir la seguridad en el infosec en el bucle de retroalimentación y su ciclo de vida de desarrollo de software.
Y así, como dije, Gartner estaba escribiendo alrededor, escribiendo sobre esto, allá por 2017, y ya había sido, un proceso y un movimiento en la industria. Durante bastante tiempo antes de eso. Entonces, estos no son conceptos completamente nuevos. Es, solo una extensión de lo que hemos estado trabajando durante años. Y efectivamente lo que es DevSecOps, es que toma el modelo similar, de DevOps en que usted tiene un lado de desarrollo y realmente un lado de operación.
Y en el quid, se está construyendo en todas sus necesidades de seguridad lo antes posible, quiero decir, desde el inicio del diseño, construir el, ya sabes, todo el proceso hasta donde sus desarrolladores en el barco a la izquierda está en el lado del desarrollo, discúlpeme, el cambio a la derecha es más en el lado de la observabilidad de las operaciones. Nos vamos a centrar en el cambio del lado izquierdo aquí hoy, pero básicamente está horneando en sus pruebas sus escaneos y su validación, tan pronto como a la izquierda. Y tan pronto como sea posible en el ciclo de vida de desarrollo en su SDLC. Así, por ejemplo, una de las cosas de las que habla, y de nuevo, esto se remonta a más de siete años, son cosas como tener seguridad, escanear y escanear sus bibliotecas de terceros de código abierto, repositorios, código base, así como el código que escribe, el diseño, la arquitectura, las nueve yardas enteras, y hornear eso desde el principio. Y uno de los ejemplos que he estado dando es la construcción y el escaneo de seguridad en los mismos IDEs que usan sus desarrolladores. Es solo un ejemplo, y hay muchos de ellos.
Así que mientras escriben su código, obtienen retroalimentación inmediata. Oh, acabo de dejar la puerta abierta a, ya sabes, relleno de credenciales o inyección de secuelas, y se obtienen como un error de sintaxis, reciben un error de seguridad justo ahí está la escritura del código. Por lo tanto, pueden arreglar eso inmediatamente, para que no tengan un cliente quejándose de que el cliente o usuario final sea empeñado, ya sabes, un mes después, no, se maneja allí mismo.
Más barato, más rápido, más fácil al principio. Richard, ibas a decir algo.
¿Por qué Shifting Left es tan importante cuando se trata de costo?
Richard Yew: Oh, sí. Sí. Como creo que el costo es muy importante de hablar, ya saben, bueno, todo el mundo sabe muchos costos operativos, ya saben, cualquier organización, es como el desarrollo, ¿verdad? El proceso de I+D.
Entonces, cuando se trata de costos, es por eso que cambiar a la izquierda es más importante, ¿verdad? Porque estamos poniendo mucho esfuerzo y hablando del por qué, ya sabes, estoy seguro de que vamos a entrar en el “cómo” más adelante, pero queremos volver a casa sobre la razón por la que esto es tan importante porque, ya sabes, tenemos datos.
Sí. Eso, de acuerdo con nuestra investigación, muestra que usted sabe, si está solucionando una vulnerabilidad de seguridad que se encontró después de liberar su código y sus producciones cuestan 15 veces más de lo que sabe cuando se encuentra en una fase de diseño cuando está realizando el montaje de amenazas. Obviamente, no estamos diciendo que usted sabe, la fase temprana del esfuerzo de desarrollo podría captar por completo todas las vulnerabilidades de seguridad.
Por eso necesitamos implementar la defensa en profundidad. Pero es muy importante que sepas, al mirar las ocho fases, sabes, en general, de los ciclos de la deuda, los ciclos de vida de, ya sabes, planificar, programar, construir, probar, todo el camino para que me guste monitorear y operar. Correcto. Los miras a la derecha, ya sabes, como cuando encuentras una vulnerabilidad de seguridad, más costoso va a tomar, ya sabes.
Para que sus organizaciones realmente solucionen el problema. Entonces, estamos hablando de la diferencia entre, ya sabes, encontrar una vulnerabilidad en un escaneo que ocurre después de que ya publicaste un montón de códigos para las producciones versus, por ejemplo, hacer una tarea dinámica de seguridad de aplicaciones en el entorno de preparación para detectarla antes de enviar ese código a las producciones, ¿verdad?
Richard Yew: Es posible que puedas, o bien remediar esos problemas, o implementar algún tipo de parche virtual antes de liberar una reducción de código para mitigarlo. Pero, una vez más, es muy importante entender que la seguridad debe ser incorporada desde el primer paso del proceso, incluso antes de comenzar a escribir el código antes de poner cualquier cosa en su IDE y empezar a pensar en hacer modelado de amenazas. Oye, ¿qué parte del diseño podría ser potencialmente susceptible a la explotación?
Implicaciones diarias para DevOps y equipos de seguridad
Lauren Bradley: Sí, y esos son muy buenos puntos, chicos. Quiero decir, desde el punto de vista del usuario, ¿qué, fuera de los costos, monetariamente, puede significar eso para un DevOps o un equipo de seguridad experimentar en su día a día si no están implementando esto desde el principio?
Y, también quiero hablar sobre cómo lo implementamos efectivamente en el ciclo de vida de DevOps.
Michael Grimshaw: Gran pregunta. Gran pregunta. Y, permítanme ser realmente contundente en mi respuesta inicial. Todos en la industria, cada CEO, CTO, CFO – todos, ingenieros, usuarios – lo que todos queremos es solo una bala mágica que podamos hacer, lo que hacemos día a día.
Y luego tenemos una bala de seguridad mágica que solo tienes que girar el interruptor y todo tu trabajo se hace seguro de repente. Eso es lo que todos quieren, pero eso no es la realidad. Es decir, ya sabes, la gente nos pregunta. Quiero preguntarles, ¿cómo está el clima en la tierra de fantasía? Oigo que es agradable. Este tipo de año es, y si te acercas a tu seguridad, tu infosec, así como tu desarrollo, ya que esto es solo un atasco. Ya sabes, “oh, voy a comprar algunas herramientas que voy a poner en marcha después de que tengamos todo desarrollado, construido e implementado, y va a seguir y hacer que todo sea seguro”, estás comprando un peso muy caro, para ser honesto contigo.
Y es por eso que, ya saben, se mencionó, se trata de personas, procesos y herramientas. Por eso es tan importante la coherencia total de este enfoque. ¿Es usted, estamos lejos años, décadas, si es que alguna vez fue posible. Para ser honesto contigo, hemos aprendido muchas lecciones de la idea de que solo diseñes algo y pongas herramientas de seguridad y ya estás listo.
Afecta a todo, desde su costo hasta la velocidad de su desarrollador y el costo allí para sus clientes. Y, un gran ejemplo de esto es mi sospecha es que casi todos los que están escuchando este podcast en algún momento de su carrera han estado en una situación en la que se implementó una nueva característica o un nuevo servicio o algo por el estilo, o incluso solo un parche y actualización. Todo parece bueno. Todo está funcionando bien. Y luego, de repente, recibe una llamada de uno de sus clientes o infosecs recibe una llamada de uno de los clientes. “Acabamos de ser empeñados”, o “Acabamos de tener un incidente de seguridad”, o algo así. Y la razón es porque, está bien, lo has implementado, pero tal vez los escaneos no habían terminado de ejecutarse, o no hiciste escaneos, o no los tenías bien ajustados, y acabas de introducir una vulnerabilidad de seguridad masiva.
Tal vez te afecte, pero lo más importante, afecta a tus clientes. DevSecOps se trata de hornear todo esto en un proceso coherente y evitarlo. Se trata de recortar costos. Absolutamente. ¿Se trata de mejorar los márgenes? Oh, de una manera grande. Pero también se trata de eliminar la responsabilidad de su empresa y la de sus clientes.
Incorporando la seguridad en DevOps – ¡Es como hornear un pastel!
Richard Yew: Absolutamente. Ya sabes, hablando de, ya sabes, hablando de hornear, ya sabes, como Mike usó un término como totalidad coherente. Así es tan cierto. Esto es muy poderoso, esta es una palabra muy poderosa para mostrar por qué es tan importante tener eso horneado en su lugar, ya sabes, como se me conoce dentro de Edgio para ser el tipo de la analogía.
Me gusta lanzar un montón de analogía alrededor y estoy, ya sabes, he escuchado esto genial. Creo que las analogías servirían como una base sólida para presionar por las culturas correctas dentro de cualquier organización como todos sabemos, como personas de seguridad, una gran parte de nuestro trabajo es el evangelismo. No se trata solo de implementar las tecnologías correctas y crear un proceso, sino también de hacer mucho marketing interno.
Decirle a la gente que es importante la seguridad para el negocio, ¿verdad? Porque, ya sabes, como líderes de seguridad, no es solo como, es como si la gente a menudo piensa en la seguridad, como agregar capas adicionales de proceso en su flujo de trabajo, pero ya sabes, la forma correcta de pensar sobre esto es que ¿cómo puede la seguridad acelerar el negocio?
¿Cómo puede la seguridad realmente generar más ingresos, porque esta es una buena manera de justificar una gran parte de la seguridad, ya sabes, implementaciones de seguridad adicionales que tienes que hacer para garantizar la seguridad de la organización? Así que, una de las analogías que escuché que fue genial es que ya sabes, la seguridad no debe ser tratada como una guinda del pastel, ya sabes, cómo hornear del pastel y simplemente poner todos los guindas como último paso, ya sabes, eso es lo que generalmente hace la gente cuando no tiene un flujo de trabajo de seguridad, ICD, y simplemente implementan firewalls y, ya sabes, protección API, lo que sea en la última fase de la fase de la fase de producción. Lo que debería ser, la seguridad, es como la harina, ya sabes, debería haber sido algo desde el principio.
La seguridad es como harina para que usted hornee el pastel. Y luego, cuando la seguridad se hace bien, no se puede ver. Y todo el punto de la seguridad es cuando se hace bien, debería haber sido horneado y no es visible. No debería ser algo que genere desafíos. No debería ser algo que ralentice a la organización.
Al igual que las analogías que, ya sabes, solía ayudar a mostrar al negocio por qué esto es importante es que tener un proceso de seguridad fuerte, culturas de tecnología de seguridad, es como tener frenos fuertes. En un coche de carreras, sabes por qué todos los superdeportivos tienen frenos grandes, realmente grandes, de lujo porque les permite curar más rápido.
Les permite frenar duro. Les permite ir más rápido y girar más duro, ¿verdad? Les permite ganar la carrera. Entonces, tener frenos fuertes es tan importante como tener un motor fuerte, ¿verdad? Así es como deberíamos considerar la seguridad desde un punto de vista filosófico. Sabes, obviamente, hablamos mucho de niveles altos, ¿verdad? Así que, obviamente queremos, ya saben, algo así como profundizar en eso. La esencia de como, bien, todo esto está bien, pero ¿cómo exactamente vamos a implementar eso?
Michael Grimshaw: Sí. Creo que es una gran llamada que es frenar. El frenado potente te da control. Está la corriente o el camino que tenemos por delante está lleno de curvas, vueltas cerradas, y todo eso, y hay, seguro, hay rectas donde lo sueltas y no tocas los frenos, pero para navegar todo, eso, ese freno, creo, me encanta ambas analogías, Richard, porque esa analogía de frenado, te da control, te da un control de grano más fino cuando te enfrentas a bordillos, desafíos, y cosas inesperadas.
Richard Yew: Gran llamada. Por cierto que quiero aclarar, no se me ocurrió esa analogía que es de este tipo llamado Dr. Eric Koh. Él lo ha hecho, y dirige un gran podcast. Por lo tanto, recomiendo a todos que vayan a ver eso. Pero sí, me parece muy apropiado cuando se explica el concepto al negocio, especialmente con aquellos que son nuevos en este tipo de concepto.
Equipos problemáticos, aislados y hojas de ruta cambiantes
Lauren Bradley: Richard, usted habla de cómo usted, usted mencionó, usted sabe, si, si, si es así, DevSecOps está hecho, ¿verdad? No lo ves. Y obviamente, una de esas visibilidades flagrantes es el costo. También son equipos aislados. También se siente como que hay una desconexión entre los equipos cuando surgen estos problemas y ¿por qué no fueron atrapados antes?
¿Qué procesos, qué comunicación no estaba teniendo lugar para resolverlos rápida o eficazmente? Entonces, mi pregunta para usted es, ya sabes, en su experiencia, cuál de… usted sabe, hay, probablemente hay una falta de transparencia. Hay una toma de decisiones lenta, hay potencial para desperdiciar recursos.
Cuando tienes equipos aislados, ¿qué problemas tienden a ser los más problemáticos cuando los equipos operan en silos en tu opinión?
Richard Yew: Sí, tomaré este. Creo que una cosa que, ya sabes, yo personalmente experimenté en mi vida pasada, es que sabes, y aquí es cuando, ya sabes, cuando hablamos de productos similares, ya sabes, como un tipo de planificación, es importante es que a veces tengas un equipo de seguridad que no está integrado en la I+D, como dentro de la organización de CTO.
A veces, en muchas organizaciones, observamos silos entre los equipos de seguridad y la organización de CTO, y verás que muchos procesos se realizaron después del hecho. Así, por ejemplo, nos encontramos con una situación en la que lanzamos muchos productos, liberamos muchos códigos porque simplemente no hay un tipo fuerte de colaboración de comunicación entre los equipos de seguridad y los equipos de ingeniería.
Lo que terminaste con es que, ya sabes, una organización debe cumplir. A veces, los ejemplos específicos son que hay equipos que vienen a hacer los escaneos como una o dos veces al año. ¿Cuál es el resultado de esos escaneos? Bueno, me dirán: “Oye Richard, tenemos que reducir la velocidad el próximo trimestre porque acabamos de encontrar cien diferentes bugs de seguridad grandes y pequeños, ya sabes, tal vez como 20, como de los 20 primeros son severidad uno y dos y superiores, mientras que el resto, ya sabes, se trata de, tienes que centrarte en arreglar esas cosas”.
Y hay un SLA dentro de la organización para que usted arregle, ya sabes, lo que terminó sucediendo es que al hacer eso, esencialmente solo tomaron mi hoja de ruta y simplemente los lanzaron al siguiente trimestre. Así que, al no girar a la izquierda, al no hornear realmente este proceso en su lugar, al hacer estas cosas solo en el lado derecho, esencialmente estamos impulsando nuestra hoja de ruta, que es, ya sabes, entregables generadores de ingresos, potencialmente que podrían ayudar a expandir nuestro negocio. Vamos a tener potencialmente moverlo bien para que podamos, ya saben, gastar un cuarto está tratando, después del hecho, de mitigar esos problemas.
Es por eso que digo, bueno, es tremendamente caro para la organización y para el negocio imaginar tener, tener que cambiar los elementos de la hoja de ruta en un cuarto. Entonces, todos sus calendarios de lanzamiento de sus nuevos productos, características y funcionalidades tienen que ser cambiados, ¿verdad? Porque no cambiaste a la izquierda en tu práctica.
Y algunas de esas cosas podrían haberse mejorado con mejores colaboraciones, especialmente entre los equipos de seguridad de aplicaciones dentro de una organización y sin embargo y el equipo de desarrollo. Es por eso que vemos que muchas organizaciones están empezando a tener este nuevo concepto. Ustedes saben, ustedes han escuchado acerca de HR BP, ya saben, socios de negocios de RRHH que están integrados dentro de diferentes unidades de negocio.
Ahora hay un concepto de seguridad de aplicaciones BP. Entonces, vas a empezar a escuchar estos términos como APP SEC BP que, que podría convertirse en práctica donde tienes gente trabajando. Casi como un gerente semi-integrado del equipo de ingeniería para asegurarse de que proporcionan la orientación, las herramientas y los procesos correctos en cada paso del flujo de trabajo de desarrollo, por ejemplo, ya sabes, la implementación de análisis de composición de software, la implementación de Secure ID, la implementación de todas las tareas de caja en blanco y negro, ya sabes, durante el proceso para asegurarnos de que, ya sabes, somos capaces de capturar algunos de esos problemas antes, ya sabes, justo al principio del ciclo de vida de desarrollo.
Michael Grimshaw: Y me encanta todo. Gran pregunta, Lauren. Y me encanta todo lo que acabas de decir, Richard. Porque hay un costo asociado con eso. Sabes, si la gente, si alguien está en un producto donde oye, espera, ya sabes, si giro a la izquierda, no tengo que cambiar mi hoja de ruta a la derecha.
Eso es música para sus oídos. Pero tal vez para CFOs, o incluso operaciones, u otras áreas del negocio, usted podría estar diciendo, bueno, ¿cuál es el impacto de eso? El impacto es enorme. Acabas de arrodillar tu departamento de ventas. Has impactado a tus clientes porque tienes, especialmente cuando se trata de seguridad, muchos clientes. Sé que en el lado de la plataforma, cuando hablo con mis proveedores, quiero saber cuál es la hoja de ruta porque, bien, tal vez tengo que ir a mis auditores y necesito obtener control compensatorio hasta que publiques algo en tu hoja de ruta. Bueno, si me dijiste, bien, lo que esperaba que me entregaran en un cuarto va a ser tres cuartos. Voy a empezar a mirar a otros vendedores. ¿Por qué? Porque tengo obligaciones con mis auditores que tengo que cumplir.
Y también me encanta, Richard, que trajo auditores y realmente el proceso de cumplimiento. Ese es otro ejemplo aquí a tu punto, Lauren, sobre donde la siloización puede hacer estallar radicalmente las cosas.
Si estás en medio de un PCI, SOC, ISO, FedRAMP, cualquiera de estos marcos de cumplimiento, y realmente no te has integrado, todavía estás operando una mentalidad de asilo, probablemente vas a tener a alguien que está en cumplimiento o sec de información hablando con tus auditores, van a tener que traducir eso a través de una capa o dos al lado de la ingeniería que espero va a implementar todo lo previsto, y entonces eso es solo para implementarlo. Y luego toda la evidencia y el escaneo y todo lo que necesita para proporcionar a sus demás, buena suerte.
Si eso realmente se traduce, todos hemos jugado el viejo juego de rumores de la escuela primaria es un tipo de función similar donde si tienes equipos integrados que están trabajando con los auditores que inmediatamente saben cómo traducir esto a la tecnología específica y tienes escaneado y puedes cambiarlo inmediatamente y ponerlo en tu conjunto de reglas y escanear y validar en eso tanto en tiempo real, como cuando te reúnes con los auditores. Tienes toda tu evidencia ahí mismo. Eso es un cambio radical de juego. Le permite entregar las cosas más rápido a sus clientes en lugar de como dijo Richard, seguir cambiando su hoja de ruta en este momento.
Lauren Bradley: Sí. Así que, para ser más tangible en eso, quiero decir, ¿cómo pueden los líderes de CISOs y AppSec cuantificar sus métricas para entender las implicaciones de costos o incluso solo el éxito general?
Richard Yew: Qué, ya sabes, es gracioso porque hablamos mucho sobre el por qué, ya sabes qué, pero vamos, vamos a profundizar en el cómo, porque sé eso, eso es lo que mucha de nuestra audiencia para. No estamos aquí para darte declaraciones esponjosas y de alto nivel. Lo que estamos aquí para ofrecer es un poco de valor para cuando se trata exactamente de cómo implementarlo.
Así que tal vez podamos sacar el gráfico de DevSecOps que tenemos, y luego podemos simplemente ir a través de cómo podemos optimizar los pasos. Está bien. Así que como pueden ver las pruebas de seguridad tradicionales, saben, algo así como las corridas de una manera lineal, ¿verdad? Es, es como cuando estamos hablando de cascada, como tu plan, tienes, belleza, una prueba, ¿verdad?
Se realizaron muchas pruebas de seguridad durante la fase de monitor del operador. Entonces, está en el lado derecho. Entonces, ahora que el nuevo concepto es, si pasamos a las próximas fotos, ¿verdad? Es que puedes encontrar 100 variedades diferentes de esta tabla. Como, cuando solo Google DevSecOps hoy, como Mike dijo antes, este concepto ha existido, ya sabes, durante 7 años, ¿verdad? Sabes que algunas organizaciones podrían no llamarlo ese ciclo. Algunas organizaciones lo llaman AppSec, ¿verdad? Así que ciertas organizaciones los llamarán una tubería de seguridad. Por lo tanto, esta es una representación aproximada de lo que representa un oleoducto de seguridad. ¿Verdad? Así que, desde el principio, tienes en la fase de planificación, ¿verdad?
Usted tiene el análisis de amenazas de modelado de amenazas. Usted trata de asegurarse de que usted horneó en todo este modelado mientras está diseñando soluciones. Así que, mientras codificas, mientras vas a una segunda fase, tu fase de codificación, ¿verdad? Quieres asegurarte de tener el enganchado. Usted quiere asegurarse de que usted tiene un IDE seguro, que siempre está realmente en tiempo real como los desarrolladores que escriben el código realmente capturaron algunos de los problemas en tiempo real. Obviamente, eso no es una bala de plata, ¿verdad? Pero es una capa adicional y estamos hablando de capas adicionales en los ciclos de defensa en profundidad. Ahora, a medida que avanzamos más y más en el proceso, ¿verdad? Una vez que te comprometiste con el código, ¿verdad? ¿Quieres asegurarte de que tienes un proceso – quién puede proporcionar, eh, un escaneo estático de todo tu código para asegurarte de que comprueban la dependencia automática, la cadena de suministro, la vulnerabilidad, etc., junto con el análisis de compensación de software para crear una vista de software de los materiales que te muestren qué tipo de versión de software estás usando? ¿Qué edad tienen?
Porque, ya sabes, no te bromeo, acabo de leer una estadística hace una semana o dos – el 25% de las descargas de Apache Log4j todavía está fuera de la versión anterior que todavía contiene una vulnerabilidad. Me desconcierta que todavía sea una estadística, ya sabes, ahora que llevamos casi dos años. No sé, ¿fueron dos años o tres años desde que se anunció la primera vulnerabilidad de días cero de Apache Log4j a principios de diciembre? ¿Fue 2021? Por lo tanto, realmente es algo que necesitamos centrarnos en hacerlo mejor y tener este tipo de conversación / análisis de software en su lugar para asegurarnos de que usted sabe exactamente qué versión de software está ejecutando.
Es importante. Entonces, nos movemos hacia las pruebas, ¿verdad? Quieres asegurarte de que tienes pruebas internas, que tienes tus pruebas dinámicas, ya sabes, implementadas para asegurarte de eso. Podemos probar la aplicación que se está ejecutando y ver si hay algún tipo de vulnerabilidad que pueda ser explotada.
Usted sabe que esto generalmente se hace a través de fuzzing. Ahora, ¿qué no se muestra aquí en los ciclos de DevSecOps tradicionales? Porque todo esto parece una práctica bastante estándar de la industria, ¿verdad? A medida que nos movemos a la derecha todo el camino para desplegar, monitorear, respuesta. Históricamente, pondrías el firewall de aplicaciones web, el gestor de bots, los valores de API, todas sus soluciones de protección de API de aplicaciones web en la fase de respuesta y monitoreo, ¿verdad? Esto es cuando monitorea su tráfico de producción, se asegura de que no hay exploit hacia.
Pero lo que es algo a considerar es mover algunas de estas protecciones de API de aplicaciones web que tiene en su lugar. Cambiarlos también. Ponerlos en este caso, en la imagen, es un paso adelante. Póngalos en la fase de prueba mientras está haciendo su prueba dinámica de seguridad de aplicaciones, ¿verdad? ¿Por qué no los prueba a través de su mecanismo de seguridad de producción? Así que, ya saben, en realidad cuánta vulnerabilidad existe entre el código, cuántas de esas vulnerabilidades se pueden mitigar, porque lo importante es que siempre estamos tratando de encontrar formas de mejorar los ciclos de vida de este ciclo de aplicaciones actual haciendo que un desarrollo funcione más rápido. Una práctica general cuando encuentra una vulnerabilidad de seguridad durante esa prueba es que básicamente detiene el tren. Regresas, ¿verdad? Arreglas el código, los vuelves a liberar. Vas a través de los ocho pasos de nuevo. Pero, ¿y si te dijera que tal vez hay una manera de decir, “oye, no detengamos el tren?”
Mantengamos el tren en marcha. Vamos a liberar eso al tener una especie de prueba adicional con soluciones de seguridad delante del paso cuatro que le permitirá saber con anticipación qué parchear virtualmente en la producción para que no tenga que detener su tren. Mantienes tu tren en marcha. Mantienes tu velocidad.
Usted libera el código con el parche virtual en su lugar para mitigar la vulnerabilidad, y luego los arregla en el próximo ciclo, con suerte, lo que con suerte sucederá muy rápidamente. Esta es también una de esas formas, las formas innovadoras que queremos, ya sabes, educar y trabajar con nuestros clientes para tratar de mejorar el flujo de trabajo de seguridad CICD existente.
Michael Grimshaw: Me encanta eso, Richard. Me encanta que llames al hecho de tirar, tirar de esto en cambio a la izquierda. Así que solo a tu punto es si tu plan de juego es, oh, vamos a poner esto en producción y luego nos preocuparemos por ello. Va a tener problemas y tendrá algo que puede mitigar que puede cubrir su parte trasera, tanto a través de su desarrollo e implementación y proceso de operaciones. Me encanta lo que llamaste ahí fuera. Y una analogía, y una analogía similar, yo diría, es como el Mono del Caos. Aquí está la cosa. Si tienes a Chaos Monkey trabajando en producción, y la única vez que estás lidiando con Chaos Monkey es cuando está en producción, vas a tener una horrible experiencia operativa y de desarrollo.
Tienes que planificar, diseñar e ingeniar para eso mucho antes de que llegue a la producción. De lo contrario, vas a estar en la miseria.
Cuantificar métricas para entender las implicaciones de costos y el éxito
Richard Yew: Sí, y Lauren, me gusta responder preguntas anteriores, ¿cómo medimos el éxito ahora que solo miramos todo el ciclo de vida de DevSecOps y cómo podemos optimizarlo? ¿Cuál es la mejor práctica, verdad?
Muy rápidamente. Así que tenemos que rastrear el éxito. Así que obviamente necesitas poder cuantificar el éxito. Correcto. Entonces, ya sabes, hay algunas de las métricas que podrían ayudar si eres un líder de seguridad y estás tratando de medir el éxito de los programas de seguridad de aplicaciones, una de las cosas que puedes ver, también es qué, cuánta cobertura de la aplicación tienes, ¿verdad?
Así, por ejemplo, ¿tiene más del 90/95 por ciento de todas sus aplicaciones o aplicaciones de Internet en todas sus organizaciones cubiertas bajo el mismo proceso? ¿Tiene el mismo proceso estandarizado cubriendo? Correcto. Que todo, incluyendo composición de software, análisis, SAS, prueba, prueba, prueba, ya sabes, como aplicaciones web, protecciones de API.
¿Tiene esas cosas en su lugar para seguir rastreando la cobertura? ¿Con qué frecuencia sueltas y con qué frecuencia tienes que retroceder? En qué fase debido a la vulnerabilidad de seguridad que detecta y con qué frecuencia tiene que retroceder en la fase de producción frente a la frecuencia con la que tiene que retroceder durante la fase de confirmación de código, ya sabes, donde está haciendo análisis estáticos porque obviamente se retrocede en las producciones.
Va a ser mucho más caro que arreglar el código después de un poco de análisis de código estático. Correcto. Las otras dos estadísticas allí, definitivamente quieres medir como, como Lauren aludió antes. El tiempo medio de la industria para detectar lo que llamamos MTTD es de 200 días. Así que, creo que con esto con el proceso correcto con el proceso de desplazamiento derecho a la izquierda, se puede reducir drásticamente mientras tanto para detectar, a mucho más corto. Por lo tanto, intente comenzar a juntar métricas para detectar cuánto tiempo toma desde una revelación de vulnerabilidad hasta que usted detecte aquellas que se construyen dentro de sus organizaciones.
Y también implementar mientras tanto a la respuesta, ¿verdad? MTTR Mientras tanto para resolver mientras tanto a resoluciones, ¿verdad? El promedio de la industria es de 70 días, por lo que son 70 días después de que se encuentre la vulnerabilidad, ¿verdad? Explotado todavía toma una organización promedio de 70 días para resolver eso. Pero con este seguimiento de inicio, ¿qué tan rápido puede resolver? Tan pronto como encuentres una versión vulnerable de los registros para J usando tu código en el análisis de composición de tu software, ¿con qué rapidez puedes parchearlos virtualmente con un firewall, o con qué rapidez puedes ir y actualizar tus bibliotecas para usar un software diferente? Así que, midiendo eso en una organización muy madura, he hablado con algunas organizaciones que realmente tienen lo que estamos hablando de cuatro horas de tiempo medio para resolver el tiempo para el evento log4j.
Eso es extremadamente impresionante. Y eso habla de la madurez de sus procesos DevSecOps. Así que he visto todo tipo. Y he visto organizaciones de clientes que tienen como semanas o incluso meses de entretanto para resolver problemas críticos como log4j. Por lo tanto, es muy importante tener en cuenta esas métricas mientras intentas mejorar el proceso en su conjunto.
Michael Grimshaw: Y hay algunos otros KPIs que quiero presentar aquí es que, como en el lado de la plataforma, cuando se trata de infraestructura o en muchos casos, cualquier cosa de ingeniería, el costo siempre ha sido un elemento importante aquí. Pero en los últimos años, con el aumento de las tasas de interés, ya saben, la espiga está tan lejos como el dinero de los VC y mucho de eso realmente se está agotando, pero el nombre del juego y el entorno de las tasas de interés en aumento es una paliza muy rentable.
Y hay un aspecto aquí. Me encanta esta técnica. Claramente, ya sabes, director de ingeniería de plataformas. Me encanta el lado técnico, pero especialmente en los últimos años, una gran parte de si estás trabajando en plataforma, como dije, la infraestructura y cosas por el estilo, el aspecto financiero y en aclarar y proporcionar retroalimentación a tu CFO, así como a tu CTO se ha convertido en imperativo.
Y así el KPI está alrededor de un costo y los ingresos son, este es otro, este es un aspecto muy importante aquí también. Y, y solo quiero destacar algunas de las cosas como esta, por ejemplo, en el lado de los ingresos. Si estás sentado con una discusión en línea roja, si tienes un cliente que está buscando comprar tu compra, pero tu producto, vas a pasar por una línea roja de seguridad porque la seguridad está en la mente de todos y tus clientes van a querer asegurarse de que están protegidos.
Van a querer minimizar su riesgo aquí. Y si vienes a él con la mentalidad de la vieja escuela. Ah, sí, desarrollamos cosas y luego, dejamos, nos aseguramos de que nuestra infosec las escanee y todo eso. He estado en un montón de discusiones de línea roja y discusiones de contratos, y eso simplemente ya no vuela.
El nivel de los cuestionarios y cuestionarios del departamento de riesgos de su cliente y el departamento legal ha pasado a otro nivel de detalle en los últimos cinco años, y mucho menos 10 años. Y, poder tener una solución totalmente integrada de desplazamiento a la izquierda para tener aplicaciones web y protección de API, todo esto. Cuando usted está hablando con los abogados de otras personas, esto mueve la aguja de una manera grande. ¿Qué significa eso? Significa que le permite cerrar ofertas más rápido. Y una de las cosas, si no estás practicando el cambio a la izquierda o simplemente estás pensando que es infosec como complemento, te animo a que regreses y veas tus ratios de cierre y dónde se rompieron y mires específicamente las discusiones de la línea roja de seguridad porque estos tipos de productos con demasiada frecuencia se ven como un centro de costos. No lo son, pueden desbloquear ingresos y pueden ahorrarte una gran cantidad de dinero.
Anteriormente en el podcast, cubrimos una gran parte de los ahorros de costos en cuanto a costos internos, pero hay ingresos en las implicaciones beta aquí que creo que es importante destacar porque ahí es donde muchos ojos están en este mundo de tasas de interés en aumento.
Terminación
Richard Yew: Ese es un punto excelente. Me alegro de que hayamos cambiado un poco de sombreros, ya sabes, como ponerme mis sombreros SDLC y te pongas el tuyo, tu sombrero de negocios. Esto es genial. Espero que todas estas cosas que compartimos proporcionen un poco de valor a nuestra audiencia.
Lauren Bradley: Muchas gracias a los dos. Creo que es una gran nota para terminar. Hemos cubierto la importancia de cambiar a la izquierda y cómo integrar eficazmente las aplicaciones web y la protección de API en el ciclo de vida de DevOps. Y, por supuesto, cómo medir eficazmente el éxito. ¿Hay menos falsos positivos? ¿Cuál es su resolución de tiempo medio? ¿Qué tan rápido estás enviando software? ¿Y estás ganando más ingresos?
Todas estas métricas son vitales para el éxito de una empresa. Así que les agradezco a ustedes, Michael y Richard, por acompañarme hoy. Realmente ha sido un placer y gracias a nuestra audiencia también por unirse a nosotros en Beyond the Edge. Te veremos en el próximo episodio.
