🥇Miedo y odio en DevSecOps

Teníamos 2 analizadores de código, 4 herramientas de pruebas dinámicas, nuestras propias creaciones y 250 scripts. No es que todo esto fuera necesario en el proceso actual, pero una vez que comencé a implementar DevSecOps, es necesario hacerlo bien.

Fuente. Creadores de personajes: Justin Roiland y Dan Harmon.

¿Qué es SecDevOps? ¿Y DevSecOps? ¿En qué se diferencian? ¿De qué trata la Seguridad de Aplicaciones? ¿Por qué el enfoque clásico ya no funciona? Todas estas preguntas tienen respuestas. Yuri Shabalin de Swordfish Security. Yuri responderá a todo en detalle y abordará los problemas de la transición del modelo clásico de Seguridad de Aplicaciones al proceso DevSecOps: cómo integrar adecuadamente el proceso de desarrollo seguro en el proceso de DevOps sin romper nada, cómo pasar por las etapas principales de pruebas de seguridad, qué herramientas se pueden utilizar, en qué se diferencian y cómo configurarlas correctamente para evitar trampas.

Sobre el ponente: Yuri Shabalin — Arquitecto de Seguridad Jefe en la empresa Swordfish Security. Es responsable de implementar SSDL, de la integración general de herramientas de análisis de aplicaciones en un ecosistema unificado de desarrollo y pruebas. 7 años de experiencia en seguridad de la información. Ha trabajado en Alfa-Bank, Sberbank y Positive Technologies, que desarrolla software y ofrece servicios. Ponente en conferencias internacionales como ZerONights, PHDays, RISSPA, OWASP.

Seguridad de Aplicaciones: ¿de qué trata?

Seguridad de Aplicaciones — es una rama de la seguridad que se encarga de la seguridad de las aplicaciones. No se relaciona con la infraestructura o la seguridad de la red, sino específicamente con lo que escribimos y en lo que trabajan los desarrolladores: son las vulnerabilidades y defectos de la propia aplicación.

Dirección SDL o SDLC — Ciclo de vida del desarrollo de seguridad — fue desarrollado por Microsoft. En el diagrama está el modelo canónico de SDLC, cuyo objetivo principal es la participación de la seguridad en cada etapa del desarrollo, desde los requisitos hasta el lanzamiento y la producción. Microsoft se dio cuenta de que había demasiados errores en producción, que estaban aumentando y había que hacer algo al respecto, y propuso este enfoque que se ha vuelto canónico.

La Seguridad de Aplicaciones y SSDL no están destinadas a detectar vulnerabilidades, como comúnmente se cree, sino a prevenir su aparición. Con el tiempo, el enfoque canónico de Microsoft fue mejorado y desarrollado, y se profundizó en detalle.

El SDLC canónico está muy detallado en diversas metodologías como OpenSAMM, BSIMM y OWASP. Las metodologías son diferentes, pero en general son similares.

Modelo de Madurez para la Construcción de Seguridad

Me agrada más BSIMM — Modelo de Madurez para la Construcción de Seguridad. La base de la metodología es la división del proceso de Seguridad de Aplicaciones en 4 dominios: Gobernanza, Inteligencia, Puntos de Contacto SSDL y Despliegue. En cada dominio hay 12 prácticas, que se presentan en forma de 112 actividades.

Cada una de las 112 actividades tiene 3 niveles de madurez: inicial, intermedio y avanzado. Todas las 12 prácticas se pueden estudiar por secciones, seleccionar lo que sea importante para usted, entender cómo implementarlas y agregar elementos gradualmente, como análisis estático y dinámico de código o revisión de código. Elabore un plan y, a partir de él, trabaje sin prisa en la implementación de las actividades seleccionadas.

Por qué DevSecOps

DevOps es un gran proceso en el que se debe cuidar la seguridad.

Inicialmente DevOps se asumieron auditorías de seguridad. En la práctica, el número de equipos de seguridad era mucho menor que ahora, y actuaban no como participantes en el proceso, sino como un organismo de control y supervisión que impone requisitos y verifica la calidad del producto al final del lanzamiento. Este es el enfoque clásico, donde los equipos de seguridad estaban separados del desarrollo y no participaban en el proceso.

