Tutorial DevSecOps: ¿Qué es y cómo puede mejorar la seguridad de la aplicación?


El Dr. David Brumley, profesor de la Universidad Carnegie Mellon y CEO de ForAllSecure, explica qué es DevSecOps y cómo las empresas pueden usarlo para mejorar la seguridad.

Bill Detwiler de TechRepublic habló con el profesor de la Universidad Carnegie Mellon y CEO de ForAllSecure Dr. David Brumley sobre DevSecOps y las formas en que las empresas pueden usarlo. La siguiente es una transcripción editada de la entrevista.

Bill Detwiler: Si ha estado en TI por algún tiempo, probablemente haya escuchado el término DevOps, básicamente una combinación de desarrollo de software y operaciones de TI. ¿Qué pasa con DevSecOps? ¿Qué es y qué aporta a la fiesta? Bueno, por suerte estoy aquí con alguien que puede responder esas preguntas.

El Dr. David Brumley es profesor en la Universidad Carnegie Mellon y CEO de ForAllSecure. También ha estado en el negocio de la seguridad de aplicaciones durante más de 20 años, tanto en el ámbito empresarial como en el de investigación, y explicará qué es DevSecOps y cómo puede ayudar a las empresas a mejorar sus procedimientos de seguridad. David, gracias por venir.

Dr. David Brumley: Gracias por invitarme, Bill.

¿Qué es DevSecOps y en qué se diferencia de DevOps?

Bill Detwiler: Así que vamos a hacerlo. ¿Qué es DevSecOps?

Dr. David Brumley: Bueno, en pocas palabras, DevSecOps se trata de crear una gran aplicación al tiempo que capacita a todos con la mentalidad de que la seguridad es responsabilidad de todos. Se requieren lecciones que hemos aprendido sobre cómo construir, implementar y ejecutar aplicaciones durante más de 40 años de investigación y práctica, y se basa en esta idea de que la seguridad no debería ser un paso al final. No es una casilla de verificación. Lo hemos intentado. Lo hemos intentado durante 40 años.

Era costoso, propenso a errores, simplemente se rompió y, en cambio, DevSecOps comienza a plegarse en seguridad durante todo el proceso. Entonces, cuando pienso en DevSecOps, no es solo una moda pasajera. No es solo algo que tengo que elegir sobre una metodología diferente. Es realmente la evolución con todas estas lecciones aprendidas.

VER: Seguridad de confianza cero: una hoja de trucos (PDF gratuito) (TechRepublic)

Bill Detwiler: Y así debe ser, ¿verdad? Realmente debería ser una evolución.

Dr. David Brumley: Absolutamente debería ser. Entonces, si retrocedemos un poco en la historia y hacemos un recorrido histórico para comprender qué es DevSecOps y qué problemas soluciona, todo comienza en 1976 con un documento y la conferencia IEEE sobre ingeniería de software. Ese documento es el que realmente arraigó esta idea de que la seguridad es una casilla de verificación al final. Es importante pensar qué propuso eso y cómo lo solucionamos. En el pasado, solíamos pensar en la seguridad del software y el método de la cascada. Eso fue realmente a lo que condujo ese artículo de 1976 y realmente tuvo cinco pasos diferentes. Entonces tenemos tiempo aquí mismo.

Lo primero que debe hacer es salir y reunir un montón de requisitos. ¿Cuál es el objetivo comercial que estás tratando de lograr? Luego ingresas a una fase de diseño. Aquí es donde estás pensando en cuáles son los diferentes componentes, cómo lo separamos, cómo comenzamos a dividirlo en equipos, etc.

Luego llegas a una fase de implementación. Tienes a todos tus desarrolladores que están creando la aplicación y, por supuesto, porque quieres verificar su trabajo, tendrás un paso de verificación. En realidad, lo que esto significaba originalmente era que desea verificar que la implementación cumpla con los requisitos y lo que sucede con el tiempo es la seguridad. A medida que las personas comenzaron a brindar seguridad, debe verificar que sea seguro y luego ingresar en esta fase de mantenimiento.

Ahora, esta es una cascada y lo que hemos aprendido de esto es que hay al menos tres grandes problemas.

Bill Detwiler: Al menos tres, ¿de acuerdo? Pensé que podría haber más.

<a href = "https://tr4.cbsistatic.com/hub/i/r/2020/07/30/f276ec12-439a-49aa-a99f-679601fbbd95/resize/370x/dcd437a2070d33d1badf91ab60bcdaad/2020-02-24-isb -dbrumley.jpg "target =" _ blank "data-component =" modalEnlargeImage "data-headline ="

David Brumley, profesor de ingeniería eléctrica e informática en la Universidad Carnegie Mellon y CEO de ForAllSecure

