Filosofía de seguridad «shift-left» promueve la idea de que las organizaciones deben integrar los procesos de seguridad en las fases iniciales de diseño y desarrollo del ciclo de vida del software. Este ideal se fomenta intensamente en los programas de DevOps y DevSecOps como una forma de detectar problemas de calidad o seguridad desde el principio y corregirlos antes de que lleguen a producción, donde los impactos resultan más costosos. Con toda razón, muchas organizaciones han apostado plenamente por el «shift-left» para intentar obtener estos beneficios y ahorros de costes.
Un enfoque específico dentro del «shift-left» es la «seguridad de la canalización de compilación», que requiere que los equipos integren herramientas de seguridad en las canalizaciones de CI/CD y en los flujos de trabajo de desarrollo basados en Git. Asegurar estas canalizaciones requiere una variedad de herramientas de seguridad, como análisis de dependencias, análisis estático, análisis dinámico, validadores de esquemas, *fuzzers* y escáneres de vulnerabilidades. El tipo de herramienta necesaria varía según los artefactos que se muevan por la canalización, lo que deba compilarse y el destino de la entrega.
Las organizaciones suelen enfrentarse a dos dificultades en la seguridad de la canalización de compilación:
- La cobertura «completa» requiere obtener múltiples tipos de herramientas de pruebas de seguridad — Algunas organizaciones intentan reducir costes optando por herramientas de código abierto, ya sea parcial o totalmente. Las decisiones varían según el nivel de concienciación, los presupuestos de seguridad y la tolerancia al riesgo.
- Las herramientas deben estar integradas y automatizadas para servir a la canalización — No basta con escanear, encontrar problemas y generar un informe. El resultado final del escaneo de seguridad debe ser digerible y encajar dentro de los procesos de CI/CD.
Incluso si logra satisfacer estos requisitos, surgen otros problemas para las organizaciones con la visión miope de que asegurar la canalización de compilación es el objetivo final de una estrategia de seguridad de API.
El escaneo de vulnerabilidades está mercantilizado y tiene poco valor
Las herramientas de evaluación y gestión de vulnerabilidades (VA/VM) dominan el panorama en muchas organizaciones de seguridad. Este tipo de escaneo de red e infraestructura es extremadamente común, ya que se ha promovido como una mejor práctica de TI y seguridad durante décadas. Algunos proveedores de VA/VM afirman cubrir también las aplicaciones, pero normalmente se limitan a identificar vulnerabilidades en paquetes de software comercial o de código abierto. Estas herramientas también pueden ser útiles para identificar ciertos tipos de configuraciones erróneas en servidores o cargas de trabajo. Sin embargo, hacen poco por evaluar la seguridad de sus aplicaciones y API personalizadas. Es habitual ver el VA/VM como el enfoque estándar en los programas de seguridad en lugar de un enfoque formalizado de seguridad de aplicaciones con herramientas diseñadas específicamente, como las herramientas de pruebas de seguridad de aplicaciones (AST).
Si el VA/VM es la herramienta que le permite escanear la infraestructura de producción en busca de vulnerabilidades conocidas, el SCA es la herramienta que le permite escanear componentes para identificar dependencias externas vulnerables en el código fuente de la aplicación o en la infraestructura como código. Los escaneos de SCA pueden activarse como parte de las confirmaciones de código, ejecutarse como parte de las compilaciones, iniciarse durante la entrega (por ejemplo, al instanciar una carga de trabajo en contenedores) o ejecutarse continuamente en producción para detectar desviaciones. El SCA también se ha mercantilizado y se puede encontrar como capacidades integradas en suites de AST, incluido en ofertas basadas en Git como GitHub y GitLab, e incorporado en la miríada de ofertas de protección de cargas de trabajo. También existen abundantes alternativas de código abierto para SCA. Incluso si el SCA funciona solo como un verificador básico de dependencias, puede proporcionar una seguridad «suficientemente buena» para muchas organizaciones.
Escanear imágenes de contenedores o registros de contenedores en busca de vulnerabilidades publicadas y conocidas es trivial en comparación con el análisis en tiempo de ejecución y la detección de anomalías. Incluso las ofertas de protección de cargas de trabajo deben proporcionar escaneo continuo en tiempo de ejecución para ser beneficiosas. El escaneo de dependencias vulnerables no es solo un punto en el tiempo o un escaneo de canalización. La desviación del entorno es común en las «operaciones del día 2» y cuanto más tiempo viva una aplicación o su infraestructura de soporte. Si se adentra en el complejo mundo de las dependencias anidadas o transitivas, verificar si el código vulnerable es realmente explotable le llevará a un terreno complejo de análisis estático extendido, análisis dinámico, *fuzzing*, análisis en tiempo de ejecución y análisis de comportamiento.
Los problemas de seguridad van más allá de los CVE
Vulnerabilidades y exposiciones comunes (CVE) Los identificadores cubren vulnerabilidades conocidas en paquetes de software y hardware publicados. Estos tipos de problemas de seguridad son más fáciles de identificar mediante herramientas de escaneo. Las técnicas comunes incluyen escanear rangos de direcciones IP de red en busca de servicios a la escucha, consultar información de *banners* de servidores, identificar el software que se ejecuta en los hosts y evaluar los encabezados en las respuestas del servidor.
Enumeración de debilidades comunes (CWE) Los identificadores son categorías más amplias de debilidades en el software, lo cual es el sistema de clasificación más apropiado para problemas en aplicaciones y API desarrolladas internamente. Son menos conocidos pero también están definidos de forma más flexible, lo que significa que un problema determinado en su aplicación personalizada puede asignarse a múltiples identificadores CWE. Desafortunadamente, esto complica la puntuación de riesgos y el seguimiento de la corrección, pero es la realidad del desarrollo a medida. Incluso las organizaciones que compran más software del que crean terminan desarrollando código personalizado para integrar sistemas e intercambiar datos. CWE es la taxonomía más relevante para los tipos de problemas de seguridad que puede estar creando inadvertidamente mientras desarrolla o integra código. Si solo observa los CVE, está perdiendo de vista el panorama general.
Las dependencias vulnerables conocidas a las que hace referencia en el código o en la infraestructura como código se convierten en parte de sus cargas de trabajo en ejecución. Como resultado, la mayoría de las organizaciones terminan con una mezcla de CWE, CVE y más. Aunque estas son taxonomías bien definidas de MITRE y NIST, no cubren todo. También existe una latencia inherente en la notificación y divulgación de vulnerabilidades. Tampoco existe necesariamente una «solución» para la latencia de los informes de CVE. Es un subproducto del proceso de autoinforme, el tiempo medio de detección de problemas, los acuerdos de divulgación coordinada de vulnerabilidades y la logística de coordinación de las partes responsables.
Los oscuros secretos de AST
Hay un problema evidente del que nadie quiere hablar cuando se trata de las limitaciones de las herramientas AST:
Las herramientas de análisis estático y dinámico no pueden detectar fallos en la lógica de negocio.
Sencillamente, no es posible para este tipo de herramientas debido a su propio diseño. La lógica de negocio es única para cada organización y depende de cómo se diseñen y programen las API. Como resultado, el código que representa la lógica de negocio rara vez sigue patrones bien definidos sobre los cuales se puedan establecer firmas o reglas. Esta limitación es similar a los inconvenientes de los mecanismos de protección contra amenazas en las puertas de enlace de API y los WAF.
Las herramientas AST que pueden instrumentar y analizar aplicaciones o API a nivel de código mientras se ejecutan (por ejemplo, IAST) podrían descubrir subconjuntos de debilidades de escalada de privilegios. Las pruebas de seguridad basadas en instrumentación pueden ofrecer una cobertura limitada para la autorización a nivel de objeto rota y la autenticación rota . Sin embargo, la mayoría de las ofertas de los proveedores no profundizan en las pruebas de autenticación o autorización más allá de comprobaciones superficiales, como la detección de formas débiles de autenticación (básica o implícita). O bien, la herramienta AST podría analizar cómo se introducen, transmiten o almacenan las credenciales, lo cual, de nuevo, es solo una pequeña pieza del rompecabezas. Técnicamente, probar las debilidades de escalada de privilegios requiere múltiples ejecuciones de una herramienta DAST contra una aplicación y su API. Desafortunadamente, el tiempo es un recurso escaso en muchas organizaciones que adoptan DevOps y presionan para reducir los plazos de lanzamiento. Las herramientas DAST son conocidas por ejecutarse durante periodos de tiempo prolongados; peor que SAST y ligeramente mejor que el fuzzing.
Las herramientas DAST tampoco están diseñadas para probar API web. Por lo general, requieren un front-end para iniciar las solicitudes de la aplicación, como JavaScript ejecutándose en un motor de navegador web o un binario móvil en un dispositivo. Las herramientas DAST detectan problemas interceptando, analizando y manipulando el tráfico. Parte de ese tráfico puede ser de API, pero las herramientas DAST no tienen el contexto de cómo funcionan dichas API. Escanear API REST de forma eficaz requiere mucho cuidado y mantenimiento con DAST, similar al entrenamiento de un WAF. La configuración del escáner puede basarse parcialmente en la documentación de la API o definirse manualmente, pero es necesario para que una herramienta DAST pueda analizar un endpoint de API de forma algo inteligente. Aun así, un DAST puede intentar detectar vulnerabilidades o debilidades que no son relevantes en el mundo de las API, como paneles de control de administrador ocultos o problemas de fuerza bruta en directorios URL. Depende del profesional ajustar aún más la configuración del escaneo DAST y suprimir dichas reglas. Sin embargo, este ajuste requiere un conocimiento experto del sistema y de todas sus API.
En pocas palabras, las organizaciones deben recurrir al análisis en tiempo de ejecución y al establecimiento de líneas base de comportamiento de las API para identificar el amplio espectro de ataques a API y abusos de la lógica de negocio. El análisis estático y el dinámico siempre han tenido sus carencias. El problema se agrava en el mundo de las API.
Las carencias de los validadores de esquemas
Como forma de análisis estático, los validadores de esquemas de API suelen presentarse como la solución ideal para la seguridad en los procesos de integración continua (DevOps). El argumento suele ser: «Danos tus definiciones de esquema, podemos escanear tus API, asegurarnos de que cumplen con las normas y comprobar si hay vulnerabilidades».
El enfoque de validación de esquemas presenta varios problemas:
- No todo necesita estar definido en el esquema de la API: Los formatos de especificación de API como OpenAPI (OAS) y Swagger no exigen definir todos los campos o funciones en la documentación de la API. Es común que los desarrolladores olviden documentar algo por completo, especialmente si no trabajan con herramientas de diseño de API como Postman.
- Muchas organizaciones son descuidadas con la documentación: Los humanos son notoriamente malos documentando, y especialmente documentando todo al detalle. La falta de documentación no es un problema exclusivo de los desarrolladores. OAS puede ayudar al ser autodocumentado, pero aun así requiere un esfuerzo manual. Algunas herramientas pueden ser mejores que otras a la hora de generar la definición OAS.
- Desviación de la API: Las desviaciones entre la especificación original y lo que se ejecuta en producción son habituales. Deriva de API refleja uno de los mayores problemas a los que se enfrentan las organizaciones con los procesos de revisión de diseño seguro y modelado de amenazas. A veces, lo que se pretende construir termina siendo muy diferente al producto real.
La validación y aplicación de esquemas es el viejo paradigma de la seguridad positiva con un nuevo disfraz. En lugar de que los equipos de seguridad tengan que crear reglas o firmas, la carga se traslada a los equipos de desarrollo. La combinación de CWE y CVE inevitablemente volverá a aparecer. Al igual que sus homólogos de AST, los validadores de esquemas siguen sin poder detectar fallos de lógica de negocio y también pueden pasar por alto exposiciones de datos confidenciales.
La ilusión de los espejos de producción
Se requieren entornos que no sean de producción y que reflejen la realidad de producción para ejecutar eficazmente ciertos tipos de AST, incluidos DAST e IAST. Lamentablemente, estos entornos de prueba suelen ser un lujo para muchas organizaciones. Es probable que existan discrepancias entre producción y los entornos de prueba si todos los elementos no están completamente contenerizados y son fáciles de desplegar. Las plataformas de contenedores y las mallas de servicios pueden facilitar la creación de entornos según sea necesario, pero estas tecnologías conllevan una curva de aprendizaje enorme. Las organizaciones que no han alcanzado un nivel avanzado de madurez en DevOps tienen dificultades para desplegarlas y ponerlas en funcionamiento. También suelen existir limitaciones de costes o licencias para disponer de un entorno funcional que refleje fielmente la producción. La nube puede parecer una solución, ya que es fácil poner en marcha instancias efímeras en los proveedores de servicios en la nube, pero los gastos de computación en la nube se acumulan rápidamente.
A falta de entornos de prueba funcionales, algunas organizaciones optan por ejecutar herramientas DAST o IAST en producción. Aunque los proveedores afirman que una herramienta determinada es razonablemente segura para producción, muchas organizaciones sacrifican la profundidad o la precisión del escaneo al desactivar ciertos tipos de pruebas y limitar los escaneos recursivos que, de otro modo, podrían provocar una interrupción del servicio. Este tipo de concesiones reducen aún más la eficacia limitada de las herramientas AST cuando se trata de API.
La automatización exitosa de las pruebas de seguridad no puede existir sin la automatización de las pruebas no relacionadas con la seguridad
Automatizar las pruebas de seguridad en las cadenas de herramientas de desarrollo, los sistemas de control de versiones y las canalizaciones de compilación requiere disciplina en muchas prácticas ajenas a la seguridad. Una buena cobertura de código y de pruebas no puede lograrse sin una gestión adecuada de los datos de prueba, entornos de prueba similares a los de producción, pruebas unitarias definidas, scripts de automatización de pruebas funcionales (por ejemplo, Appium, Selenium) y más.
Los datos, las herramientas y los procesos necesarios para tener éxito en la automatización de pruebas son una responsabilidad compartida entre los equipos de identidad, infraestructura y operaciones, control de calidad y desarrollo. En algunas organizaciones, el control de calidad ni siquiera existe. En muchos casos, este rol se ha reducido significativamente o se ha eliminado por completo. Y suponiendo que todos estos fundamentos de automatización de pruebas estén en su lugar, es aún más raro que los equipos de seguridad colaboren con los equipos de aplicaciones para aprovechar todo ello.
La colaboración entre seguridad y otras áreas es inexistente en algunas organizaciones, y la madurez de DevOps puede ser menor. Los equipos de TI aislados y el aislamiento pueden persistir a menos que la organización haya adoptado una iniciativa de transformación digital más amplia. Estos enfoques plurianuales son algo más que la búsqueda de herramientas de canalización para resolver un problema. La transformación digital implica renovar radicalmente cómo funciona la organización, qué tipo de cultura fomenta, cómo contrata talento y más. Las metodologías ágiles y las prácticas de DevOps suelen estar entrelazadas con la transformación, pero hay muchos pilares en los que se tarda años en alcanzar la competencia. Muchos equipos de seguridad siguen operando de forma independiente a los equipos de desarrollo para poder mantener el enfoque en otros riesgos de seguridad que afectan a sus organizaciones. La fricción entre los equipos de desarrollo, operaciones y seguridad también sigue siendo más común de lo que nos gustaría pensar.
Lidiando con la mentalidad de cadena de montaje
Como profesionales de cualquier rol de TI, no trabajamos en fábricas. En algunos círculos, estos enfoques de canalización y programas de DevOps se denominan a veces fábricas de software. El concepto de fábrica de software promueve la mentalidad de cadena de montaje, excepto que no somos máquinas ni trabajadores de fábrica produciendo cosas. Muchos también argumentarían que los trabajadores de fábrica no siempre son trabajadores felices. Si un trabajador no está contento, eso afecta directamente a la calidad (y a la seguridad). Cualquier forma de código debe considerarse imperfecta, ya que somos humanos quienes lo creamos. Todavía no hemos llegado al punto de inflexión en el que las máquinas generen el código por sí mismas. El código también evoluciona con el tiempo, con muchas manos tocando una base de código a lo largo de su vida útil. El código también pasa por muchos conjuntos de escáneres a lo largo del tiempo y aún puede ser de baja calidad, explotable o vulnerable. Numerosas organizaciones modelo de DevOps con canalizaciones de compilación seguras han sufrido ataques a API que han provocado pérdida de datos, impactos en la privacidad, problemas de seguridad, daños a la marca y más.
Toyota se cita a menudo como una historia de éxito ágil, siendo pionera en la fabricación ajustada y el pensamiento ágil. Toyota también facultó a los trabajadores de la cadena de montaje para detener la línea tirando de un cordón andon si observaban un problema. Los vehículos de Toyota estuvieron plagados de problemas de aceleración involuntaria durante años en la década de 2000. Expertos revisaron posteriormente el código fuente de Toyota para los numerosos sistemas integrados y testificaron que los problemas de aceleración involuntaria probablemente fueron causados por código espagueti, no por alfombrillas intrusivas o pedales de acelerador atascados como se afirmó originalmente. Incluso si descarta este evento como el resultado de la corrupción o de objetivos comerciales que prevalecen sobre la seguridad pública, estos siguen siendo factores que resultaron en la omisión de protocolos de seguridad y estándares de desarrollo establecidos.
Los problemas encontrados durante las pruebas de seguridad deben registrarse como errores o defectos, terminando inevitablemente en una lista de tareas pendientes, o debe detener la canalización y fallar la compilación. Fallar las compilaciones en exceso retrasa los ciclos de lanzamiento. También se desarrollan otros aspectos del lanzamiento a producción. ¿Sabemos si los problemas son realmente explotables o vulnerables? ¿Qué gravedad y prioridad se deben asignar a un problema detectado? ¿Qué tan profundo en la lista de defectos debe ir el problema detectado? ¿Detiene un lanzamiento a producción por problemas de gravedad potencialmente baja que pueden ser o no explotables?
Es probable que haya más de una canalización
La mayoría de las organizaciones cuentan con una mezcla de tecnologías que involucran diferentes lenguajes de programación y procesos de desarrollo. Es probable que exista una combinación de arquitecturas monolíticas y de microservicios, tecnologías modernas y heredadas, y metodologías en cascada y ágiles. Esta mezcla conduce inevitablemente a múltiples canales de compilación (build pipelines) para las organizaciones, así como a una menor visibilidad o control sobre ellos. Algunos factores que contribuyen a esto incluyen:
- Parte del código y los canales por los que circula pueden estar fuera de su control.
- Un canal de compilación formalizado puede ser inexistente si la parte responsable no adopta CI/CD.
- Muchas organizaciones subcontratan o deslocalizan el desarrollo, ya sea total o parcialmente.
- Los esfuerzos de desarrollo suelen estar fragmentados, con equipos separados de front-end y back-end, o equipos dedicados a subconjuntos específicos de funcionalidad.
- Las plataformas de código bajo (low-code) pueden no proporcionar flujos de trabajo y servicios de compilación formalizados, o los artefactos de código pueden ser una incógnita.
La realidad del desarrollo de aplicaciones empresariales, la integración y la ingeniería de sistemas resulta inevitablemente en múltiples canales de compilación. Cuantos más canales existan, más difícil le resulta a la seguridad obtener visibilidad, integrar herramientas o ejercer control. Unificar todas las compilaciones en un solo canal es poco realista para la mayoría de las organizaciones, ya que a menudo existen necesidades comerciales legítimas para utilizar diferentes tecnologías.
Piense en los canales de compilación desde otra perspectiva
Las mejores prácticas y herramientas para asegurar el propio canal de compilación aún están en desarrollo. A veces, las organizaciones toman atajos en la seguridad de los servicios de CI/CD, o las herramientas no están diseñadas adecuadamente para garantizar la integridad de todo lo que pasa por el canal. Los diversos servicios de VCS, CI y CD son, a su vez, aplicaciones construidas a menudo sobre APIs. Estos también pueden ser atacados de diversas formas, lo que pone en riesgo todo lo que circula por su canal. Los equipos que operan dentro del canal pueden suprimir comprobaciones o resultados para poder lanzar el código. Los riesgos inherentes a la cadena de suministro empeoran cuanto más código o dependencias se obtienen de terceros. Los socios o proveedores también pueden proporcionar código personalizado que no forma parte de su canal, pero que termina en el código compilado o en el sistema completo de la organización. Todos estos factores afectan potencialmente la calidad y la seguridad de todo lo que se mueve a través de sus canales.
Es importante recordar que el escaneo de canales incluye comprobaciones para todas las formas de código, pero también controles que pueden auditarse mediante programación. Las prácticas de DevOps se extienden más allá del código fuente de la aplicación para incluir también la infraestructura como código (IaC) y las políticas como código (PaC). Del mismo modo que la funcionalidad se habilita mediante algo más que el código de la aplicación, lo mismo ocurre con la seguridad, y muchos controles de seguridad existen fuera del código. Los elementos que usted valida en los canales pueden simplemente implicar confirmar que un determinado control de seguridad en tiempo de ejecución esté habilitado y configurado adecuadamente en IaC o PaC.
Conclusión
Establecer y lograr la adopción de enfoques de canales de compilación seguros es un esfuerzo de varios años para las organizaciones. Y ningún esfuerzo de canal seguro puede tener éxito sin alcanzar cierto nivel de madurez en DevOps. Dicen que DevOps es un viaje por una razón. Se necesitan años para madurar sus procesos y cadenas de herramientas. Más importante aún, se necesita tiempo para lograr la adopción por parte de todas las personas de TI dentro y fuera de la organización. Sin embargo, a los atacantes no les importa su viaje de DevOps y, mientras tanto, están eludiendo los controles de acceso, explotando debilidades y abusando de la lógica empresarial.
Los enfoques de "shift-left" y de canales de compilación seguros tienen sus méritos. Sin embargo, las organizaciones deben aceptar el riesgo de que existen muchos tipos de problemas de seguridad que simplemente no pueden detectarse como parte de los escaneos automatizados de diseño, desarrollo y tiempo de compilación. Las organizaciones maduras en sus estrategias de seguridad de API y programas de DevSecOps admiten que, en el mejor de los casos, solo detectan una parte de los problemas de seguridad con una herramienta de escaneo determinada. Los problemas detectables se limitan a vulnerabilidades y debilidades que siguen patrones bien definidos. Muchos problemas de seguridad solo se manifiestan en tiempo de ejecución, como parte del sistema completo y dentro de la arquitectura empresarial.
El análisis de comportamiento en tiempo de ejecución es un camino a seguir para las organizaciones y una forma de protegerse del amplio espectro de problemas y ataques a las APIs. Cualquier oferta debe proporcionar detección y prevención tempranas, deteniendo a los atacantes antes de que logren explotar o abusar de sus APIs. La plataforma de protección de APIs de Salt Security fue creada para evitar los muchos inconvenientes de los enfoques de escaneo tradicionales y las mitigaciones en tiempo de ejecución. La plataforma de protección de APIs de Salt es:
- Ciclo de vida completo, proporcionando capacidades para las fases de diseño, compilación y tiempo de ejecución para fortalecer y proteger sus APIs contra el amplio espectro de patrones de ataque a APIs.
- Integrada, trabajando con sus inversiones tecnológicas existentes y minimizando el impacto en los flujos de trabajo de todas las personas que interactúan con las APIs
- Informada por ML, aportando inteligencia experta en los múltiples dominios de seguridad críticos para la protección de APIs, para los cuales de otro modo sería difícil contar con personal especializado
- Automatizado, aprendiendo la lógica de su negocio y los patrones de diseño de su API para ofrecer información de seguridad personalizada de forma automática
Para obtener más información sobre cómo Salt puede ayudar a proteger a su organización de los riesgos de las API, puede contactar a un representante o programar una demostración personalizada.