El principal problema es que la seguridad de la información está separada del desarrollo. Generalmente, hay un contorno de seguridad de la información y en él hay 2-3 grandes y costosas herramientas. Una vez cada seis meses, se recibe código fuente o una aplicación que necesita ser revisada, y una vez al año se realizan pruebas de penetración. Todo esto lleva a que los plazos de lanzamiento se retrasen, y el desarrollador se enfrenta a una gran cantidad de vulnerabilidades de herramientas automatizadas. Todo esto es imposible de resolver y reparar, porque aún no se han analizado los resultados de los seis meses anteriores, y ya hay un nuevo lote.

En el proceso de trabajo de nuestra empresa, vemos que la seguridad en todas las áreas e industrias reconoce que es hora de alinearse y trabajar con el desarrollo en un mismo camino: en Agile. La paradigma DevSecOps encaja perfectamente en la metodología de desarrollo ágil, en la implementación, apoyo y participación en cada lanzamiento e iteración.

Transición a DevSecOps

La palabra más importante en el Ciclo de Vida del Desarrollo de Seguridad es "proceso"Debes entender esto antes de pensar en comprar herramientas.

Simplemente incluir herramientas en el proceso de DevOps no es suficiente; es importante la interacción y comprensión entre los participantes del proceso.

Comienza con lo que ya se utiliza.

Antes de comprar herramientas costosas, observa lo que ya tienes. Cada empresa tiene requisitos de seguridad que se imponen al desarrollo, hay auditorías, pruebas de penetración; ¿por qué no transformar todo esto en una forma clara y conveniente para todos?

Normalmente, los requisitos son un documento en papel que se encuentra en una estantería. Hubo un caso en el que llegamos a una empresa para revisar los procesos y pedimos ver los requisitos de seguridad para el software. El especialista que se encargaba de eso buscó por mucho tiempo:

— Ahora, en algún lugar en las notas había un camino donde se encontraba este documento.

Al final, obtuvimos el documento una semana después.

Para requisitos, auditorías y demás, crea una página, por ejemplo, en Confluence — es conveniente para todos.

Es más fácil reformatear lo que ya existe y usarlo como punto de partida.

Usa los Security Champions.

Normalmente, en una empresa promedio con 100-200 desarrolladores trabaja un experto en seguridad, que desempeña varias funciones y no puede revisar todo físicamente. Incluso si se esfuerza al máximo, no podrá revisar todo el código que genera el desarrollo. Para tales casos, se desarrolló el concepto de Security Champions..

Los Campeones de Seguridad son personas dentro del equipo de desarrollo que están interesadas en la seguridad de su producto.

El Campeón de Seguridad es el punto de entrada al equipo de desarrollo y un evangelista de la seguridad en una sola persona.

Normalmente, cuando un experto en seguridad se une al equipo de desarrollo y señala un error en el código, suele recibir una respuesta sorprendida:

— ¿Y usted quién es? Es la primera vez que lo veo. Todo está bien para mí: un compañero senior en la revisión de código me dijo "aplicar", ¡sigamos adelante!

Esta es una situación típica, porque hay mucha más confianza hacia los compañeros senior o simplemente a los colegas del equipo con los que el desarrollador interactúa constantemente en el trabajo y en las revisiones de código. Si en lugar de un experto en seguridad, es un Campeón de Seguridad quien señala el error y sus consecuencias, su palabra tendrá más peso.

Además, los desarrolladores conocen su código mejor que cualquier experto en seguridad. Para alguien que tiene al menos 5 proyectos en la herramienta de análisis estático, suele ser complicado recordar todos los matices. Los Campeones de Seguridad conocen su producto: con qué interactúa y qué mirar primero, son más efectivos.

Así que reflexione sobre la posibilidad de implementar Campeones de Seguridad y ampliar la influencia del equipo de seguridad. Para el propio campeón, también es útil: desarrollo profesional en un nuevo campo, ampliación de la perspectiva técnica, mejora de habilidades técnicas, de gestión y de liderazgo, aumento en el valor en el mercado. Es un cierto elemento de ingeniería social, sus "ojos" en el equipo de desarrollo.

