Introducción al podcast de Edgio Beyond the Edge Episodio 4: DevSecOps: Cambia a la izquierda para evitar cambiar la hoja de ruta de tu producto a la derecha, organizado por Lauren Bradley, Gerente de Campaña Global de Edgio.
Lauren Bradley: Oye, y bienvenidos a Beyond the Edge, donde nos adentramos en los entresijos de los negocios digitales modernos. Soy Lauren Bradley, su copiloto para este episodio, y hoy, vamos a explorar el tema del cambio a la izquierda, específicamente cómo la cultura y la tecnología cambian a medida que la protección de aplicaciones web y API se convierten en una parte nativa e inherente de su ciclo de vida de DevOps.
Empecemos con una estadística impactante del Instituto Ponemon. Hoy en día, la mayoría de las empresas tardan más de 200 días en detectar incluso 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 errores fijos encontrados durante la etapa de prueba puede ser 15 veces más que los encontrados durante el diseño.
Por lo tanto, para decirlo simplemente, 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, hacer retroceder las hojas de ruta de los productos. Entonces, ¿cómo puede cambiar a la izquierda de manera efectiva y evitar desperdiciar recursos valiosos y detener su progreso?
Junto a nosotros, tenemos a 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 encima.
Michael Grimshaw: Gracias, Lauren. Genial estar aquí. Gracias.
Lauren BRADLEY: ¿Pueden decirme un poco sobre ustedes mismos y sus pensamientos iniciales sobre este tema? Mike, empezaremos contigo.
Michael Grimshaw: Absolutamente. En primer lugar, permítanme comenzar dando las gracias, gracias, Lauren, por tener tanto interés. En este tema tan importante y, y estás cavando y aumentando y las conversaciones que hemos tenido y estamos teniendo en torno a 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 necesita ser compartido a lo largo y ancho 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 la plataforma o que están súper familiarizados con ella en términos de industria, realmente está pensando en términos de 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 bastante porque mueve la aguja de una manera tan grande, en cuanto a seguridad, en cuanto a rentabilidad, y muchas de las áreas que son tan importantes para nuestra industria.
Y puedo seguir alrededor de DevSecOps, pero permítanme 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 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 realmente que estamos entregando valor a nuestros clientes. Y, ya saben, todo lo que obviamente incluiría como la optimización de nuestra práctica de desarrollo, nuestra seguridad, la práctica de CI CD. para asegurarnos de que realmente somos capaces de ofrecer productos seguros.
Correcto. Eso realmente proporciona valor a nuestros clientes, los entrega a tiempo, en presupuestos, y asegura que brindamos una gran experiencia a nuestros clientes. Entonces, mi objetivo en esto es mirar realmente a todo DevSecOps, ya saben, desde una perspectiva de la gente: El proceso en lugar de la tecnología y cómo podemos implementar realmente las mejores prácticas, para la industria.
¿Qué es DevSecOps?
Michael Grimshaw: Hasta tu punto, Richard, déjame que me robe la pelota allí si no te importa.
Y solo creo que vamos a estandarizar lo que queremos decir con DevSecOps y cambiar el turno izquierdo, ¿verdad? Estaba Gartner, aquí están las cosas para algunas personas que escuchan en este DevSecOps, y los términos cambian a la izquierda, cambian a la derecha, etc. podría sonar relativamente nuevo. 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 cocinando en la industria durante bastante tiempo. Y de hecho, Gartner tenía un informe de 2017 sobre el ciclo de vida de DevSecOps. Fue realmente una extensión de los DevOps, la tendencia de DevOps en la industria, solo extendiéndose para incluir la seguridad en la infosec en el bucle de retroalimentación y su ciclo de vida de desarrollo de software.
Y así, como dije, Gartner estaba 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 tan pronto como sea posible, quiero decir, desde el inicio del diseño, construir el, ya sabes, todo el proceso hasta donde sus desarrolladores en el barco de la izquierda está en el lado del desarrollo, disculpe, el cambio a la derecha está más en el lado de la observabilidad de las operaciones. Vamos a centrarnos en el lado izquierdo aquí hoy, pero básicamente está horneando en sus pruebas de escaneos y su validación, tan temprano como a la izquierda. Y tan pronto como sea posible en el ciclo de vida del desarrollo de su SDLC. Entonces, por ejemplo, una de las cosas de las que habla, y de nuevo, esto se remonta a más de siete años, es cosas como tener seguridad, escanear y escanear sus bibliotecas de terceros de código abierto, repositorios, base de código, 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 propios IDE que utilizan sus desarrolladores. Es solo un ejemplo, y hay muchos de ellos.
Para que mientras escriben su código, obtengan retroalimentación inmediata. Oh, acabo de dejar la puerta abierta a, ya sabes, relleno de credenciales o inyección de secuela, y obtienen como un error de sintaxis, obtienen un error de seguridad justo allí está escribiendo el código. Por lo tanto, pueden arreglar eso de inmediato, para que no tengan un cliente quejándose de que el cliente o el usuario final se empeñen, ya sabes, un mes después, no, se maneja allí mismo.
Más barato, más rápido, más fácil al inicio. Richard, usted iba a decir algo.
¿Por qué el cambio es tan importante cuando se trata de costos?
Richard Yew: Oh, sí. Sí. Creo que el costo es realmente muy importante de hablar, ya sabes, bueno, todo el mundo sabe muchos costos operativos, ya sabes, 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 sobre el por qué, ya sabes, estoy seguro de que vamos a entrar en el “cómo” más tarde, pero queremos llegar a casa sobre la razón por la que esto es tan importante porque, ya sabes, tenemos datos.
Sí. Eso, según nuestra investigación, muestra que usted sabe, si está corrigiendo una vulnerabilidad de seguridad que se encontró después de liberar su código y producciones cuesta 15 veces más de lo que sabe cuando se encuentra en una fase de diseño cuando está haciendo el montaje de amenazas. Obviamente, no estamos diciendo que ya sabes, la fase inicial del esfuerzo de desarrollo captaría por completo todas las vulnerabilidades de seguridad.
Es por eso que necesitamos implementar la defensa en profundidad. Pero es muy importante que usted sepa, al mirar las ocho fases, usted sabe, en general, de los ciclos de la deuda, ciclos de vida de, usted sabe, plan, código, construya, pruebe, todo el camino para que le guste monitorear y operar. Correcto. Los miras cuanto más a la derecha vayas, ya sabes, como cuando encuentras una vulnerabilidad de seguridad, más costoso será, 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 sucede después de que ya liberaste un montón de códigos a las producciones versus digamos, ya sabes, como hacer una tarea dinámica de seguridad de aplicaciones en el entorno de puesta en escena para detectarlo antes de enviar ese código a las producciones, ¿verdad?
Richard Yew: Es posible que pueda remediar esos problemas o implementar algún tipo de parches virtuales con anticipación antes de lanzar una reducción de código para mitigar eso. Pero, una vez más, es muy importante entender que la seguridad debe incorporarse desde el primer paso del proceso, incluso antes de comenzar a escribir el código antes de poner algo en su IDE y empezar a pensar en hacer modelado de amenazas. Hey, ¿qué parte del diseño podría ser potencialmente susceptible a la explotación?
Implicaciones cotidianas para DevOps y equipos de seguridad
Lauren BRADLEY: Sí, y esos son muy buenos puntos, ustedes. 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 este derecho desde el principio?
Y, también quiero hablar sobre cómo lo implementamos de manera efectiva en el ciclo de vida de DevOps.
Michael Grimshaw: Gran pregunta. Gran pregunta. Y, permítanme ser muy contundente en mi respuesta inicial. Son todos en la industria, cada CEO, CTO, CFO – todos, ingenieros, usuarios: lo que todos queremos es solo una bala mágica que podemos hacer, lo que hacemos día a día.
Y luego tenemos una bala mágica de seguridad que solo dan la vuelta al interruptor y todo su trabajo se hace de repente seguro. Eso es lo que todos quieren, pero eso no es realidad. Es decir, ya sabes, la gente nos pregunta. Quiero preguntarles, ¿cómo es el clima en tierra de fantasía? Oigo que es agradable. Este tipo de año es, y si te acercas a tu seguridad, a tu infosec, así como a tu desarrollo, ya que esto es solo un obstáculo. Sabes, “oh, voy a comprar algunas herramientas que voy a utilizar después de que tengamos todo desarrollado, construido y desplegado, y va a seguir y hacer todo seguro”, estás comprando un peso en papel muy caro, para ser honesto con usted.
Y es por eso que, ya sabes, se mencionó, se trata de personas, procesos, y herramientas. Es por ello que la totalidad coherente de este enfoque es tan importante. ¿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ñas algo y pones herramientas de seguridad y eres bueno.
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 así, 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, de acuerdo, lo has implementado, pero tal vez los escaneos no habían terminado de ejecutarse, o no los has hecho, o no los has ajustado correctamente, 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 evitar eso. Se trata de reducir costos. Absolutamente. ¿Se trata de mejorar los márgenes? Oh, en una gran manera. Pero también se trata de eliminar la responsabilidad de su empresa y la de sus clientes.
Incorporar seguridad en DevOps – ¡es como hornear un pastel!
Richard Yew: Absolutamente. Ya sabes, hablando de, ya sabes, hablando de hornearlo, ya sabes, como Mike usó un término de totalidad coherente. Así que esto 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 oído esto genial. Las analogías creo que servirían como una base sólida para impulsar 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 adecuadas y crear un proceso, sino también de hacer mucho marketing interno.
Decir que las personas son importantes de seguridad para el negocio, ¿verdad? Porque, como líderes de seguridad, no es solo como, es como si la gente a menudo piense en la seguridad, como agregar capas adicionales de proceso a su flujo de trabajo, pero usted sabe, la manera correcta de pensar en esto es que ¿cómo puede la seguridad acelerar el negocio?
¿Cómo puede la seguridad generar más ingresos, porque esta es una buena manera de justificar una gran cantidad de la seguridad, ya sabes, implementaciones de seguridad adicionales que tienes que hacer para garantizar la seguridad de la organización? Entonces, una de las analogías que escuché que fue genial es que sabes, la seguridad no debe ser tratada como una guinda en el pastel, ya sabes, cómo hornear el pastel y simplemente poner todas las guindas como un último paso, ya sabes, eso suele ser lo que hacen las personas cuando no tienen un flujo de trabajo de seguridad, ICD, y simplemente implementan firewalls y, ya sabes, protección de API, lo que sea en la última fase de la fase de producción. Lo que debe ser, la seguridad, es como harina, ya sabes, debería haber sido algo desde el principio.
La seguridad es como harina para que hornees 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 debe ser algo que cree desafíos. No debería ser algo que ralentice 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é cada supercoche tiene frenos grandes, realmente grandes, de lujo porque les permite hacer curvas más rápido.
Les permite frenar con fuerza. Les permite ir más rápido y girar más duro, ¿verdad? Les permite ganar la carrera. Por lo tanto, 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 altos niveles, ¿verdad? Así que, obviamente, queremos, ya saben, algo así como profundizar en eso. La esencia de algo así, está bien, así que todo esto está bien, pero ¿cómo exactamente vamos a implementar eso?
Michael Grimshaw: Sí. Creo que esa es una gran llamada es frenar. El potente frenado te da control. Ahí está la corriente o el camino que tenemos por delante está lleno de curvas, giros de horquilla, y todo eso, y hay, claro, hay rectas donde lo sueltas y no tocas los frenos, sino para navegar todo, eso, ese freno, creo, amor, me encantan las dos 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, 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 ir a ver eso. Pero sí, me parece tan apropiado a la hora de explicar el concepto al negocio, especialmente con aquellos que son nuevos en este tipo de concepto.
Equipos problemáticos, aislados y cambios de hoja de ruta
Lauren BRADLEY: Richard, usted habla de cómo usted, usted mencionó, usted sabe, si, si, DevSecOps está hecho, ¿verdad? No lo ves. Y obviamente, una de esas visibilidades evidentes es el costo. También son equipos aislados. También se siente como que hay una desconexión entre los equipos cuando hay estos problemas que surgen y ¿por qué no fueron atrapados antes?
¿Qué procesos, qué comunicación no se estaba llevando a cabo para resolverlos de forma rápida o efectiva? Entonces, mi pregunta para usted es, ya sabes, en su experiencia, cuál de… Ya sabes, 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, sabes, experimenté personalmente en mi vida pasada, cierto, es que sabes, y aquí es cuando, ya saben, cuando hablamos de productos similares, ya saben, como un tipo de planificación, es importante que a veces tenga un equipo de seguridad que no esté integrado en la I+D, como en la organización de CTO.
A veces en muchas organizaciones, observamos silos entre los equipos de seguridad y la organización de CTO, y descubrirá que muchos procesos se realizaron después del hecho. Así, por ejemplo, nos encontramos con una situación en la que lanzamos muchos productos, lanzamos 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 como cien errores de seguridad diferentes, grandes y pequeños, ya sabes, como tal vez, como 20, como de los 20 primeros son severidad uno y dos y más, mientras que el resto, ya sabes, se trata de, tienes que concentrarte en arreglar esas cosas”.
Y hay un SLA dentro de la organización para que arreglen, ya saben, lo que terminó sucediendo es que al hacer eso, esencialmente simplemente tomaron mi hoja de ruta y simplemente los lanzaron al próximo trimestre. Por lo tanto, al no desplazarnos a la izquierda, al no preparar realmente este proceso, simplemente haciendo 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 realmente, ya saben, gastar una cuarta parte es tratar, 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 por un cuarto. Por lo tanto, todos sus programas 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 aún así y el equipo de desarrollo. Es por eso que vemos que muchas organizaciones están empezando a tener este nuevo concepto. Ya saben, ustedes escucharon sobre HR BP, ya saben, socios de negocios de recursos humanos que están integrados dentro de diferentes unidades de negocio.
Ahora existe un concepto de Seguridad de Aplicaciones BP. Entonces, vas a empezar a escuchar estos términos como APP SEC BP que, eso podría convertirse en práctica donde tienes gente trabajando. Casi como un gerente semi-embebido 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 desde, digamos, ya sabes, la implementación del análisis de composición de software, la implementación de ID seguro, la implementación de todas las tareas de caja en blanco y negro, ya sabes, durante el proceso para garantizar que, ya sabes, podamos capturar algunos de esos problemas antes, ya sabes, justo al principio del ciclo de vida del 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. Ya sabes, si la gente, si alguien está en un producto donde oyen, esperan, ya saben, si cambio 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 CFO, o incluso operaciones, u otras áreas del negocio, podría estar diciendo, bueno, ¿cuál es el impacto de eso? El impacto es enorme. Usted acaba de arrodillar su 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, bueno, tal vez tengo que ir a mis auditores y necesito obtener control compensatorio hasta que liberes algo en tu hoja de ruta. Bueno, si usted me acaba de decir, está bien, lo que esperaba que se entregara en un cuarto va a ser tres cuartas partes. 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 hayas criado auditores y realmente el proceso de cumplimiento. Ese es otro ejemplo aquí hasta tu punto, Lauren, sobre dónde la siloización puede hacer volar radicalmente las cosas.
Si usted está en medio de un PCI, SOC, ISO, FedRAMP, cualquiera de estos diversos marcos de cumplimiento, y no se ha integrado realmente, todavía está operando una mentalidad de asilo, probablemente va a tener a alguien que está en cumplimiento o información sec hablando con sus auditores, van a tener que traducir eso a través de una capa o dos al lado de la ingeniería que, con suerte, va a implementar todo lo que se pretende, y entonces eso es solo para ponerlo en práctica. Y luego toda la evidencia y el escaneo y todo lo que necesita para proporcionar de vuelta a sus demás, buena suerte.
Si eso realmente se traduce a través, todos hemos jugado el, ya sabes, ese viejo juego de rumores de la escuela primaria es un tipo de función similar en la que si tienes equipos integrados que están trabajando con los auditores que inmediatamente saben cómo traducir esto en la tecnología específica y tienes escaneo y puedes cambiarlo inmediatamente y ponerlo en su conjunto de reglas y escanee y valide en ese tiempo real, así como cuando se reúna con los auditores. Tienes todas tus evidencias juntas ahí mismo. Eso es un cambio radical del juego. Le permite entregar las cosas más rápido a sus clientes en lugar de como Richard Said, siga cambiando su hoja de ruta ahora mismo.
Lauren BRADLEY: Sí. Entonces, para ser más tangibles en eso, quiero decir, ¿cómo pueden los CISOs y los líderes de AppSec cuantificar sus métricas para entender las implicaciones de costos o incluso simplemente el éxito general?
Richard Yew: ¿Qué, sabes, es gracioso porque hablamos mucho sobre el por qué, sabes qué, pero vamos a profundizar en el cómo, porque sé eso, para eso es para muchos de nuestros públicos. No estamos aquí para darle declaraciones mullidas y de alto nivel. Esperamos que lo que estamos aquí para proporcionar sea un poco de valor para cuando se trata exactamente de cómo implementar eso.
Así que tal vez podemos hacer aparecer el gráfico DevSecOps que tenemos, y luego podemos ir a través de cómo podemos optimizar los pasos. Muy bien. Así que como pueden ver las pruebas de seguridad tradicionales, ya saben, como se ejecuta de una manera lineal, ¿verdad? Es, es como cuando estamos hablando de cascada, como su plan, usted tiene, 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 nos movemos en las próximas fotos, ¿verdad? Es que puedes encontrar 100 variedades diferentes de esta tabla. Al igual que, cuando solo Google DevSecOps hoy, como Mike dijo antes, este concepto ha existido, ya sabes, durante 7 años, ¿verdad? Usted sabe que algunas organizaciones pueden no llamarlo ese ciclo. Algunas organizaciones simplemente lo llaman AppSec, ¿verdad? Por lo tanto, ciertas organizaciones los llamarán una tubería de seguridad. Por lo tanto, esta es una representación aproximada de lo que significa un gasoducto de seguridad. ¿Verdad? Entonces, desde el principio, tienes en la fase de planificación, ¿verdad?
Tienes el análisis de amenazas de modelado. Usted intenta y se asegura de que horneó en todo este modelado mientras está diseñando soluciones. Así como, 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 tiene un IDE seguro, que está realmente en tiempo real, ya que 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 hacia abajo en el proceso, ¿verdad? Una vez que te comprometiste con el código, ¿verdad? Usted quiere asegurarse de que tiene un proceso – quién es capaz de proporcionar, uh, un análisis estático de todo su código para asegurarse 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 le muestran qué tipo de versión de software está utilizando? ¿Cuántos años tienen?
Porque, ya saben, no me engaño, 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 siga siendo una estadística, ya sabes, ahora que llevamos casi dos años. No lo sé, ¿fueron dos o tres años desde que se anunció la primera vulnerabilidad de día cero Apache Log4j a principios de diciembre? ¿Fue 2021? Entonces, es realmente algo en lo que necesitamos centrarnos en hacerlo mejor y tener este tipo de conversación / análisis de software en su lugar para asegurarnos de que sabes exactamente qué versión de software estás ejecutando.
Es importante. Entonces, entonces nos movemos hacia las pruebas, ¿verdad? Quieres asegurarte de que tienes pruebas internas, tienes tus pruebas dinámicas, 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 se pueda explotar.
Usted sabe que esto se hace generalmente a través de fuzzing. Ahora, ¿qué no se muestra aquí en un ciclo tradicional de DevSecOps? Porque todo esto parece una práctica bastante estándar de la industria, ¿verdad? A medida que nos movemos bien todo el camino para desplegar, monitorear, responder. Históricamente, pondría firewall de aplicaciones web, gestor de bots, 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 ningún exploit hacia.
Pero lo que es algo a considerar es mover algunas de las protecciones de API de esta aplicación web que tiene en su lugar. Muévalos a la izquierda también. Póngalos en este caso, en la imagen, es un paso adelante. Póngalos en la fase de prueba mientras está haciendo su prueba de seguridad dinámica de aplicaciones, ¿verdad? ¿Por qué no las pruebas a través de su mecanismo de seguridad de producción? Entonces, 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 actuales del ciclo de aplicación haciendo que un trabajo de desarrollo sea más rápido. Una práctica general cuando encuentras una vulnerabilidad de seguridad durante esa prueba es que básicamente detienes el tren. Vuelves, ¿verdad? Usted arregla el código, usted los relanza de nuevo. Pasas por los ocho pasos otra vez. Pero, ¿qué pasaría 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 mucha anticipación qué parchear virtualmente en la producción para que no tenga que detener su tren. Usted mantiene su tren en marcha. Usted mantiene su velocidad.
Liberas el código con el parche virtual en su lugar para mitigar la vulnerabilidad, y luego los arreglas en el siguiente ciclo, con suerte, que 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 de CICD existente.
Michael Grimshaw: Me encanta eso, Richard. Me encanta que llames el hecho de tirar, tirando de esto en el cambio a la izquierda. Así que solo a tu punto es si tu plan de juego es, oh, pongamos esto en producción y entonces nos preocuparemos por ello. Va a tener problemas y tener algo que puede mitigar que puede cubrir su parte trasera, tanto a través de su desarrollo y el proceso de implementación y operaciones. Me encanta lo que llamaste ahí fuera. Y una analogía, y una analogía similar, diría yo, es como Chaos Monkey. Aquí está la cosa. Si tienes a Chaos Monkey trabajando en producción, y la única vez que estás tratando con Chaos Monkey es cuando está en producción, vas a tener una horrible experiencia operativa y de desarrollo.
Usted tiene que planificar, diseñar, y diseñar 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 mismo 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 seguir el éxito. Así que obviamente necesitas ser capaz de cuantificar el éxito. Correcto. Así que, 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 la aplicación, una de las cosas que puedes ver, también es qué, cuánta cobertura de aplicación tienes, ¿verdad?
Así que, por ejemplo, ¿tiene más del 90/95 por ciento de todas sus aplicaciones o aplicaciones orientadas a Internet en 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 aplicación web, protecciones API.
¿Tiene esas cosas en su lugar para mantener el seguimiento de 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 en comparación con qué frecuencia tiene que retroceder durante la fase de producción? fase de confirmación de código en la que está haciendo análisis estático porque obviamente retrocede 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ó anteriormente. El tiempo medio de la industria para detectar lo que llamamos un MTTD es de 200 días. Así que, creo que con esto con el proceso correcto con el proceso de desplazamiento derecho izquierdo, se puede reducir drásticamente mientras tanto para detectar, a mucho más corto. Por lo tanto, intente comenzar a poner métricas juntas para detectar cuánto tiempo le toma una divulgación de vulnerabilidad para detectar esos edificios dentro de sus organizaciones.
Y también implementar mientras tanto a la respuesta, ¿verdad? MTTR Mientras tanto para resolver a las resoluciones, ¿verdad? El promedio de la industria es de 70 días, así que son 70 días después de que se encuentra la vulnerabilidad, ¿verdad? Explotado Todavía se necesita 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 encuentre una versión vulnerable de los registros para J usando su código en el análisis de composición de su software, ¿qué tan rápido puede parcharlos virtuales con un firewall, o qué tan rápido puede ir y actualizar sus bibliotecas para usar un software diferente, ¿verdad? 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 semanas o incluso meses mientras tanto para resolver problemas críticos como log4j. Por lo tanto, es muy importante tener en cuenta esas métricas a medida que intentas mejorar el proceso en su conjunto.
Michael Grimshaw: Y hay algunos otros KPIs que quiero introducir 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, el pico está tan lejos como el dinero de VC y mucho de eso realmente se está agotando, pero el nombre del juego y el entorno de tasas de interés en aumento es un golpe 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, 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 vuelto imperativo.
Y así el KPI es alrededor de un costo y los ingresos es, esto es otro, este es un aspecto muy importante aquí también. Y, y solo quiero decir algunas de las cosas como esta es, por ejemplo, en el lado de los ingresos. Si estás sentado con una discusión de 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. Oh, sí, desarrollamos cosas y luego, dejamos, nos aseguramos de que nuestro infosec las escanee y todo eso. He estado en muchas discusiones de línea roja y discusiones de contratos, y eso simplemente ya no vuela.
El nivel de cuestionarios y cuestionarios del departamento de riesgos de sus clientes y del departamento legal ha alcanzado otro nivel de detalle en los últimos cinco años, y mucho menos en 10 años. Y, poder tener una solución de desplazamiento a la izquierda totalmente integrada 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 negocios más rápido. Y una de las cosas si no estás practicando shift left o solo estás pensando que es infosec como un complemento, les animo a que vuelvan atrás y miren sus índices de cierre y dónde se rompieron y específicamente miren las discusiones de la línea roja de seguridad porque estos tipos de problemas 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 muchos de los ahorros de costos en cuanto a costos internos, pero hay ingresos en implicaciones beta aquí que creo que es importante llamar la atención porque es ahí donde hay tantos ojos en este mundo de tasas de interés en aumento.
Para terminar
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 tu sombrero de negocio. 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 incorporar 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 un negocio. Por lo tanto, les agradezco a ambos, Michael y Richard, por unirse a mí 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.
