Dark deploys: los riesgos de trabajar por afuera de las políticas de seguridad
Mejores prácticas para evitar problemas en los proyectos de desarrollo que involucren herramientas de terceros, procesos no homologados o flujos de trabajo alternativos.
Por Luciano Moreira, Chief DevSecOps Strategy Officer (CDSO) de Cloud Legion.
Las presiones llegan desde todas las direcciones. Primero, el éxito de los negocios en la era digital dependen del software y las aplicaciones. Luego, las regulaciones se vuelven cada día más estrictas en lo que hace a la mitigación de vulnerabilidades de ciberseguridad.
Y, por último, el panorama de amenazas se hace más complejo, voluminoso y sofisticado: un informe reciente de Kaspersky, empresa especializada en soluciones para este segmento, calcula que las empresas latinoamericanas sufren 3,1 millones de ataques diarios. En simultáneo, otra compañía experta, Tenable, detectó que el 38% de las empresas tienen exposiciones tóxicas en la nube, esto es, que exponen públicamente cargas de trabajo claves con vulnerabilidades críticas.
Todo esto hace que la seguridad se haya convertido en una de las principales prioridades para cualquier equipo de desarrollo. Y si bien en muchos entornos ágiles DevOps existen procesos diseñados con medidas de seguridad integradas de extremo a extremo, en la práctica abundan lo que se conoce como “dark deploys”: procesos secundarios y flujos de trabajo alternativos que escapan a las políticas autorizadas y que tienen como objetivo simplificar el trabajo del día a día.
En simultáneo, los ciclos de desarrollo suelen incluir activos de terceros que ingresan al pipeline a través de repositorios de código fuente. Esto representa un riesgo y una apuesta: la empresa depende de la madurez que ese tercero tenga en materia de ciberseguridad y se podría estar almacenando código que no ofrece niveles de seguridad elevados y que expone a toda la organización a vulnerabilidades que están “fuera del radar”.
Una problemática adicional: muchas veces, diferentes equipos cuentan con prioridades, entornos de prueba y de desarrollo y presupuestos separados. En estos casos, lograr una uniformidad de políticas y estándares suele ser bastante dificultoso.
Los riesgos de los ‘dark deploys’: una amenaza oculta en los procesos de desarrollo
Los dark deploys habilitan riesgos como la “ejecución por pipeline envenenado” (PPE, por sus siglas en inglés): una vulnerabilidad que los atacantes pueden aprovechar para inyectar código malicioso en un proceso de ejecución. También, podría provocar una escalada de privilegios y una fuga de datos a partir de controles de accesos insuficientes basados en el pipeline.
La buena noticia: existen mejores prácticas para lidiar con esta problemática. Una de ellas es el uso de herramientas AST (application security testing, prueba de seguridad de aplicaciones), ideales para reportar riesgos, incrementar la evaluación del código y aumentar los controles.
A nivel organizacional también es necesario realizar algunas adaptaciones: algunas de las principales son regular el uso de servicios de terceros y restringirlo a aquellos que cumplan los controles de seguridad aprobados internamente, adoptar un enfoque de seguridad basado en plataformas que ofrezcan una visión única de todos los proyectos y de todos los equipos o limitar el acceso a recursos a grupos limitados.
Las amenazas crecen en número y en complejidad. Los equipos de desarrollo que tomen rápidamente cartas en el asunto y bloqueen los dark deploys estarán iluminando con seguridad y confianza, y de extremo a extremo, sus procesos de desarrollo de software.