Etapas de prueba

La parábola 20 a 80 indica que el 20% de los esfuerzos generan el 80% del resultado. Estos 20% son prácticas de análisis de aplicaciones que se pueden y deben automatizar. Ejemplos de tales actividades son el análisis estático, SAST, el análisis dinámico, DAST, y control de código abierto. Hablaré en detalle sobre las actividades, así como sobre las herramientas, con qué peculiaridades nos encontramos normalmente al implementarlas en el proceso y cómo hacerlo correctamente.

Problemas principales de las herramientas

Resaltaré los problemas actuales que requieren atención en todas las herramientas. Los analizaré más a fondo para no repetir más adelante.

Análisis prolongado. Si desde el commit hasta la producción se tardan 30 minutos en todas las pruebas y la compilación, las verificaciones de seguridad llevarán un día. Nadie va a frenar el proceso por eso. Tengan en cuenta esta particularidad y saquen conclusiones.

Alto nivel de False Negative o False Positive. Todos los productos son diferentes, todos utilizan diferentes frameworks y su propio estilo de codificación. En diferentes bases de código y tecnologías, las herramientas pueden mostrar diferentes niveles de False Negative y False Positive. Por lo tanto, presten atención a lo que exactamente en su empresa y para sus aplicaciones mostrará un resultado bueno y confiable.

No hay integraciones con las herramientas existentes. Mire las herramientas desde el punto de vista de las integraciones, con lo que ya está utilizando. Por ejemplo, si tiene Jenkins o TeamCity, verifique la integración de las herramientas precisamente con este software, y no con GitLab CI, que usted no utiliza.

Falta o excesiva complejidad en la personalización. Si la herramienta no tiene API, ¿para qué sirve? Todo lo que se puede hacer en la interfaz debe estar disponible a través de la API. Idealmente, la herramienta debe tener la capacidad de personalizar las verificaciones.

No hay hoja de ruta para el desarrollo del producto. El desarrollo no se detiene, siempre estamos utilizando nuevos frameworks y funciones, reescribiendo código antiguo en nuevos lenguajes. Queremos estar seguros de que la herramienta que compremos seguirá soportando nuevos frameworks y tecnologías. Por eso, es importante saber que el producto tiene una real y correcta Hoja de ruta hoja de ruta.

Particularidades del proceso

Además de las particularidades de las herramientas, tengan en cuenta las particularidades del proceso de desarrollo. Por ejemplo, interferir en el desarrollo es un error típico. Veamos qué otras características deben ser consideradas y en qué debe prestar atención el equipo de seguridad.

Para no retrasar los plazos de desarrollo y lanzamiento, cree diferentes reglas y diferentes show stoppers — criterios para detener el proceso de compilación en caso de vulnerabilidades — para diferentes entornos. Por ejemplo, entendemos que la rama actual va a un entorno de desarrollo o UAT, por lo que no detenemos ni decimos:

— ¡Usted tiene vulnerabilidades aquí, no puede continuar!

En esta etapa, es importante informar a los desarrolladores que hay problemas de seguridad a los que deben prestar atención.

La existencia de vulnerabilidades no es un obstáculo para continuar con las pruebas.: manual, de integración o manual. Por otro lado, necesitamos de alguna manera aumentar la seguridad del producto, para que los desarrolladores no ignoren lo que encuentra la seguridad. Así que a veces actuamos de esta manera: en el entorno de desarrollo, cuando se lanza al entorno de desarrollo, simplemente notificamos a los desarrolladores:

— Chicos, tienen problemas, por favor presten atención a ellos.

En la etapa de UAT, mostramos nuevamente advertencias sobre vulnerabilidades, y en la etapa de salida al entorno de producción decimos:

— Chicos, les hemos advertido varias veces, no han hecho nada: no los dejaremos salir con esto.

Si hablamos del código y la dinámica, solo debemos mostrar y advertir sobre las vulnerabilidades de aquellas funciones y códigos que se han escrito recientemente en esta función. Si un desarrollador ha movido un botón 3 píxeles y le decimos que tiene una inyección SQL y que necesita corregirlo urgentemente, eso es incorrecto. Solo mire lo que se ha escrito ahora y los cambios que están llegando a la aplicación.

