Miedo y asco DevSecOps

Teníamos 2 analizadores de código, 4 herramientas para pruebas dinámicas, nuestras propias manualidades y 250 scripts. No es que todo esto fuera necesario en el proceso actual, pero desde que comencé a implementar DevSecOps, debemos ir al final.



Fuente Autores de los personajes: Justin Royland y Dan Harmon.

¿Qué es SecDevOps? ¿Qué pasa con DevSecOps? Cuales son las diferencias? Seguridad de la aplicación: ¿de qué se trata? ¿Por qué el enfoque clásico ya no funciona? Yury Shabalin de Swordfish Security sabe la respuesta a todas estas preguntas . Yuri responderá todo en detalle y analizará los problemas de cambiar del modelo clásico de Application Security al proceso DevSecOps: cómo abordar la integración del proceso de desarrollo seguro en el proceso DevOps y no romper nada, cómo pasar por las etapas principales de las pruebas de seguridad, qué herramientas se pueden usar, qué difieren y cómo configurarlos correctamente para evitar dificultades.


Sobre el orador: Yuri Shabalin - Arquitecto jefe de seguridad en Swordfish Security . Es responsable de la implementación de SSDL, de la integración general de las herramientas de análisis de aplicaciones en un único ecosistema de desarrollo y pruebas. 7 años de experiencia en seguridad de la información. Trabajó en Alfa Bank, Sberbank y Positive Technologies, que desarrolla software y brinda servicios. Ponente de conferencias internacionales ZerONights, PHDays, RISSPA, OWASP.

Seguridad de la aplicación: ¿de qué se trata?

Application Security es la sección de seguridad responsable de la seguridad de la aplicación. Esto no se aplica a la infraestructura o la seguridad de la red, es decir, lo que escribimos y en qué están trabajando los desarrolladores; estos son los defectos y vulnerabilidades de la aplicación en sí.

Microsoft desarrolló la dirección de SDL o SDLC ( ciclo de vida del desarrollo de seguridad) . El diagrama muestra el modelo canónico de SDLC, cuya tarea principal es la participación de la seguridad en cada etapa del desarrollo, desde los requisitos, hasta el lanzamiento y el lanzamiento a la producción. Microsoft se dio cuenta de que había demasiados errores en el baile de graduación, había más de ellos y había que hacer algo, y propusieron este enfoque, que se convirtió en canónico.



Application Security y SSDL no tienen como objetivo detectar vulnerabilidades, como comúnmente se cree, sino prevenir su aparición. Con el tiempo, el enfoque canónico de Microsoft fue mejorado, desarrollado y apareció una inmersión más profunda y detallada.



Canonical SDLC es altamente detallado en varias metodologías: OpenSAMM, BSIMM, OWASP. Las metodologías son diferentes, pero generalmente similares.

Construyendo modelo de seguridad en madurez

Lo que más me gusta de BSIMM es la construcción del modelo de seguridad en la madurez . La base de la metodología es la separación del proceso de Seguridad de la Aplicación en 4 dominios: Gobierno, Inteligencia, Puntos de contacto SSDL e Implementación. Cada dominio tiene 12 prácticas, que se representan como 112 actividades.



Cada una de las 112 actividades tiene 3 niveles de madurez : elemental, intermedio y avanzado. Las 12 prácticas se pueden estudiar en secciones, seleccionar cosas importantes para usted, comprender cómo implementarlas y agregar elementos gradualmente, por ejemplo, análisis de código estático y dinámico o revisión de código. Usted pinta el plan y trabaja con calma en él como parte de la implementación de las actividades seleccionadas.

Por qué DevSecOps

DevOps es un gran proceso común en el que debe cuidar la seguridad.

Inicialmente, DevOps incluyó controles de seguridad. En la práctica, el número de equipos de seguridad era mucho menor que ahora, y actuaron no como participantes en el proceso, sino como un organismo de control y supervisión que establece los requisitos y verifica la calidad del producto al final del lanzamiento. Este es un enfoque clásico en el que los equipos de seguridad estaban detrás del muro del desarrollo y no estaban involucrados en el proceso.



