Los servicios fuzzing ayudan a impulsar la tecnología en DevOps …



Como parte de un enfoque de prueba continuo, el fuzzing ha evolucionado para proporcionar comprobaciones de código en profundidad para detectar vulnerabilidades desconocidas antes de la implementación.

A medida que las empresas han cambiado la seguridad a la izquierda, la implementación de más controles de seguridad en la línea de desarrollo, las pruebas de fuzz o «fuzzing» ha continuado en gran medida fuera del ciclo de vida de desarrollo de application principal.

Este año, eso parece haber cambiado. La empresa de ciclo de vida de DevOps, GitLab, anunció en junio que la empresa había adquirido dos organizaciones, Peach Train y Fuzzit, para reforzar sus propias capacidades proporcionando un protocolo fuzzing continuo y periódico. La semana pasada, la empresa de infraestructura de World-wide-web Cloudflare anunció que utilizaría el fuzzer Mayhem de ForAllSecure, una startup automatizada de ciberseguridad, como parte de su ciclo de vida de desarrollo de application.

Si se hace correctamente, el fuzzing encaja bien en el modelo DevOps, también conocido como modelo de implementación continua de integración continua (CICD), dice Jeff Whalen, vicepresidente de producto de ForAllSecure.

«Fuzzing por su propia naturaleza es esta notion de pruebas continuas automatizadas», dice. «No se necesita mucha participación humana para obtener los beneficios de las pruebas de fuzz en su entorno. Se ajusta bien a la notion de automatización y pruebas continuas, junto con esta thought de desarrollo continuo».

Muchas empresas tienen como objetivo crear procesos de desarrollo de software ágiles, como DevOps. Debido a que este cambio a menudo requiere muchos ciclos iterativos, los métodos de prueba avanzados generalmente no reciben una alta prioridad. Las pruebas de fuzz, el proceso automatizado de enviar entradas aleatorias o creadas a la aplicación, es una de estas técnicas más complejas. Incluso dentro del panteón de las tecnologías de seguridad, el fuzzing se encuentra a menudo entre los últimos adoptados.

Sin embargo, 2020 puede ser el año que cambie. Los principales proveedores e incluso los marcos se han centrado en facilitar el fuzzing, dice David Haynes, ingeniero de seguridad de productos en Cloudflare.

«Creo que recién estamos comenzando en términos de ver que el fuzzing se vuelve un poco más común, porque el variable más importante que obstaculiza (su adopción) son las herramientas disponibles», dice. «La gente acepta que se necesitan pruebas de integración, se necesitan pruebas unitarias, se necesitan pruebas de extremo a extremo y ahora, se necesitan pruebas fuzz».

Agregar más pruebas a DevOps no siempre es fácil, especialmente cuando esas pruebas podrían bloquear el desarrollo. Si bien los ciclos CICD son una alta prioridad para muchas empresas, los desarrolladores de program continúan teniendo problemas para alcanzar un alto nivel de madurez. En 2019, el 43% de los profesionales del desarrollo de program calificaron su desarrollo como de alto rendimiento o de élite en DevOps, frente al 48% en 2018, según el grupo DevOps Analysis and Evaluation (DORA) de Google. Las empresas de alto rendimiento implementan código para una aplicación al menos una vez por semana, requieren menos de una semana para realizar cambios y pueden restaurar los servicios dentro de un día después de un incidente.

«La entrega continua no es fácil de hacer», dice Christopher Apartment, analista principal del grupo de desarrollo y entrega de aplicaciones de Forrester Investigate. «La entrega continua requiere automatización en todos los niveles, pero no solo la automatización de la entrega de computer software, las pruebas de funciones y la gestión de la infraestructura y las versiones, sino también la automatización del cumplimiento y la automatización de la gobernanza … Empresas que son muy reacias al riesgo y quieren tener muchos niveles de pruebas, eso lo hace aún más difícil «.

Agregar fuzzing a las empresas que luchan por refinar sus implementaciones de DevOps es un desafío. La tecnología de fuzzing básica, en la que el programa encuentra todas las entradas de la aplicación y luego envía datos aleatoriamente a esas entradas, conduce a un conjunto muy grande, a menudo infinito, de posibles entradas. Una clave crítica en el fuzzing es limitar el número de entradas, o la construcción de entradas, utilizadas para probar una aplicación, lo que cut down la complejidad del problema, dice Whalen de ForAllSecure.