Supongamos que tenemos un defecto funcional: cómo no debería funcionar la aplicación: el dinero no se transfiere, al hacer clic en el botón no hay una transición a la siguiente página o no se carga el producto. Los defectos de seguridad son defectos similares, pero no en términos del funcionamiento de la aplicación, sino de la 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 defectos similares, deben estar donde están todos los defectos de desarrollo. Así que olvídense de los informes y los terroríficos PDF que nadie lee.

Cuando trabajaba en una empresa de desarrollo, recibí un informe de herramientas de análisis estático. Lo abrí, me asusté, preparé un café, hojeé 350 páginas, lo cerré y volví a trabajar. Los grandes informes son informes muertos.. Por lo general, no llevan a ninguna parte, los correos se eliminan, se olvidan, se pierden o el negocio dice que asume los riesgos.

¿Qué hacer? Los defectos confirmados que encontré los transformamos en un formato amigable para el desarrollo, por ejemplo, los agrupamos en el backlog en Jira. Priorizamos los defectos y los solucionamos en orden de prioridad junto con los defectos funcionales y de pruebas.

Análisis estático - SAST

Es un análisis de código en busca de vulnerabilidades, pero esto no es lo mismo que SonarQube. No solo verificamos patrones o estilo. Utilizamos varios enfoques para el análisis: basado en el árbol de vulnerabilidades, por DataFlow, por análisis de archivos de configuración. Esto se refiere estrictamente al código.

Ventajas del enfoque: identificación de vulnerabilidades en el código en una etapa temprana del desarrollo, cuando aún no hay entornos y herramientas listos, y posibilidad de escaneo incremental: escaneo de la sección de código que ha cambiado, y solo de la funcionalidad que estamos implementando, lo que reduce el tiempo de escaneo.

Desventajas — la falta de soporte para los lenguajes necesarios.

Integraciones necesarias, que deberían estar presentes 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 cómodo para el desarrollador no tener que lidiar con una interfaz confusa que tiene que memorizar, sino ver todas las integraciones y vulnerabilidades necesarias directamente en su propio entorno de desarrollo.
Revisión de código: SonarQube y revisión manual.
Seguimiento de defectos: Jira y Bugzilla.

En la imagen se presentan 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 adecuadas para perfeccionar el proceso.

El SAST de código abierto no encontrará una gran cantidad de vulnerabilidades o flujos de datos complejos, pero se pueden y deben utilizar al construir el proceso. Ayudan a entender cómo se construirá el proceso, quién será responsable de los errores, quién reportará y quién informará. Si quieres llevar a cabo la etapa inicial de construcción de la seguridad de tu código, utiliza soluciones de código abierto.

¿Cómo se puede integrar esto si estás al principio del camino y no tienes nada: ni CI, ni Jenkins, ni TeamCity? Consideremos las integraciones en el proceso.

Integración a nivel de CVS

Si tienes Bitbucket o GitLab, puedes hacer una integración a nivel de Sistema de Versiones Concurrentes.

Por evento — pull request, commit. Escaneas el código y en el estado de la compilación muestras si la verificación de seguridad pasó o no.

Retroalimentación. Sin duda, la retroalimentación siempre es necesaria. Si simplemente ejecutaste en el lado de seguridad, lo guardaste en una caja y no contaste nada al respecto, y luego al final del mes sacas un montón de errores, eso no está bien y no es correcto.

Integración con el sistema de revisión de código

Una vez establecimos a un usuario técnico de AppSec como revisor predeterminado en varios proyectos importantes. Dependiendo de si se encontraron errores en el nuevo código o no, el revisor en el pull request asigna un estado de 'accept' o 'need work' — o todo está OK, o necesita mejoras y se agregan enlaces sobre qué exactamente debe ser corregido. Para la integración con la versión que se va a producción, teníamos habilitada la prohibición de merge si la prueba de seguridad no pasaba. Esto lo incluimos en la revisión manual de código, y los demás participantes del proceso veían los estados de seguridad exactamente para este proceso específico.