El principal problema es que la seguridad de la información está separada del desarrollo. Por lo general, este es un tipo de circuito IB y contiene 2-3 herramientas grandes y costosas. Una vez cada seis meses, llega el código fuente o la aplicación, que debe verificarse, y una vez al año se producen pentests . Todo esto lleva al hecho de que los plazos para ingresar al baile de graduación se posponen, y una gran cantidad de vulnerabilidades de las herramientas automatizadas caen sobre el desarrollador. Todo esto no se puede desmontar y reparar, porque los resultados de los seis meses anteriores no se han resuelto, y aquí hay un nuevo lote.

En el proceso de nuestra empresa, vemos que la seguridad en todas las áreas e industrias comprende que es hora de tirar de ti mismo y girar con el desarrollo en una sola rueda: en Agile . El paradigma DevSecOps se adapta muy bien a la metodología de desarrollo ágil, a la implementación, el soporte y la participación en cada versión e iteración.

Transición a DevSecOps

La palabra más importante en el ciclo de vida del desarrollo de seguridad es "proceso" . Debe comprender esto antes de pensar en comprar herramientas.

La incorporación de herramientas en el proceso DevOps no es suficiente: la interacción y la comprensión entre los participantes del proceso es importante.

Más importante que las personas, no las herramientas.

A menudo, la planificación de un proceso de desarrollo seguro comienza con la selección y compra de una herramienta, y termina con intentos de integrar la herramienta en el proceso actual, que siguen siendo intentos. Esto lleva a tristes consecuencias, porque todas las herramientas tienen sus propias características y limitaciones.

Un caso común cuando el departamento de seguridad eligió una herramienta buena y costosa, con excelentes características, y acudió a los desarrolladores para incorporarlo en el proceso. Pero no funciona: el proceso está estructurado de modo que las limitaciones de la herramienta ya comprada no encajan en el paradigma actual.

Primero, describa qué resultado desea y cómo se verá el proceso. Esto ayudará a comprender los roles de la herramienta y la seguridad en el proceso.

Comience con lo que ya está en uso

Antes de comprar herramientas costosas, mira lo que ya tienes. Cada empresa tiene requisitos de seguridad para el desarrollo, hay controles, pentests, ¿por qué no transformar todo esto en una forma comprensible y conveniente para todos?

Por lo general, los requisitos son un Talmud de papel, que se encuentra en un estante. Hubo un caso cuando acudimos a la empresa para ver los procesos y solicitar mostrar los requisitos de seguridad para el software. El especialista que hizo esto estuvo buscando durante mucho tiempo:

- Ahora, en algún lugar de las notas había una forma en la que se encuentra este documento.

Como resultado, recibimos el documento una semana después.

Para requisitos, verificaciones y otras cosas, cree una página, por ejemplo, sobre Confluence ; esto es conveniente para todos.

Es más fácil formatear lo que ya está allí y usarlo para comenzar.

Use campeones de seguridad

Por lo general, en una empresa mediana para 100-200 desarrolladores trabaja un oficial de seguridad, que realiza varias funciones y físicamente no tiene tiempo para verificar todo. Incluso si hace todo lo posible, él solo no verificará todo el código que genera el desarrollo. Para tales casos, se ha desarrollado un concepto: Security Champions .

Security Champions es una persona dentro del equipo de desarrollo que está interesada en la seguridad de su producto.

Security Champion es el punto de entrada para el equipo de desarrollo y el evangelista de seguridad, todo en uno.

Por lo general, cuando una caja fuerte llega al equipo de desarrollo e indica un error en el código, recibe una respuesta sorprendente:

"¿Quién eres?" Te veo por primera vez. Estoy bien: mi amigo principal en el conjunto de revisión de códigos "aplica", ¡vamos más allá!

Esta es una situación típica, porque hay mucha más confianza en los compañeros de equipo senior o solo, con quienes el desarrollador interactúa constantemente en el trabajo y en la revisión del código. Si, en lugar del guardia de seguridad, el Campeón de Seguridad indica el error y las consecuencias, entonces su palabra tendrá más peso.

Además, los desarrolladores conocen su código mejor que cualquier proveedor de seguridad. Para una persona que tiene al menos 5 proyectos en una herramienta de análisis estático, generalmente es difícil recordar todos los matices. Los campeones de seguridad conocen su producto: qué interactúa con qué y qué mirar en primer lugar, son más efectivos.

Así que piense en implementar Security Champions y expandir la influencia del equipo de seguridad. Para el propio campeón, esto también es útil: desarrollo profesional en un nuevo campo, expandir los horizontes técnicos, aumentar las habilidades técnicas, gerenciales y de liderazgo, aumentar el valor de mercado. Este es un elemento de la ingeniería social, sus "ojos" en el equipo de desarrollo.

Pasos de prueba

El paradigma del 20 al 80 dice que el 20% del esfuerzo produce el 80% del resultado. Este 20% son prácticas de análisis de aplicaciones que pueden y deben automatizarse. Ejemplos de tales actividades son el análisis estático ( SAST) , el análisis dinámico ( DAST) y el control de código abierto . Le contaré más sobre las actividades, así como sobre las herramientas, las características que usualmente encontramos cuando se introducen en el proceso y cómo hacerlo correctamente.

Los principales problemas de las herramientas.

Destacaré los problemas que son relevantes para todas las herramientas que requieren atención. Los analizaré con más detalle para no repetir más.

Análisis a largo plazo. Si tarda 30 minutos en completar todas las pruebas y el ensamblaje desde el compromiso para ir al producto, las verificaciones de seguridad de la información tomarán un día. Entonces nadie retrasará el proceso. Considere esta característica y saque conclusiones.

Alto falso negativo o falso positivo. Todos los productos son diferentes, todos usan marcos diferentes y su propio estilo de código de escritura. En diferentes bases de código y tecnologías, las herramientas pueden mostrar diferentes niveles de falso negativo y falso positivo. Por lo tanto, vea qué exactamente en su empresa y para sus aplicaciones mostrará un resultado bueno y confiable.

Sin integración con las herramientas existentes . Mira las herramientas en términos de integraciones para que ya estés usando. Por ejemplo, si tiene Jenkins o TeamCity, verifique la integración de las herramientas con este software, y no con GitLab CI, que no utiliza.

La ausencia o complejidad excesiva de personalización. Si la herramienta no tiene una API, ¿por qué es necesaria? Todo lo que se puede hacer en la interfaz debe ser accesible a través de la API. Idealmente, la herramienta debería tener la capacidad de personalizar cheques.

Sin hoja de ruta para el desarrollo de productos. El desarrollo no se detiene, siempre usamos nuevos marcos y funciones, reescribimos el código antiguo en nuevos lenguajes. Queremos asegurarnos de que la herramienta que compramos admitirá nuevos marcos y tecnologías. Por lo tanto, es importante saber que el producto tiene una Hoja de ruta de desarrollo real y adecuada.

Características del proceso

Además de las características de las herramientas, considere las características del proceso de desarrollo. Por ejemplo, interferir con el desarrollo es un error típico. Veamos qué otras características deben considerarse y a qué debe prestar atención el equipo de seguridad.

Para no interrumpir el desarrollo y las fechas de lanzamiento, cree diferentes reglas y diferentes topes de espectáculos (criterios para detener el proceso de compilación en presencia de vulnerabilidades) para diferentes entornos . Por ejemplo, entendemos que la rama actual va al puesto de desarrollo o UAT, por lo que no nos detenemos y no decimos:

- Tienes vulnerabilidades aquí, ¡no irás más lejos!