"data-credit =" Credit: ForAllSecure "rel =" noopener noreferrer nofollow ">David Brumley

David Brumley, profesor de ingeniería eléctrica e informática en la Universidad Carnegie Mellon y CEO de ForAllSecure

Crédito: ForAllSecure

Dr. David Brumley: Al menos tres grandes problemas. Primero, es muy lineal y esa no es la forma en que funciona el mundo. Aprendemos cosas a medida que comenzamos a implementar a medida que comenzamos a implementar aplicaciones, por lo que tenemos que construir en un ciclo de retroalimentación. Ahora pensamos en el componente de desarrollo como un ciclo y ahora realmente lo tenemos en cuatro pasos separados. La primera parte del ciclo es que vamos a planificar.

Eso es un poco como la fase de requisitos. Vamos a codificar, luego vamos a construir el software. Esto no estaba en la fase anterior, descubrimos que el software se está volviendo cada vez más complicado. Tenemos que integrar un equipo de desarrollo con otro antes de que podamos llegar al producto de aplicación terminado. Esta fase de compilación es realmente muy importante: llegaremos más adelante sobre cómo encaja en DevSecOps.

Finalmente, tenemos una fase de prueba. Esto fue una constatación de que la verificación no solo verifica los requisitos, sino que se prueba para ver qué tan bien funciona. Entonces, cuando pensamos en el desarrollo, intentamos que sea un ciclo de movimiento rápido en el que pueda volver a visitar la fase de planificación, puede volver al código, construir, probar y luego, por supuesto, tendremos varias versiones de software . Entonces vamos a lanzarlo.

La segunda cosa en la que Waterfall realmente no pensó es en cómo opera el software. Si le preguntas a alguien en TI, la forma en que construyes el software hace una gran diferencia en la seguridad, así como solo en la velocidad a la que puedes construir grandes operaciones. Entonces DevOps agregó esta idea de que existe el ciclo de operación.

Estás hablando de TI y hay un par de pasos diferentes aquí. Tenemos un paso de configuración; de nuevo, va a funcionar en círculo. Habrá un paso de despliegue. Hay una fase de operaciones. Entonces, después de haber desplegado todo, se sentará allí y hará lo que hace. Luego le hemos agregado un componente de observabilidad. Desea poder, por ejemplo, registrar lo que está sucediendo, comprender cómo sus usuarios interactúan con él. Para las personas que odian los rastreadores, aquí es donde pones el rastreador, ¿verdad?

Entonces esto es lo que sucedió con DevOps. Lo que hace DevSecOps es que realmente toma esta idea de que la seguridad es responsabilidad de todos. Cuando habla de DevSecOps y dice que la seguridad será parte de todo este ciclo. En pocas palabras, comenzamos con esta idea de que la seguridad es la última y ese no fue el único problema aquí: realmente hay tres. El primero fue un proceso lineal. Vamos a hacer un ciclo.

El segundo es que tenemos que descubrir cómo vamos a mantener el software si realmente está implementado, ese es el lado de la operación. El lado de la seguridad fue que será responsabilidad de todos. Como dije, este será un circuito cerrado donde vamos a tomar lecciones ya que lo hemos implementado mientras lo estamos operando. Eso va a retroalimentar a la fase de planificación. Así es como hemos evolucionado en los últimos 40 años.

Entonces DevSecOps no es una moda pasajera. No es algo que elijas sobre alguna otra metodología. Realmente está tomando todas esas lecciones que aprendimos y poniéndolo en un gran marco.

Cómo comenzar con DevSecOps

Bill Detwiler: Entonces esta es una gran explicación. Si una empresa quiere comenzar a integrar DevSecOps en su proceso de desarrollo, ¿cómo lo hacen y cuáles son algunas de las herramientas para ayudar a las empresas a hacerlo de manera efectiva?

Dr. David Brumley: Creo que hoy en día hay muchas herramientas diferentes entre las que las personas pueden elegir y, a veces, las personas se confunden porque, 'Bueno, pensé que esta herramienta encontró todas las vulnerabilidades. ¿Por qué necesito este otro? Y realmente se trata de poner diferentes herramientas que sean apropiadas para diferentes fases.

Quiero dar un paso atrás y decir que DevSecOps también es una mentalidad. Se trata de los procesos y las personas, no solo las herramientas que tiene que invertir en esos dos primeros componentes, también. Herramientas: piense en ellas como un habilitador, por lo que a medida que avanzamos en este ciclo, puede comenzar a pensar en el tipo de herramientas que pondría.

Lo primero es que cuando pensamos en la etapa de planificación, la gente ha comenzado a construir sistemas de seguimiento de programas y seguimiento de problemas, cosas como JIRA, por ejemplo, donde puede encontrar más rápidamente este es el conjunto de requisitos.