Integración con SonarQube

Muchos tienen quality gate relacionado con la calidad del código. Aquí es lo mismo: se pueden hacer los mismos gates solo para herramientas SAST. Tendrá la misma interfaz, el mismo quality gate, solo que se denominará security gate. Y así, si tienes un proceso configurado utilizando SonarQube, puedes integrar todo sin problemas.

Integración a nivel de CI

Aquí también todo es bastante simple:

En un mismo nivel con pruebas automáticas, pruebas unitarias.
División por etapas de desarrollo: dev, test, prod. Se pueden incluir diferentes conjuntos de reglas, o diferentes condiciones de fallo: detenemos la compilación, no detenemos la compilación.
Ejecución sincrónica/asíncrona. Esperamos la finalización de la verificación de pruebas de seguridad o no. Es decir, simplemente las ejecutamos y continuamos, y luego recibimos el estado de que todo está bien o mal.

Todo esto en un mundo ideal. En la vida real no existe, pero nos esforzamos por ello. El resultado de las pruebas de seguridad debe ser análogo a los resultados de las pruebas unitarias.

Por ejemplo, tomamos un gran proyecto y decidimos que ahora lo escanearemos con SAST — está bien. Metimos este proyecto en SAST, nos dio 20,000 vulnerabilidades y, mediante una decisión voluntariosa, aceptamos que todo estaba bien. 20,000 vulnerabilidades son nuestra deuda técnica. Colocaremos esta deuda en una cajita, la resolveremos poco a poco y registraremos los errores en los rastreadores de defectos. Contrataremos una compañía, lo haremos todo nosotros mismos o contaremos con la ayuda de Security Champions — y la deuda técnica disminuirá.

Y todas las nuevas vulnerabilidades en el nuevo código deben ser corregidas de la misma manera que los errores en las pruebas unitarias o en las pruebas automáticas. En otras palabras, se inició una compilación, se ejecutaron las pruebas, fallaron dos y hubo dos pruebas de seguridad. Está bien — fuimos, miramos qué sucedió, corregimos uno, corregimos el otro, la próxima vez ejecutamos de nuevo — todo bien, no aparecieron nuevas vulnerabilidades, las pruebas no fallaron. Si esta tarea es más compleja y necesita ser entendida a fondo, o si la corrección de vulnerabilidades afecta a grandes capas de lo que está detrás: se registró un error en el rastreador de defectos, se prioriza y se corrige. Desafortunadamente, el mundo no es perfecto y a veces las pruebas fallan.

Un ejemplo de security gate — similar a un quality gate, basado en la presencia y cantidad de vulnerabilidades en el código.

Nos integramos con SonarQube — se instala un plugin, todo es muy conveniente y genial.

Integración con el entorno de desarrollo

Opciones de integración:

Iniciar el escaneo desde el entorno de desarrollo incluso antes del commit.
Visualizar los resultados.
Analizar los resultados.
Sincronización con el servidor.

Así es como se ve la obtención de resultados del servidor.

En nuestro entorno de desarrollo Intellij IDEA aparece simplemente un punto adicional que indica que durante el escaneo se detectaron estas vulnerabilidades. Se puede corregir el código de inmediato, ver las recomendaciones y Flow Graph. Todo esto está ubicado en el espacio de trabajo del desarrollador, lo que es muy conveniente: no es necesario ir a otros enlaces y ver algo adicional.

Open Source

Este es mi tema favorito. Todos usan bibliotecas de código abierto — ¿por qué escribir un montón de parches y bicicletas, cuando se puede utilizar una biblioteca lista que ya tiene todo implementado?

Por supuesto, es así, pero las bibliotecas también son escritas por personas, también conllevan ciertos riesgos y también presentan vulnerabilidades que se informan periódicamente o de manera constante. Por eso existe el siguiente paso en la seguridad de aplicaciones: el análisis de componentes de código abierto.

Análisis de Código Abierto - OSA

La herramienta consta de tres grandes etapas.