En este punto, es importante decirles a los desarrolladores que hay problemas de seguridad a los que vale la pena prestarles atención.

La presencia de vulnerabilidades no es un obstáculo para pruebas adicionales : manual, integración o manual. Por otro lado, necesitamos aumentar de alguna manera la seguridad del producto, y para que los desarrolladores no se olviden de lo que encuentran seguridad. Por lo tanto, a veces hacemos esto: en el stand, cuando se implementa en el entorno de desarrollo, simplemente notificamos al desarrollo:

- Chicos, tienen problemas, presten atención a ellos.

En la etapa UAT, nuevamente mostramos advertencias sobre vulnerabilidades, y en la etapa de salida en el baile de graduación decimos:

- Chicos, lo hemos advertido varias veces, no hicieron nada, no lo dejaremos salir con esto.

Si hablamos de código y dinámica, es necesario mostrar y advertir sobre las vulnerabilidades solo de las características y el código que se acaba de escribir en esta característica. Si el desarrollador movió el botón 3 píxeles y le decimos que tiene una inyección SQL allí y, por lo tanto, necesita ser reparado con urgencia, esto está mal. Mire solo lo que está escrito ahora y el cambio que viene a la aplicación.

Supongamos que tenemos un cierto defecto funcional: la forma en que la aplicación no debería funcionar: el dinero no se transfiere, cuando hace clic en el botón, no hay transición a la página siguiente o el producto no se carga. Los defectos de seguridad son los mismos defectos, pero no en el contexto de la aplicación, sino de seguridad.

No todos los problemas de calidad del software son problemas de seguridad. Pero todos los problemas de seguridad están relacionados con la calidad del software. Sherif Mansour, Expedia.

Dado que todas las vulnerabilidades son los mismos defectos, deben ubicarse en el mismo lugar que todos los defectos de desarrollo. Así que olvídate de los informes y los PDF de miedo que nadie lee.



Cuando trabajaba para una empresa de desarrollo, recibí un informe de las herramientas de análisis estático. Lo abrí, me horroricé, hice café, hojeé 350 páginas, lo cerré y seguí trabajando. Los grandes informes son informes muertos . Por lo general, no van a ninguna parte, las cartas se eliminan, se olvidan, se pierden o la empresa dice que toma riesgos.

Que hacer Simplemente transformamos los defectos confirmados que encontramos en una forma conveniente para el desarrollo, por ejemplo, los agregamos a la cartera de pedidos en Jira. Priorizamos y eliminamos defectos en orden de prioridad junto con defectos funcionales y defectos de prueba.

Análisis estático - SAST

Este es un análisis de código para vulnerabilidades , pero no es lo mismo que SonarQube. Verificamos no solo por patrones o estilo. En el análisis, se utilizan varios enfoques: en el árbol de vulnerabilidades, en DataFlow , en el análisis de los archivos de configuración. Todo esto está directamente relacionado con el código.

Ventajas del enfoque : identificar vulnerabilidades en el código en una etapa temprana de desarrollo , cuando no hay soportes y una herramienta terminada, y la posibilidad de escaneo incremental : escanear una sección de código que ha cambiado, y solo la característica que estamos haciendo ahora, lo que reduce el tiempo de escaneo.

Contras : esta es la falta de soporte para los idiomas necesarios.

Las integraciones necesarias que deberían estar en las herramientas, en mi opinión subjetiva:

• Herramienta de integración: Jenkins, TeamCity y Gitlab CI.
  
• Entorno de desarrollo: Intellij IDEA, Visual Studio. Es más conveniente para el desarrollador no meterse en una interfaz incomprensible que aún necesita ser recordada, sino directamente en el lugar de trabajo en su propio entorno de desarrollo para ver todas las integraciones y vulnerabilidades necesarias que encontró.
  
• Revisión de código: SonarQube y revisión manual.
  
• Rastreadores de defectos: Jira y Bugzilla.
  

La imagen muestra algunos de los mejores representantes del análisis estático.