También es algo que su equipo de desarrollo puede ver. No es un equipo separado de la unidad de negocios que lo hace. Vemos a los que vienen aquí, y este también es un gran lugar para comenzar a pensar en la arquitectura de seguridad y el tipo de cosas que desea proteger. ¿Dónde están tus datos? ¿Dónde está tu superficie de ataque? Y así sucesivamente … Y el paso de codificación: por supuesto, cuando estás mirando DevSecOps, quieres tener control de revisión y la razón por la que quieres que sea así, ya que la gente está ingresando el código, a medida que entran esos cambios, puede comenzar a agregar procesos como la revisión por pares para que sepa, si escribí el código, a veces el autor no ve los puntos ciegos, alguien más, cuando está registrado, puede revisarlo y asegurarse de que sea seguro y debidamente codificado. El paso de compilación ha llamado mucho la atención en DevSecOps.

La razón por la que tenemos esto es que la detección es a menudo donde ponemos ganchos en el paso de compilación porque este es el primer lugar donde se integra todo el código que se ha escrito. Entonces hay un par de cosas que la gente hace aquí. Una de las cosas que ayudó a DevSecOps es una idea de implementaciones reproducibles. Eso no suena como seguridad, así que déjame explicarte.

Cuando nos fijamos en los viejos tiempos, cuando escribía el software por primera vez, tenías desarrollo y se les ocurrió tal vez un paquete que ingresarías e instalarías en un sistema completamente diferente y que este sistema tenía una configuración y esto uno tenía una configuración diferente. Bueno, eso es solo pedir problemas de seguridad, ¿verdad? Las herramientas como Docker se vuelven muy populares porque durante el desarrollo podemos probar ambas, una plataforma de desarrollo y cómo se va a operar y asegurarnos de que sean consistentes y que hayamos implementado todas las mejores prácticas.

El segundo conjunto de cosas que las personas enganchan al sistema de compilación son un conjunto de herramientas de prueba de seguridad de aplicaciones. En mi opinión, si nos fijamos en el grupo de Gartner, tienen cuadrantes mágicos, etc. Creo que queremos ver cuáles son los diferentes tipos que entran aquí y qué hacen. En un nivel alto, hay dos conjuntos diferentes de herramientas que las personas obtienen.

Existe el conjunto de herramientas que encuentran vulnerabilidades conocidas y el conjunto de herramientas que encuentran vulnerabilidades desconocidas; estos son dos conjuntos diferentes de herramientas. Una vulnerabilidad conocida es algo como lo que estoy construyendo y estoy usando un componente de código abierto y se ha encontrado una vulnerabilidad. ¿Cómo me aseguro de seguir y rastrear esa última dependencia? La gran herramienta que la gente termina usando aquí se llama análisis de componentes de software.

Piense en ello como solo revisar su biblioteca y asegurarse de que esté actualizada. Una especie de historia divertida es que Equifax fue pirateado y una de las razones por las que eran vulnerables es que están ejecutando una versión vulnerable de los puntales irregulares. Ahora, Apache se había dado cuenta de esa vulnerabilidad y la arregló nueve semanas antes del ataque. Entonces, si hubieran estado ejecutando el análisis de componentes de software, habrían tenido nueve semanas de tiempo para encontrar ese problema y solucionarlo.

Bill Detwiler: Pero simplemente no habían hecho eso todavía.

Dr. David Brumley: Simplemente no lo habían hecho y esa es una de las lecciones: necesitamos tener estas herramientas automatizadas como parte de este ciclo. Ahora, cuando habla de vulnerabilidades desconocidas, estas son cosas que alguien aún no ha descubierto. Tal vez es un código que acaba de escribir o como parte de su propio código, no un componente de terceros y realmente puede dividir este mundo nuevamente en dos.

El enfoque de la vieja escuela para encontrar vulnerabilidades de seguridad es un análisis estático para soluciones basadas en SaaS. Piense en esto como una revisión gramatical del código fuente. Están buscando patrones inseguros. Ahora, en el viejo mundo del desarrollo, estos se volvieron extremadamente populares. Lo que producen es un informe de todos los diferentes lugares.

Puede haber un problema, pero también tienen algo llamado falsos positivos. Un falso positivo es cuando tiene un código seguro, pero la herramienta lo marca, por lo que el análisis estático es bueno. Puede encontrar muchos defectos diferentes, pero cuando te mudes a este mundo, tendrás que contratar a alguien que revise esos informes de análisis estáticos, algo en lo que pensar.

Bill Detwiler: También podría ralentizar el proceso.