Búsqueda de vulnerabilidades en bibliotecas. Por ejemplo, la herramienta sabe que estamos utilizando alguna biblioteca, y que en CVE o en los rastreadores de errores hay algunas vulnerabilidades relacionadas con esa versión de la biblioteca. Al intentar usarla, la herramienta emitirá una advertencia de que la biblioteca es vulnerable y recomendara utilizar otra versión que no tenga vulnerabilidades.

Análisis de la limpieza de licencias. Esto aún no es muy popular aquí, pero si trabajas con el extranjero, a veces puedes recibir un aviso por utilizar un componente de código abierto que no se puede usar o modificar. Según la política de la biblioteca de licencias, no podemos hacer esto. O, si la hemos modificado y la usamos, debemos publicar nuestro código. Por supuesto, nadie quiere publicar el código de sus productos, pero también hay formas de protegerse de esto.

Análisis de componentes que se utilizan en un entorno industrial. Imaginemos una situación hipotética en la que finalmente hemos terminado el desarrollo y lanzamos la última versión de nuestro microservicio. Está funcionando maravillosamente allí: una semana, un mes, un año. No lo estamos manteniendo, no realizamos verificaciones de seguridad, parece que todo está bien. Pero de repente, dos semanas después del lanzamiento, surge una vulnerabilidad crítica en un componente de código abierto que estamos utilizando en esta versión, en el entorno industrial. Si no registramos qué y dónde estamos utilizando, simplemente no veremos esta vulnerabilidad. Algunas herramientas tienen la opción de monitorear vulnerabilidades en bibliotecas que se están utilizando actualmente en producción. Esto es muy útil.

Características:

Políticas diferentes para diferentes etapas de desarrollo.
Monitoreo de componentes en el entorno industrial.
Control de bibliotecas en el perímetro de la organización.
Soporte para diferentes sistemas de construcción y lenguajes.
Análisis de imágenes de Docker.

Algunos ejemplos de líderes en el área que se dedican al análisis de código abierto.

El único gratuito entre ellos es Dependency-Check de OWASP. Se puede habilitar en las primeras etapas, ver cómo funciona y qué soporta. Principalmente son todos productos en la nube o on-premise, pero por su propia base, siempre se envían a internet. No envían tus bibliotecas, sino hashes o valores que calculan, y huellas digitales a su servidor, para obtener notificaciones sobre la existencia de vulnerabilidades.

Integración en el proceso

Control de bibliotecas en el perímetro, que se descargan de fuentes externas. Tenemos repositorios externos e internos. Por ejemplo, dentro de Event Central hay un Nexus, y queremos que no haya vulnerabilidades con estado 'crítico' o 'alto' en nuestro repositorio interno. Se puede configurar el proxy usando la herramienta Nexus Firewall Lifecycle para que tales vulnerabilidades se filtren y no lleguen al repositorio interno.

Integración en CI. A la par con pruebas automáticas, pruebas unitarias y división por etapas de desarrollo: dev, test, prod. En cada etapa se pueden descargar cualquier bibliotecas, usar lo que sea, pero si hay algo serio con estado 'crítico', quizás vale la pena que los desarrolladores lo noten en la etapa de lanzamiento a producción.

Integración con artefactos: Nexus y JFrog.

Integración en el entorno de desarrollo. Las herramientas que elijas deben tener integración con los entornos de desarrollo. El desarrollador debe tener acceso desde su lugar de trabajo a los resultados del escaneo, o la posibilidad de escanear y verificar el código en busca de vulnerabilidades antes de hacer un commit en CVS.

Integración en CD. Es una característica fantástica que realmente me gusta y de la que ya he hablado: el monitoreo de nuevas vulnerabilidades en el entorno de producción. Funciona más o menos así.

Tenemos Repositorios de Componentes Públicos — algunas herramientas externas y nuestro repositorio interno. Queremos que solo contenga componentes confiables. Al proxyizar la solicitud, verificamos que la biblioteca descargada no tenga vulnerabilidades. Si se encuentra dentro de ciertas políticas que establecemos y que deben ser aprobadas con desarrollo, entonces no la descargamos y se devuelve un mensaje para usar otra versión. Por lo tanto, si hay algo crítico y malo en la biblioteca, el desarrollador no obtendrá la biblioteca en la etapa de instalación; deberá usar una versión más alta o más baja.