Lo importante no son las herramientas, sino el proceso, por lo que existen soluciones de código abierto que también son buenas para ejecutar el proceso.



SAST Open Source no encontrará una gran cantidad de vulnerabilidades o DataFlow complejo, pero puede y debe usarlos al crear un proceso. Ayudan a comprender cómo se construirá el proceso, quién responderá a los errores, a quién informar, a quién informar. Si desea llevar a cabo la etapa inicial de construir la seguridad de su código, use soluciones de código abierto.

¿Cómo se puede integrar esto si está al comienzo del camino, no tiene nada: ni CI, ni Jenkins, ni TeamCity? Considere la integración en el proceso.

Integración CVS

Si tiene Bitbucket o GitLab, puede hacer la integración en el nivel del Sistema de Versiones Simultáneas .

Por evento : solicitud de extracción, confirmación. Escanea el código y muestra en el estado de compilación que la verificación de seguridad ha pasado o ha fallado.

Comentarios Por supuesto, siempre se necesita retroalimentación. Si acaba de actuar en el lado de la seguridad, póngalo en una caja y no se lo contó a nadie, y luego arrojó un montón de errores a fin de mes; esto no es correcto ni bueno.

Integración con revisión de código

Una vez, en varios proyectos importantes, configuramos el revisor predeterminado del usuario técnico de AppSec. Dependiendo de si se detectaron errores en el nuevo código o si no hay errores, el revisor coloca el estado en "aceptar" o "necesita trabajar" en la solicitud de extracción: o todo está bien, o necesita refinar y enlaces a exactamente qué finalizar. Para la integración con la versión que va al producto, teníamos habilitada la prohibición de fusión si no se pasa la prueba IB. Incluimos esto en una revisión manual del código, y otros participantes en el proceso vieron estados de seguridad para este proceso en particular.

Integración SonarQube

Muchos tienen una puerta de calidad para la calidad del código. Lo mismo aquí: puede hacer las mismas puertas solo para las herramientas SAST. Habrá la misma interfaz, la misma puerta de calidad, solo que se llamará puerta de seguridad . Y también, si tiene un proceso usando SonarQube, puede integrar fácilmente todo lo que hay allí.

Integración CI

Aquí, también, todo es bastante simple:

• Al mismo nivel que las pruebas automáticas , las pruebas unitarias.
  
• Separación por etapas de desarrollo : desarrollo , prueba, producción. Se pueden incluir diferentes conjuntos de reglas o diferentes condiciones de falla: detener el ensamblaje, no detener el ensamblaje.
  
• Arranque síncrono / asíncrono . Estamos esperando el final de la prueba de seguridad o no estamos esperando. Es decir, los lanzamos y seguimos adelante, y luego recibimos el estado de que todo es bueno o malo.
  

Todo está en un mundo rosado perfecto. En la vida real, esto no es así, pero nos esforzamos. El resultado de los controles de seguridad debe ser similar a los resultados de las pruebas unitarias.

Por ejemplo, tomamos un proyecto grande y decidimos que ahora lo escanearemos con SAST'om - OK. Empujamos este proyecto en SAST, nos dio 20,000 vulnerabilidades y, con una decisión decidida, aceptamos que todo está bien. 20,000 vulnerabilidades son nuestro deber técnico. Pondremos la deuda en una caja, y poco a poco iremos acumulando y comenzando errores en los rastreadores de defectos. Contratamos una empresa, lo hacemos todos nosotros o Security Champions nos ayudará, y nuestra deuda técnica disminuirá.