Dr. David Brumley: Podría ralentizar el proceso. Ciertamente es algo que tendrá que contratar. Ahora, el análisis estático tiene ventajas y una tecnología más madura. También es compatible con más lenguajes de programación. Por otro lado, tenemos un análisis dinámico, por lo que se trata de un conjunto de herramientas que realmente verifican el código mientras se ejecuta y hace 10 años no eran muy sofisticadas. Fueron ataques preprogramados, pero ha habido una pequeña revolución aquí y uno de los grandes ha sido la introducción de fuzzing.

Lo que hace fuzzing es que ejecuta su programa e intenta atacarlo un poco como un atacante para buscar esas vulnerabilidades. Ahora, análisis dinámico, cada vez que dice que esto es un problema, puede probarlo. Cero falsos positivos. Cuando observa qué herramientas implementar, realmente tiene una opción. ¿Desea análisis estático o análisis dinámico para vulnerabilidades desconocidas? La compensación que realmente debe tener en cuenta si es un ejecutivo o desarrollador: ¿Voy a contratar a alguien para que revise esos informes o quiero algo automático?

Si alguien me pregunta, ¿qué me recomiendan? Bueno, si no estás haciendo algo como el análisis de componentes de software, realmente no estás haciendo lo suficiente, ¿verdad? Debe asegurarse de que todas sus dependencias estén actualizadas. Equifax nos ha enseñado esa lección; no te quemes como Equifax. Si va a elegir una herramienta para lo desconocido, mi regla general es que, si hay un difusor que admita bien su idioma, esto acelerará su desarrollo y aumentará mucho su seguridad, y esto es por lo que deberías ir.

Si está buscando una aplicación que no tiene un fuzzer bien soportado, vaya con análisis estático. Cuando observa a personas como Google, puedo decirle que hacen cosas casi exclusivamente como análisis de componentes de software y fuzzers, y esto ha sido un cambio a medida que nos mudamos a DevSecOps. Déjame contarte sobre el tipo de tecnologías en el lado de operaciones también.

Entonces, cuando observa el lado de las operaciones, tenemos los pasos de configuración, implementación y operaciones como se observa. Si observa varios diagramas de DevSecOps, todos tendrán este ocho en su lado o forma infinita. Se verán así y todos tendrán esencialmente el mismo tipo de características que pueden diferir.

Pero, cuando lo miras, una de las cosas clave es cuando configuras la aplicación, quieres tenerla automatizada y quieres ocuparte de, nuevamente, asegurarte de tener un entorno reproducible para que, Dios no lo quiera , no estás usando una biblioteca antigua aquí en producción mientras tus desarrolladores ya han actualizado. En el paso de implementación, tiene muchas herramientas que se ocupan de cosas como la gestión secreta. Y lo que quiero decir con eso es que si vas a implementar una aplicación web, vas a trabajar en un servidor web y eso tiene una clave criptográfica.

Por lo tanto, desea crear mecanismos que implementen automáticamente su software. Cosas como Kubernetes se están volviendo extremadamente populares debido a esto, porque ayudan a administrar algunas de esas funciones de seguridad. Como, 'Hey, ¿cómo hago para manejar secretos?'

En el lado de las operaciones, vemos muchas herramientas de TI tradicionales y son completamente apropiadas y DevSecOps. Eso es una gran cosa. Sin embargo, no es como si tuvieras que comprar una herramienta completamente nueva. Ves cosas como los sistemas de detección de intrusos. Ahora, estos operan en la capa de red, son realmente importantes para monitorear su red y ver si está bajo ataque.

También hemos visto el surgimiento de algo llamado autoprotección de aplicaciones en tiempo de ejecución (RASP) y lo que RASP está haciendo es asegurarse de que la capa de la aplicación, que si hay un ataque, lo detecte y lo evite. Estas son en realidad tecnologías complementarias (detección de intrusos y RASP) porque hay dos capas diferentes. De hecho, podemos lanzar al cubo algo llamado firewall de aplicaciones web que está en otra capa. Por lo tanto, hay un conjunto de herramientas aquí que puede tener que controlar para garantizar la seguridad.

En el lado de la observación, entras en cosas como la administración de registros. Ahora, Dios no permita que te comprometas. Una de las cosas que querrá hacer es reaccionar rápidamente, descubrir qué está comprometido, para que pueda tomar medidas. Las infraestructuras de registro son un gran problema aquí y es posible que no piense en esto como seguridad. Puede estar pensando en estos para '¿cómo veo qué páginas están visitando las personas?' Pero cuando ocurre un incidente, estarás muy agradecido de tenerlos.

Ver también

20200320-devsecops-bill-new.jpg "src =" https://tr4.cbsistatic.com/hub/i/r/2020/07/24/d5fbe579-0d2a-47b2-a9ec-d831a47b8879/resize/770x/7824cf317cfab6a665dad31025fe72 /20200320-devsecops-bill-new.jpg



Enlace a la noticia original