Durante el build verifica que nadie haya introducido nada malo, que todos los componentes sean seguros y que nadie haya traído nada peligroso en una memoria USB.
En nuestro repositorio solo tenemos componentes confiables.
Durante el despliegue, verificamos una vez más el paquete en sí: war, jar, DL o imagen de Docker para asegurarnos de que cumple con la política.
Al salir a producción, monitoreamos lo que sucede en el entorno productivo: si aparecen o no vulnerabilidades críticas.

Análisis dinámico — DAST

Las herramientas de análisis dinámico son radicalmente diferentes de todo lo mencionado anteriormente. Es una imitación del comportamiento del usuario con la aplicación. Si es una aplicación web, enviamos solicitudes imitando el comportamiento del cliente, hacemos clic en los botones en la interfaz, enviamos datos falsos desde el formulario: comillas, paréntesis, símbolos en diferentes codificaciones, para observar cómo la aplicación funciona y gestiona datos externos.

Este mismo sistema permite verificar vulnerabilidades comunes en Open Source. Como DAST no sabe qué Open Source estamos utilizando, simplemente lanza patrones 'maliciosos' y analiza las respuestas del servidor:

— Ah, aquí hay un problema de deserialización, y aquí no.

Esto conlleva grandes riesgos, porque si realizas esta prueba de seguridad en el mismo entorno que utilizan los testers, pueden ocurrir cosas desagradables.

Alta carga en el servidor de la aplicación.
No hay integraciones.
Posibilidad de cambiar la configuración de la aplicación analizada.
No hay soporte para las tecnologías necesarias.
Complejidad de la configuración.

Tuvimos una situación en la que finalmente lanzamos AppScan: tardamos en obtener acceso a la aplicación, conseguimos 3 cuentas y nos alegramos: ¡por fin lo vamos a comprobar todo! Iniciamos el escaneo y lo primero que hizo AppScan fue acceder al panel de administración, pulsar todos los botones, cambiar la mitad de los datos y luego incluso acabar con el servidor por su cuenta. mailform-peticiones. El desarrollo junto con las pruebas dijeron:

— ¡Chicos, ¿están locos?! ¡Les dimos acceso, y ustedes arruinaron el entorno!

Tomen en cuenta los riesgos potenciales. Idealmente, preparen un entorno de prueba separado para seguridad de la información que esté aislado de todo lo demás al menos de alguna manera, y es recomendable verificar el panel administrativo manualmente. Esta es una prueba de penetración: esos restos de esfuerzo que ahora no estamos considerando.

Hay que tener en cuenta que se puede usar esto como un análogo a las pruebas de carga. En la primera fase, se puede activar un escáner dinámico en 10-15 flujos y ver qué sucede, pero generalmente, como muestra la práctica, no suele resultar en nada bueno.

Algunos recursos que utilizamos normalmente.

Vale la pena destacar Burp Suite es el "cuchillo suizo" de cualquier especialista en seguridad. Todos lo usan y es muy cómodo. Ahora ha salido una nueva versión demo de la edición empresarial. Antes era simplemente una herramienta independiente con complementos, pero ahora finalmente los desarrolladores están creando un gran servidor desde el cual se podrán gestionar múltiples agentes. Es genial, lo recomiendo.

Integración en el proceso

La integración se realiza de manera bastante fluida y sencilla: iniciar el escaneo tras la instalación exitosa de la aplicación en el entorno y escaneo tras la realización exitosa de las pruebas de integración.

Si las integraciones no funcionan o hay colocaciones y funciones simuladas, esto es inútil y sin valor: sea cual sea el patrón que enviemos, el servidor seguirá respondiendo de la misma manera.

Lo ideal sería tener un entorno separado para las pruebas.
Antes de comenzar las pruebas, anoten la secuencia de inicio de sesión.
Las pruebas del sistema de administración deben ser manuales únicamente.

El proceso