Y todas las vulnerabilidades emergentes en el nuevo código deben corregirse, así como los errores en la unidad o en las pruebas automáticas. Relativamente hablando, la asamblea comenzó, se alejó, dos pruebas y dos pruebas de seguridad cayeron. OK, fueron, miraron lo que sucedió, corrigieron una cosa, corrigieron la segunda, la expulsaron la próxima vez: todo está bien, no hubo nuevas vulnerabilidades, las pruebas no fallaron. Si esta tarea es más profunda y necesita comprenderla bien, o corregir las vulnerabilidades afecta a grandes capas de lo que se esconde debajo del capó: introdujeron un error en el rastreador de defectos, se prioriza y soluciona. Desafortunadamente, el mundo no es perfecto y las pruebas a veces fallan.

Un ejemplo de una puerta de seguridad es un análogo de una puerta de calidad, por la presencia y la cantidad de vulnerabilidades en el código.

Nos integramos con SonarQube: el complemento está instalado, todo es muy conveniente y genial.

Integración del entorno de desarrollo.

Capacidades de integración:

• Iniciar un escaneo desde el entorno de desarrollo antes de confirmar.
  
• Ver resultados.
  
• Análisis de los resultados.
  
• Sincronización con el servidor.
  

Parece algo así como obtener resultados del servidor.



En nuestro entorno de desarrollo Intellij IDEA , simplemente aparece un elemento adicional que informa que tales vulnerabilidades se detectaron durante el análisis. Puede editar inmediatamente el código, ver recomendaciones y Flow Graph . Todo esto se encuentra en el lugar de trabajo del desarrollador, lo cual es muy conveniente: no tiene que ir al resto de los enlaces y ver algo adicional.

Código abierto

. Open Source — , , ?



, , , , , , . Application Security — Open Source .

Open Source — OSA

.

. , , - , CVE - - , . , , , .

. , , , . , . , , . , , .

, . , . — , , . , , . Open Source , , -. , , . , . .

:

• .
  
• .
  
• .
  
• .
  
• Docker-.
  

, Open Source.


— Dependency-Check OWASP. , , . , on-premise, . , , , , .

, . . , Event Central Nexus, , «» «». Nexus Firewall Lifecycle , .

CI . , - : dev, test, prod. , , , - «critical» -, .

: Nexus JFrog.

. , , . , CVS.

CD. , — . .



Public Component Repositories — , . , trusted components. , . , , . , - , — .

• build' , , .
  
• trusted components.
  
• : war, jar, DL Docker- , .
  
• , : .
  

— DAST

, . . -, , , , : , , , , .

Open Source. DAST , Open Source , «» :

— , , .

, , — .

• \ .
  
• .
  
• .
  
• .
  
• .
  

, AppScan: , 3 — - ! , , AppScan — -, , , mailform -. :

— , ?! , !

. , -, . — , .

, . 10-15 , , , , .

, .



Burp Suite — « » . , . - enterprise edition. stand alone , - , . , .

: .

mock-, — , .

• — .
  
• .
  
• — .
  

, . — , , OpenSource, - , , Waf .

.

, , , , -.

. , , . , , . , .



API, , , , — AppSec , .

, security- , , , , , . , , — Confluence , Jira -, / CI/CD.

Key Takeaways

. — . , , . — «» , — - high mega super critical, , .

— , . , , . DevSecOps, SecDevOps, .

, : , , , , . — . — .

.

, . , — . - , . , .

— Security Champions .

, , , - — . elija herramientas basadas en los requisitos de su proceso . No mire lo que la comunidad dice que esta herramienta es mala y esta es buena. Quizás sea exactamente lo contrario en su producto.

Requerimientos de herramientas.

• Bajo falso positivo.
  
• Tiempo de análisis adecuado.
  
• Facilidad de uso.
  
• Disponibilidad de integraciones.
  
• Comprensión del desarrollo de productos de hoja de ruta
  
• La capacidad de personalizar herramientas.
  

El informe de Yuri fue elegido como uno de los mejores en DevOpsConf 2018. Para familiarizarse con ideas y casos prácticos aún más interesantes, visite Skolkovo el 27 y 28 de mayo en DevOpsConf como parte del festival RIT ++ . Mejor aún, si está listo para compartir su experiencia, solicite un informe antes del 21 de abril.