«Existe este enorme espacio de pruebas negativas. ¿Qué sucede cuando una aplicación ve cosas que se supone que no debe ver o que no se espera que vea?» él dice. Sin embargo, enfatiza la necesidad de hacerlo bien. «Cuando se pasa a la arquitectura nativa de la nube, no necesariamente va a tener mucho regulate sobre qué (tipos de ataques) vendrán a la aplicación. Y ahí es donde el fuzzing funciona realmente, realmente bien».

Google está de acuerdo. El año pasado, la compañía lanzó su propio fuzzer, Cluster Fuzz, como un proyecto de código abierto. Como muchos fuzzers, el programa tiene como objetivo encontrar fallas de corrupción de memoria en software package que puedan ser explotadas por atacantes. Google ejecutó el sistema en un clúster de carga de trabajo masivo de 25.000 núcleos y lo ofreció como un servicio gratuito para proyectos de código abierto. La empresa lo acreditó con encontrar más de 16.000 errores en el navegador Chrome y más de 11.000 errores en una variedad de programas de código abierto.

«Para los proyectos de software escritos en un lenguaje inseguro como C o C ++, el fuzzing es una parte essential para garantizar su seguridad y estabilidad», Google declaró en su publicación de website. «Para que el fuzzing sea realmente efectivo, debe ser continuo, realizado a escala e integrado en el proceso de desarrollo de un proyecto de program».

Para facilitar la incorporación de pruebas fuzz en las canalizaciones de DevOps, las empresas deben utilizar conjuntos de pruebas más pequeños. La empresa de seguridad de application Synopsys, por ejemplo, señala que las empresas podrían ejecutar 9 millones de casos de prueba en la configuración completa para su plataforma de fuzzing, Defensics, o 700.000 en su configuración predeterminada. Adaptar la muestra de prueba a miles de casos puede significar que los desarrolladores ejecuten una prueba fuzz dentro del ciclo de DevOps y alertar a los desarrolladores sobre cualquier problema.

Al ultimate, el fuzzing sigue siendo complejo.

La máquina de fuzzing automatizada de ForAllSecure, Mayhem, por ejemplo, surgió de un proyecto de investigación en la Universidad Carnegie Mellon y se hizo un nombre en 2016 cuando ganó el evento Cyber ​​Grand Problem, un torneo de piratería de máquinas. Sin embargo, una invitación posterior al torneo anual DEF CON Capture the Flag demostró que incluso el mejor sistema en fuzzing de IA todavía tiene un largo camino por delante en el mundo de la ciberseguridad, cuando el sistema colocó último muerto en la clasificación de 15 equipos.

Podría decirse que tales sistemas de IA, que han derribado a los mejores jugadores de ajedrez, Jeopardy, póquer y Go, eventualmente también resolverán este problema. Tanto los sistemas defensivos como los ofensivos se benefician de la automatización, dice Alex Rebert, cofundador de ForAllSecure.

«Ya estamos viendo una creciente dependencia de las herramientas de automatización, tanto en el lado defensivo como en el ofensivo», dice. «En el lado ofensivo, todos los que conozco dependen en gran medida de herramientas como fuzzing para encontrar errores explotables».

A medida que las herramientas y los servicios de los desarrolladores incorporen fuzzing más fácil de usar, la seguridad del application se beneficiará. Incorporar experiencia en los servicios ayudará a los desarrolladores a saber cuándo usar fuzzing y cuándo confiar en otras tecnologías, dice David DeSanto, líder de proyectos técnicos e investigación de seguridad en GitLab.

«En mi carrera, he roto muchas cosas de la gente, y muchas veces es porque lideré con las pruebas de fuzz primero», dice. «Fuzzing solía ser un arte oscuro que solo los investigadores de seguridad y los piratas informáticos sabían utilizar. El objetivo es hacerlo accesible y fácil de entender».

Periodista tecnológico veterano de más de 20 años. Ex ingeniero de investigación. Escrito para más de dos docenas de publicaciones, incluidas CNET News.com, Dim Looking at, MIT&#39s Technologies Evaluation, Well-known Science y Wired News. Cinco premios de periodismo, incluido el de Mejor fecha límite … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia first