Teníamos 2 analizadores de código, 4 herramientas de pruebas dinámicas, nuestras propias artesanías y 250 scripts. No es que todo esto fuera necesario en el proceso actual, pero una vez que comenzó a implementar DevSecOps, debe llegar al final.
. Personajes creados por Justin Roiland y Dan Harmon.
¿Qué es SecDevOps? ¿Qué pasa con DevSecOps? ¿Cuáles son las diferencias? Seguridad de aplicaciones: ¿de qué se trata? ¿Por qué el enfoque clásico ya no funciona? Todas estas preguntas saben la respuesta. Yuri Shabalin de Seguridad del pez espada. Yuriy responderá todo en detalle y analizará los problemas de la transición del modelo clásico de seguridad de aplicaciones al proceso DevSecOps: cómo abordar adecuadamente la integración del proceso de desarrollo seguro en el proceso DevOps y no romper nada, cómo pasar por las etapas principales de pruebas de seguridad, qué herramientas se pueden usar, en qué se diferencian y cómo configurarlas correctamente para evitar errores.
Acerca del altavoz: Yuri Shabalin - Arquitecto Jefe de Seguridad en la empresa Seguridad del pez espada. Responsable de la implementación de SSDL, para la integración general de las herramientas de análisis de aplicaciones en un solo ecosistema de desarrollo y prueba. 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 congresos internacionales ZerONights, PHDays, RISSPA, OWASP.
Seguridad de aplicaciones: ¿de qué se trata?
Seguridad de las aplicaciones es la sección de seguridad que se encarga de la seguridad de la aplicación. No se trata de la infraestructura o la seguridad de la red, sino de lo que escribimos y en lo que trabajan los desarrolladores: estas son las fallas y vulnerabilidades de la aplicación en sí.
dirección - Ciclo de vida del desarrollo de seguridad - Desarrollado por Microsoft. El diagrama muestra el modelo SDLC canónico, 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 producción. Microsoft se dio cuenta de que hay demasiados errores en el prom, hay más y hay que hacer algo al respecto, y propuso este enfoque, que se volvió canónico.
Application Security y SSDL no tienen como objetivo detectar vulnerabilidades, como comúnmente se cree, sino prevenir su ocurrencia. Con el tiempo, el enfoque canónico de Microsoft se ha mejorado, desarrollado, tiene una inmersión más profunda y detallada.
El SDLC canónico es muy detallado en varias metodologías: OpenSAMM, BSIMM, OWASP. Las metodologías difieren, pero en general son similares.
Seguridad del edificio en el modelo de madurez
me gusta mas BSIMM - . 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 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: principiante, intermedio y avanzado. Puede estudiar las 12 prácticas en secciones, seleccionar cosas que son importantes para usted, descubrir 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. Elabora un plan y trabaja de acuerdo con él con calma como parte de la implementación de las actividades seleccionadas.
¿Por qué DevSecOps?
DevOps es un gran proceso general en el que se debe cuidar la seguridad.
Inicialmente controles de seguridad involucrados. En la práctica, el número de equipos de seguridad era mucho menor que ahora, y actuaban no como partícipes del proceso, sino como un órgano de control y vigilancia que lo exige y comprueba la calidad del producto al final de la liberación. Este es un enfoque clásico en el que los equipos de seguridad estaban detrás de un muro de desarrollo y no participaron en el proceso.
El principal problema es que la seguridad de la información está separada del desarrollo. Por lo general, este es algún tipo de circuito IB y contiene 2-3 herramientas grandes y costosas. Una vez cada seis meses llega el código fuente o aplicación para ser probado, y una vez al año . Todo esto lleva al hecho de que las fechas de lanzamiento para la industria se posponen y una gran cantidad de vulnerabilidades de las herramientas automatizadas recaen sobre el desarrollador. Es imposible desmontar y reparar todo esto, porque incluso en los seis meses anteriores no se desmontaron los resultados, y aquí hay un nuevo lote.
En el curso del trabajo de nuestra empresa, vemos que la seguridad en todas las áreas e industrias entiende que es hora de ponerse al día y girar con el desarrollo en una rueda: en . El paradigma DevSecOps encaja perfectamente en la metodología de desarrollo ágil, implementación, soporte y 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 la seguridad es "proceso". Debe comprender esto antes de pensar en comprar herramientas.
No basta con incluir herramientas en el proceso DevOps: la comunicación y la comprensión entre los participantes del proceso son importantes.
Las personas son más importantes que las herramientas.
A menudo, la planificación de un proceso de desarrollo seguro comienza con la elección y compra de una herramienta y termina con los 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 es cuando el departamento de seguridad eligió una herramienta buena y costosa con una amplia gama de funciones y acudió a los desarrolladores para incorporarla en el proceso. Pero no funciona: el proceso está diseñado de tal manera que las limitaciones de un instrumento ya comprado no se ajustan al paradigma actual.
Primero, describa qué resultado desea y cómo será 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 caras, mire lo que ya tiene. Cada empresa tiene requisitos de seguridad que se aplican al desarrollo, hay controles, pruebas de penetración, ¿por qué no transformar todo esto en una forma comprensible y conveniente para todos?
Por lo general, los requisitos son un Talmud en papel que se encuentra en un estante. Hubo un caso en el que acudimos a la empresa para ver los procesos y pedirles que mostraran 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 un camino donde se encuentra este documento.
Como resultado, recibimos el documento una semana después.
Para requisitos, cheques y más, cree una página, por ejemplo en Confluencia - es conveniente para todos.
Es más fácil reformatear lo que ya está allí y usarlo para comenzar.
Usar campeones de seguridad
Por lo general, en una empresa promedio de 100 a 200 desarrolladores, hay un oficial de seguridad que realiza varias funciones y no tiene tiempo físico 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 es una persona dentro del equipo de desarrollo que está interesada en la seguridad de su producto.
Security Champion es un punto de entrada al equipo de desarrollo y un evangelista de seguridad, todo en uno.
Por lo general, cuando un oficial de seguridad llega al equipo de desarrollo y señala un error en el código, recibe una respuesta sorprendida:
- ¿Y quien eres tu? Te veo por primera vez. Todo está bien conmigo: mi amigo mayor puso "aplicar" en la revisión del código, ¡seguimos adelante!
Esta es una situación típica, porque hay mucha más confianza en las personas mayores o simplemente en los compañeros de equipo con los que el desarrollador interactúa constantemente en el trabajo y en la revisión del código. Si, en lugar de un guardia de seguridad, el Security Champion señala el error y las consecuencias, entonces su palabra tendrá más peso.
Además, los desarrolladores conocen su código mejor que cualquier tipo de seguridad. Para una persona que tiene al menos 5 proyectos en una herramienta de análisis estático, suele ser difícil recordar todos los matices. Los campeones de la seguridad conocen su producto: qué interactúa con qué y qué mirar en primer lugar: son más eficientes.
Así que considere 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, ampliar los horizontes técnicos, impulsar las habilidades técnicas, de gestión y de liderazgo, aumentar el valor de mercado. Este es un elemento de ingeniería social, sus "ojos" en el equipo de desarrollo.
Etapas de prueba
dice que el 20% de los esfuerzos dan el 80% de los resultados. Este 20% son prácticas de análisis de aplicaciones que pueden y deben ser automatizadas. Ejemplos de tales actividades son el análisis estático: El domingo, análisis dinámico — RÁPIDO, и control de código abierto. Te contaré más sobre las actividades, así como sobre las herramientas, qué características solemos encontrar cuando se introducen en el proceso y cómo hacerlo correctamente.
Principales problemas de la herramienta
Destacaré los problemas que son relevantes para todos los instrumentos que requieren atención. Los analizaré con más detalle para no repetir más.
Largo tiempo de análisis. Si se tardan 30 minutos desde la confirmación hasta el lanzamiento para todas las pruebas y el ensamblaje, las comprobaciones de seguridad de la información tardarán un día. Así nadie ralentizará 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 codificación. En diferentes bases de código y tecnologías, las herramientas pueden mostrar diferentes niveles de Falso Negativo y Falso Positivo. Así que mira lo que hay su empresas y para su las aplicaciones mostrarán un resultado bueno y confiable.
Sin integraciones con herramientas existentes. Mire las herramientas en términos de integraciones con lo que ya usa. Por ejemplo, si tienes Jenkins o TeamCity, revisa la integración de herramientas con este software, y no con GitLab CI, que no usas.
Falta o excesiva complejidad de personalización. Si la herramienta no tiene una API, ¿por qué es necesaria? Todo lo que se pueda hacer en la interfaz debería estar disponible a través de la API. Idealmente, la herramienta debería tener la capacidad de personalizar los cheques.
Sin hoja de ruta de 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 admita nuevos marcos y tecnologías. Por lo tanto, es importante saber que el producto tiene un verdadero y correcto desarrollo
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 los plazos de desarrollo y lanzamiento, cree reglas diferentes y diferente Mostrar tapones - criterios para detener el proceso de construcción en presencia de vulnerabilidades - para diferentes ambientes. Por ejemplo, entendemos que la sucursal actual va a un stand de desarrollo o UAT, por lo que no nos detenemos y decimos:
- ¡Tienes vulnerabilidades aquí, no irás a ningún lado más!
En este punto, es importante decirles a los desarrolladores que hay problemas de seguridad que deben tener en cuenta.
La presencia de vulnerabilidades no es una barrera para realizar más pruebas.: manual, integración o manual. Por otro lado, necesitamos mejorar de alguna manera la seguridad del producto, y que los desarrolladores no puntúen en lo que encuentra la 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, por favor 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, les advertimos varias veces, no hicieron nada, no los dejaremos salir con esto.
Si hablamos de código y dinámica, entonces es necesario mostrar y advertir sobre las vulnerabilidades solo de aquellas funciones y el código que se acaba de escribir en esta función. Si el desarrollador movió el botón 3 píxeles y le decimos que tiene una inyección de SQL allí y, por lo tanto, necesita una reparación urgente, esto está mal. Fíjate solo en lo que está escrito ahora, y en el cambio que viene a la aplicación.
Digamos que tenemos algún 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. Defectos de seguridad - estos 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 Mansur, 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 archivos PDF aterradores 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 me puse manos a la obra. Los grandes informes son informes muertos. Por lo general, no van a ninguna parte, los correos electrónicos se eliminan, se olvidan, se pierden o la empresa dice que está tomando riesgos.
¿Qué hacer? Simplemente convertimos los defectos confirmados que encontramos en una forma conveniente para el desarrollo, por ejemplo, los agregamos a la cartera de pedidos en Jira. Los defectos se priorizan y eliminan en orden de prioridad junto con los defectos funcionales y los 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 los patrones o el estilo. El análisis utiliza varios enfoques: por árbol de vulnerabilidad, por , analizando los archivos de configuración. Eso es todo por el código en sí.
Ventajas del enfoque: identificar vulnerabilidades en el código en una etapa temprana de desarrollocuando no hay soportes y herramientas listas para usar, y capacidad de escaneo incremental: escanea una sección de código que ha cambiado, y solo la función que estamos haciendo actualmente, lo que reduce el tiempo de escaneo.
Contras es la falta de soporte para los idiomas requeridos.
integraciones requeridas, que debería 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 un desarrollador no subirse a una interfaz incomprensible que aún debe recordarse, sino ver todas las integraciones y vulnerabilidades necesarias que ha encontrado en el lugar de trabajo en su propio entorno de desarrollo.
- 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.
No son las herramientas lo que importa, 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 pueden y deben usarse al construir un proceso. Ayudan a comprender cómo se construirá el proceso, quién responderá a los errores, quién informará, quién informará. Si quieres llevar a cabo la etapa inicial de construcción de la seguridad de tu código, utiliza soluciones Open Source.
¿Cómo se puede integrar esto si estás al comienzo del viaje, no tienes nada: ni CI, ni Jenkins, ni TeamCity? Considere la integración de procesos.
Integración a nivel de CVS
Si tiene Bitbucket o GitLab, puede hacer la integración a nivel .
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 pasó o falló.
Retroalimentación Por supuesto, la retroalimentación siempre es necesaria. Si solo lo hizo por el lado de la seguridad, lo puso en una caja y no le dijo a nadie nada al respecto, y luego arrojó un montón de errores a fin de mes, esto no es correcto ni bueno.
Integración con el sistema de revisión de código
Una vez, configuramos al usuario técnico de AppSec como el revisor predeterminado en varios proyectos importantes. Dependiendo de si se encontraron errores en el nuevo código o si no hay errores, el revisor coloca el estado en la solicitud de extracción en "aceptar" o "necesita trabajo": todo está bien o debe finalizar y vincular a qué exactamente finalizar. Para la integración con la versión que se está lanzando, hemos deshabilitado la combinación si no se pasa la prueba IS. Incluimos esto en la revisión manual del código, y el resto de los participantes del proceso vieron los estados de seguridad para este proceso en particular.
Integración con SonarQube
muchos tienen en términos de calidad de código. Es lo mismo aquí: puede hacer las mismas puertas solo para instrumentos SAST. Habrá la misma interfaz, la misma puerta de calidad, solo que se llamará puerta de seguridad. Y además, si tienes un proceso configurado con SonarQube, puedes integrar todo allí fácilmente.
Integración a nivel de CI
Aquí, también, todo es bastante simple:
- A la par con las pruebas automáticas, pruebas unitarias.
- División por etapas de desarrollo: desarrollo, prueba, prod. Se pueden incluir diferentes conjuntos de reglas o diferentes condiciones de falla: detenemos el ensamblaje, no detenemos el ensamblaje.
- Ejecución sincrónica/asincrónica. Estamos esperando el final de las pruebas de seguridad o no estamos esperando. Es decir, simplemente los lanzamos y seguimos adelante, y luego obtenemos un estado de que todo es bueno o malo.
Todo está en un mundo rosa perfecto. En la vida real, este no es el caso, pero nos esforzamos. El resultado de realizar 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 - OK. Empujamos este proyecto a SAST, nos dio 20 vulnerabilidades y tomamos la decisión de que todo está bien. 000 vulnerabilidades es nuestra deuda técnica. Pondremos la deuda en una caja, la recogeremos lentamente e iniciaremos errores en los rastreadores de defectos. Contrate a una empresa, hagamos todo nosotros mismos o deje que los campeones de seguridad nos ayuden, y la deuda técnica disminuirá.
Y todas las vulnerabilidades que aparezcan en el nuevo código deben eliminarse de la misma manera que los errores en una unidad o en las pruebas automáticas. Relativamente hablando, la asamblea comenzó, se alejó, dos pruebas y dos pruebas de seguridad cayeron. OK, fuimos, miramos lo que sucedió, corregimos uno, corregimos el segundo, condujimos la próxima vez: todo está bien, no aparecieron nuevas vulnerabilidades, las pruebas no fallaron. Si esta tarea es más profunda y necesita comprenderla bien, o si la reparación de vulnerabilidades afecta a grandes capas de lo que se encuentra debajo del capó: se introduce un error en el rastreador de defectos, se prioriza y se corrige. 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, en términos de presencia y número 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
Opciones de integración:
- Iniciar un escaneo desde el entorno de desarrollo incluso antes de la confirmación.
- Ver resultados.
- Análisis de los resultados.
- Sincronización con el servidor.
Así es como se ve obtener resultados del servidor.
En nuestro entorno de desarrollo simplemente aparece un elemento adicional que dice que dichas vulnerabilidades se encontraron durante el análisis. Puede editar inmediatamente el código, ver recomendaciones y . Todo esto se encuentra en el lugar de trabajo del desarrollador, lo cual es muy conveniente: no necesita seguir el resto de los 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 muletas y bicicletas cuando puede tomar una biblioteca lista para usar en la que todo ya está implementado?
Por supuesto, esto es cierto, pero las bibliotecas también están escritas por personas, también incluyen ciertos riesgos y también hay vulnerabilidades que se informan periódicamente o constantemente. Por lo tanto, hay un siguiente paso en la seguridad de las aplicaciones: este es el análisis de los componentes de código abierto.
Análisis de código abierto - OSA
La herramienta incluye tres pasos principales.
Encontrar vulnerabilidades en bibliotecas. Por ejemplo, la herramienta sabe que estamos usando algún tipo de biblioteca, y que en o en los rastreadores de errores hay algunas vulnerabilidades relacionadas con esta versión de la biblioteca. Si intenta usarla, la herramienta le advertirá que la biblioteca es vulnerable y le aconsejará que use otra versión donde no haya vulnerabilidades.
Análisis de pureza de la licencia. Esto no es muy popular entre nosotros todavía, pero si trabaja con un país extranjero, allí puede recibir periódicamente un ataque por usar un componente de código abierto que no se puede usar ni modificar. De acuerdo con la política de la biblioteca con licencia, no podemos hacer esto. O, si lo hemos modificado y lo usamos, debemos publicar nuestro código. Por supuesto, nadie quiere publicar el código de sus productos, pero también puedes protegerte de esto.
Análisis de componentes que se utilizan en un entorno industrial. Imagine una situación hipotética en la que finalmente hayamos completado el desarrollo y lanzado la última versión de nuestro microservicio a la industria. Vive allí maravillosamente: una semana, un mes, un año. No lo recopilamos, no realizamos controles de seguridad, todo parece estar bien. Pero de repente, dos semanas después del lanzamiento, surge una vulnerabilidad crítica en el componente Open Source, que usamos en este ensamblaje en particular, en el entorno industrial. Si no registramos qué y dónde usamos, entonces esta vulnerabilidad simplemente no se verá. Algunas herramientas tienen la capacidad de monitorear vulnerabilidades en bibliotecas que se usan actualmente en prom. Es muy útil.
Características:
- Diferentes políticas para diferentes etapas de desarrollo.
- Supervisión de componentes en un entorno industrial.
- Control de bibliotecas en el contorno de la organización.
- Soporte para varios sistemas de compilación e idiomas.
- Análisis de imágenes Docker.
Algunos ejemplos de líderes en el campo que se dedican al análisis de Open Source.
El único gratuito es de OWASP. Puede encenderlo en las primeras etapas, ver cómo funciona y qué admite. Básicamente, estos son todos productos en la nube, o en las instalaciones, pero detrás de su base todavía van a Internet. No envían sus librerías, sino hashes o sus valores que ellos mismos calculan, y huellas dactilares a su servidor para recibir noticias de la presencia de vulnerabilidades.
Integración de procesos
Control de biblioteca perimetralque se descargan de fuentes externas. Contamos con repositorios externos e internos. Por ejemplo, tenemos Nexus dentro de Event Central y queremos asegurarnos de que no haya vulnerabilidades con un estado "crítico" o "alto" dentro de nuestro repositorio. Puede configurar el uso de proxy con la herramienta Nexus Firewall Lifecycle para eliminar dichas vulnerabilidades y no incluirlas en el repositorio interno.
integración de CI. Al mismo nivel que las autopruebas, las pruebas unitarias y la división en etapas de desarrollo: dev, test, prod. En cada etapa, puede descargar cualquier biblioteca, usar cualquier cosa, pero si hay algo difícil con el estado "crítico", probablemente debería llamar la atención de los desarrolladores sobre esto en la etapa de ingreso al prom.
Integración de artefactos: Nexus y JFrog.
Integración en el entorno de desarrollo. Las herramientas que elija deben tener integración con entornos de desarrollo. El desarrollador debe tener acceso a los resultados del escaneo desde su lugar de trabajo, o la capacidad de escanear y verificar el código en busca de vulnerabilidades antes de enviarlo a CVS.
Integración de CD. Esta es una función genial que me gusta mucho y de la que ya he hablado: monitorear la aparición de nuevas vulnerabilidades en un entorno industrial. Funciona así.
Tenemos Repositorios de componentes públicos - algunas herramientas externas y nuestro repositorio interno. Queremos que solo haya componentes confiables en él. Al enviar una solicitud por proxy, verificamos que la biblioteca descargada no tenga vulnerabilidades. Si cae bajo ciertas políticas que establecemos y necesariamente coordinamos con el desarrollo, entonces no lo subimos y recibimos un rechazo para usar una versión diferente. En consecuencia, si hay algo realmente crítico y malo en la biblioteca, entonces el desarrollador no recibirá la biblioteca incluso en la etapa de instalación; déjelo usar una versión superior o inferior.
- Al construir, verificamos que nadie haya deslizado nada malo, que todos los componentes estén seguros y que nadie haya traído nada peligroso en la memoria USB.
- Solo tenemos componentes de confianza en el repositorio.
- Al implementar, una vez más verificamos el paquete en sí: war, jar, DL o Docker image para verificar que cumpla con la política.
- Al ingresar al entorno industrial, monitoreamos lo que sucede en el entorno industrial: las vulnerabilidades críticas aparecen o no aparecen.
Análisis dinámico - DAST
Las herramientas de análisis dinámico son fundamentalmente diferentes de todo lo que se ha dicho antes. Este es un tipo de imitación del trabajo del usuario con la aplicación. Si se trata de una aplicación web, enviamos solicitudes imitando el trabajo del cliente, haga clic en los botones en el frente, envíe datos artificiales del formulario: comillas, corchetes, caracteres en diferentes codificaciones para ver cómo funciona la aplicación y procesos externos datos.
El mismo sistema le permite verificar las vulnerabilidades de las plantillas en Open Source. Dado que DAST no sabe qué Open Source estamos usando, simplemente arroja patrones "maliciosos" y analiza las respuestas del servidor:
- Sí, aquí hay un problema de deserialización, pero no aquí.
Hay grandes riesgos en esto, porque si realiza esta prueba de seguridad en el mismo soporte con el que trabajan los evaluadores, pueden suceder cosas desagradables.
- Alta carga en la red del servidor de aplicaciones.
- Sin integraciones.
- La capacidad de cambiar la configuración de la aplicación analizada.
- No hay soporte para las tecnologías requeridas.
- Dificultad de montaje.
Tuvimos una situación cuando finalmente lanzamos AppScan: bloqueamos el acceso a la aplicación durante mucho tiempo, recibimos 3 cuentas y quedamos encantados. ¡Finalmente, revisaremos todo! Lanzamos un escaneo, y lo primero que hizo AppScan fue ingresar al panel de administración, perforar todos los botones, cambiar la mitad de los datos y luego eliminar el servidor por completo con su propio -peticiones. Desarrollo con Testing dijo:
“Chicos, ¿están bromeando? ¡Te dábamos cuentas, y tú ponías el estrado!
Considere los posibles riesgos. Idealmente, prepare un stand separado para probar la seguridad de la información, que estará aislado del resto del entorno al menos de alguna manera, y verifique condicionalmente el panel de administración, preferiblemente en modo manual. Este es un pentest: esos porcentajes restantes de esfuerzos que no estamos considerando ahora.
Vale la pena considerar que puede usar esto como un análogo de la prueba de carga. En la primera etapa, puede activar el escáner dinámico en 10-15 subprocesos y ver qué sucede, pero generalmente, como muestra la práctica, nada bueno.
Unos recursos que solemos utilizar.
Vale la pena destacar es la "navaja suiza" para cualquier profesional de la seguridad. Todos lo usan y es muy conveniente. Se ha lanzado una nueva versión de demostración de la edición empresarial. Si antes era solo una utilidad independiente con complementos, ahora los desarrolladores finalmente están creando un gran servidor desde el cual será posible administrar varios agentes. Es genial, te recomiendo que lo pruebes.
Integración de procesos
La integración es bastante buena y simple: comience a escanear después de una instalación exitosa aplicaciones en el stand y escaneo después de una prueba de integración exitosa.
Si las integraciones no funcionan o hay stubs y funciones simuladas, no tiene sentido ni sirve; no importa qué patrón enviemos, el servidor seguirá respondiendo de la misma manera.
- Idealmente, un banco de pruebas separado.
- Antes de realizar la prueba, anote la secuencia de inicio de sesión.
- La prueba del sistema de administración es solo manual.
proceso
Un poco generalizado sobre el proceso en general y sobre el trabajo de cada herramienta, en particular. Todas las aplicaciones son diferentes: una funciona mejor con análisis dinámico, otra con análisis estático, la tercera con análisis OpenSource, pentests o algo más en general, por ejemplo, eventos con .
Cada proceso necesita ser controlado.
Para comprender cómo funciona el proceso y dónde se puede mejorar, debe recopilar métricas de todo lo que pueda tener en sus manos, incluidas las métricas de producción, las métricas de las herramientas y los rastreadores de defectos.
Cualquier información es útil. Es necesario mirar en varias secciones dónde se usa mejor esta o aquella herramienta, dónde el proceso específicamente se hunde. Puede valer la pena mirar el tiempo de respuesta del desarrollo para ver dónde mejorar el proceso en función del tiempo. Cuantos más datos, más cortes se pueden construir desde el nivel superior hasta los detalles de cada proceso.
Dado que todos los analizadores estáticos y dinámicos tienen sus propias API, sus propios métodos de lanzamiento, principios, algunos tienen planificadores, otros no, estamos escribiendo una herramienta Orquestador de AppSec, que permite hacer un único punto de entrada a todo el proceso desde el producto y gestionarlo desde un único punto.
Los administradores, desarrolladores e ingenieros de seguridad tienen un punto de entrada desde el cual pueden ver lo que se está ejecutando, configurar y ejecutar análisis, obtener resultados de análisis y enviar requisitos. Intentamos alejarnos de los pedazos de papel, traducir todo a uno humano que usa el desarrollo: páginas en Confluence con estado y métricas, defectos en Jira o en varios rastreadores de defectos, o incrustarlos en un proceso síncrono/asincrónico en CI/CD.
Puntos clave
Las herramientas no importan. Primero piense en el proceso, luego implemente las herramientas. Las herramientas son buenas, pero costosas, por lo que puede comenzar con el proceso y ajustar la interacción y la comprensión entre el desarrollo y la seguridad. Desde el punto de vista de la seguridad, no hay necesidad de "parar" todo de una vez, desde el punto de vista del desarrollo, si hay algo alto mega súper crítico, entonces esto debe eliminarse y no cerrarse al problema. .
Calidad del producto - meta común tanto de seguridad como de desarrollo. Hacemos una cosa, tratamos de asegurarnos de que todo funcione correctamente y no haya riesgos reputacionales y pérdidas financieras. Por eso promovemos el acercamiento a DevSecOps, SecDevOps con el fin de establecer comunicación y mejorar el producto.
Comience con lo que ya está allí: requisitos, arquitectura, verificaciones parciales, capacitaciones, lineamientos. No es necesario aplicar inmediatamente todas las prácticas a todos los proyectos - moverse iterativamente. No hay un estándar único experimento y probar diferentes enfoques y soluciones.
Signo igual entre defectos IS y defectos funcionales.
Automatice todoque se está moviendo Cualquier cosa que no se mueva, muévete y automatízate. Si algo se hace a mano, esta no es una buena parte del proceso. Quizás valga la pena reconsiderarlo y automatizarlo también.
Si el tamaño del equipo del IB es pequeño, usar campeones de seguridad.
Tal vez lo que hablé no te convenga y se te ocurra algo propio, y eso es bueno. Pero elegir herramientas en función de los requisitos de su proceso. No mires lo que dice la comunidad de que esta herramienta es mala y esta es buena. Tal vez sea al revés en su producto.
Requisitos de la herramienta.
- Bajo Falso Positivo.
- Tiempo de análisis adecuado.
- Facilidad de uso.
- Disponibilidad de integraciones.
- Comprensión de la hoja de ruta de desarrollo de productos.
- Posibilidad de personalizar herramientas.
El informe de Yuriy fue elegido como uno de los mejores en DevOpsConf 2018. Para familiarizarse con ideas y casos prácticos aún más interesantes, venga a Skolkovo el 27 y 28 de mayo. dentro . Aún mejor, si está dispuesto a compartir su experiencia, entonces Envíe su informe antes del 21 de abril.
Fuente: habr.com