Un poco de forma general sobre el proceso en general y sobre el funcionamiento de cada herramienta, en particular. Todas las aplicaciones son diferentes: en una funciona mejor el análisis dinámico, en otra el estático, en una tercera el análisis de código abierto, pruebas de penetración o incluso algo completamente diferente, como eventos con. Waf.

Cada proceso necesita control.

Para entender cómo funciona el proceso y dónde se puede mejorar, es necesario recopilar métricas de todo lo que se pueda, incluyendo métricas de producción, métricas de herramientas y de rastreadores de defectos.

Cualquier dato es útil. Es necesario observar en diferentes dimensiones dónde se aplica mejor cada herramienta y dónde el proceso falla en particular. Tal vez valga la pena analizar el tiempo de respuesta del desarrollo para entender dónde mejorar el proceso basado en el tiempo. Cuantos más datos haya, más dimensiones se pueden construir, desde niveles altos hasta detalles de cada proceso.

Dado que cada analizadores estáticos y dinámicos tiene su propia API, sus propios métodos de ejecución, principios, algunos tienen programadores, otros no, estamos desarrollando una herramienta Orquestador de AppSec, que permite crear un único punto de entrada en todo el proceso de fabricación y gestionarlo desde un solo lugar.

Los gerentes, desarrolladores e ingenieros de seguridad tienen un punto de entrada desde el cual se puede ver qué está en ejecución, configurar y comenzar el escaneo, obtener resultados del escaneo y presentar requerimientos. Intentamos alejarnos de los documentos, traduciendo todo a un lenguaje accesible que utiliza el desarrollo: páginas en Confluence con estados y métricas, defectos en Jira o en diferentes rastreadores de defectos, o integrarlo en un proceso sincrónico/asíncrono en CI/CD.

Puntos Clave

Las herramientas no son lo principal. Primero pensar en el proceso y luego implementar herramientas. Las herramientas son buenas, pero costosas, por lo que se puede comenzar con el proceso y establecer interacción y entendimiento entre el desarrollo y la seguridad. Desde el punto de vista de la seguridad, no es necesario "detener" todo, desde el punto de vista del desarrollo, si hay algo altamente crítico, debe ser abordado y no ignorado.

Calidad del producto — un objetivo común tanto para la seguridad como para el desarrollo. Hacemos lo mismo, nos esforzamos para que todo funcione correctamente y no haya riesgos reputacionales ni pérdidas financieras. Por eso promovemos un enfoque de DevSecOps, SecDevOps, para establecer comunicación y hacer el producto de mayor calidad.

Comience con lo que ya existe: requisitos, arquitectura, verificaciones parciales, entrenamientos, guías. No es necesario aplicar todas las prácticas de inmediato en todos los proyectos — avancen de manera iterativa. No hay un estándar único — experimente y pruebe diferentes enfoques y soluciones.

Entre los defectos en seguridad de la información y los defectos funcionales hay un signo de igualdad.

Automatice todo, lo que se mueve. Todo lo que no se mueve, muévalo y automatícelo. Si algo se hace manualmente, no es una buena parte del proceso. Quizás valga la pena revisarlo y también automatizarlo.

Si el tamaño del equipo de seguridad de la información es pequeño — utilice Champions de Seguridad.

Es posible que lo que he mencionado no sea adecuado para usted y que invente algo propio — y eso está bien. Pero elija herramientas según los requisitos de su propio proceso. No preste atención a lo que dice la comunidad, que esta herramienta es mala y aquella es buena. Puede que en su producto sea todo lo contrario.

Requisitos para las herramientas.

Bajo nivel de falsos positivos.
Tiempo de análisis adecuado.
Facilidad de uso.
Disponibilidad de integraciones.
Comprensión de la hoja de ruta del desarrollo del producto.
Capacidad de personalización de las herramientas.

La presentación de Yuri fue seleccionada como una de las mejores en DevOpsConf 2018. Para conocer más ideas interesantes y casos prácticos, venga el 27 y 28 de mayo a Skolkovo en DevOpsConf el marco de el festival RIT++. Y aún mejor, si está dispuesto a compartir su experiencia, entonces envíe su solicitud para la presentación hasta el 21 de abril.

Fuente: habr.com