Estado de la seguridad de las aplicaciones

Lo que las estadísticas nos muestran

0
24

La aparición de la cultura DevOps en los últimos años ha cambiado el desarrollo de software, permitiendo a las empresas entregar código más rápidamente y escalar automáticamente la infraestructura necesaria para soportar nuevas características e innovaciones. El mayor empuje hacia DevSecOps, que introduce la seguridad en los canales de desarrollo y operaciones, está cambiando ahora el estado de la seguridad de las aplicaciones, pero según los datos de los nuevos informes de la industria aún quedan una serie de vacíos.

Propiedad de las pruebas de seguridad
Un nuevo informe del Grupo de Estrategias Empresariales (ESG), que encuestó a 378 desarrolladores de aplicaciones y profesionales de la seguridad de aplicaciones en América del Norte, encontró que muchas organizaciones continúan empujando el código con vulnerabilidades conocidas a producción, a pesar de ver sus propios programas de seguridad de aplicaciones como sólidos.

Liberar código vulnerable nunca es bueno, pero hacerlo a sabiendas es mejor que hacerlo sin saberlo, ya que la decisión suele implicar cierta evaluación de los riesgos, un plan para solucionarlos y tal vez mitigaciones temporales. La mitad de los encuestados dijeron que sus organizaciones hacen esto regularmente, y un tercio dijo que lo hacen ocasionalmente. Las razones más citadas fueron el cumplimiento de un plazo límite crítico, el bajo riesgo de las vulnerabilidades o el hecho de que los problemas se descubran demasiado tarde en el ciclo de publicación (45%).

Los hallazgos destacan por qué es importante integrar las pruebas de seguridad lo antes posible en el proceso de desarrollo, pero también que la liberación de código vulnerable no es necesariamente una señal de que no se tiene un buen programa de seguridad, porque esto puede suceder por diferentes razones y ningún tipo de prueba de seguridad atrapará todos los errores. Sin embargo, el informe también encontró que muchas organizaciones todavía están en el proceso de expandir sus programas de seguridad de aplicaciones, con solo un tercio señalando que sus programas cubren más de tres cuartos de su base de código, y otro tercio diciendo que sus programas cubren menos de la mitad.

Según el estudio mencionado, el responsable de tomar la decisión de empujar el código vulnerable a producción puede variar de una organización a otra. En el 28% de las organizaciones la decisión es tomada por el gerente de desarrollo junto con un analista de seguridad; en el 24%, por el gerente de desarrollo solo; y en el 21%, por un analista de seguridad.

Esto podría ser en realidad una señal de que los programas de seguridad de las aplicaciones están madurando, porque DevSecOps trata de trasladar las pruebas de seguridad lo antes posible al desarrollo, mientras que en el pasado las pruebas de seguridad recaían únicamente en la esfera de los equipos de seguridad que las realizaban una vez completado el producto.

En las organizaciones en las que el equipo de desarrollo realiza las pruebas de seguridad como resultado de las integraciones en sus procesos y también consume los resultados, es normal que el director de desarrollo tome decisiones sobre qué vulnerabilidades son aceptables, ya sea en colaboración con el equipo de seguridad, o incluso dentro de su propia organización si tienen un campeón de seguridad -un desarrollador con conocimientos y formación en seguridad de aplicaciones- en su equipo. No obstante, esas decisiones deben seguir adoptándose sobre la base de las políticas establecidas por la organización CISO, que es la responsable de la gestión del riesgo de seguridad de la información de toda la empresa y puede, por ejemplo, decidir qué aplicaciones están más expuestas a los ataques o contienen información más sensible que los hackers podrían atacar. Esas aplicaciones podrían tener normas más estrictas en lo que respecta a la aplicación de parches.

Si no se evalúa correctamente el riesgo, el envío de código con vulnerabilidades conocidas puede tener consecuencias graves. El 60% de los encuestados admitió que sus aplicaciones de producción fueron explotadas a través de las vulnerabilidades listadas en el Top-10 de OWASP durante los últimos 12 meses. El Top-10 de OWASP contiene los riesgos de seguridad más críticos para las aplicaciones web e incluye problemas como la inyección SQL, la autenticación rota, la exposición de datos sensibles, los controles de acceso rotos, las malas configuraciones de seguridad, el uso de componentes de terceros con vulnerabilidades conocidas y más. Se trata de problemas que, en general, no deberían permitirse en el código de producción.

Según el informe de ESG, las empresas utilizan una variedad de herramientas de prueba de seguridad de aplicaciones: escaneo de vulnerabilidad de seguridad de API (ASV) (56%), herramientas de seguridad de infraestructura como código para protegerse contra las malas configuraciones (40%), herramientas de prueba de seguridad de aplicaciones estáticas (SAST) (40%), herramientas de prueba de análisis de composición de software (SCA) (38%), herramientas de prueba de seguridad de aplicaciones interactivas (IAST) (38%), herramientas de prueba de seguridad de aplicaciones dinámicas (DAST) (36%), plugins para entornos de desarrollo integrado (IDEs) que ayudan a identificar y resolver problemas de seguridad (29%), herramientas de escaneo de imágenes utilizadas en contenedores, repositorios y microservicios (29%), herramientas de fuzzing (16%) y herramientas de seguridad de configuración de tiempo de ejecución de contenedores (15%).

Sin embargo, entre los principales desafíos en el uso de estas herramientas, los encuestados mencionaron que los desarrolladores carecen de los conocimientos necesarios para mitigar los problemas identificados (29%), que los desarrolladores no utilizan las herramientas en las que la empresa ha invertido eficazmente (24%), que las herramientas de pruebas de seguridad añaden fricción y ralentizan los ciclos de desarrollo (26%), y que hay una falta de integración entre las herramientas de seguridad de las aplicaciones de diferentes proveedores (26%).

Mientras que casi el 80% de las organizaciones informan que sus analistas de seguridad están directamente comprometidos con sus desarrolladores revisando las características y el código, haciendo el modelado de amenazas o participando en las reuniones diarias de scrum de desarrollo, los propios desarrolladores no parecen recibir mucha capacitación en seguridad. Esta es la razón por la cual solo en el 19% de las organizaciones la tarea de comprobación de la seguridad de las aplicaciones pertenece formalmente a los desarrolladores individuales, y en el 26% a los directores de desarrollo. Un tercio de las organizaciones todavía tienen esta tarea asignada a analistas de seguridad dedicados, y en otro 29% es propiedad conjunta de los equipos de desarrollo y seguridad.

En un tercio de las organizaciones, menos de la mitad de los desarrolladores requieren recibir formación formal en materia de seguridad, y solo el 15% de esa capacitación es requisito para todos los desarrolladores. Menos de la mitad de las organizaciones les exigen que se comprometan con la formación formal en seguridad más de una vez al año, el 16% espera que los desarrolladores se auto-educen y el 20% solo ofrece formación cuando un desarrollador se une al equipo.

Además, incluso cuando se proporciona o se requiere capacitación, en la mayoría de las organizaciones no se hace un seguimiento adecuado de la eficacia de esa capacitación. Solo el 40% de éstas hace un seguimiento de la introducción de problemas de seguridad y de las métricas de mejora continua para los equipos de desarrollo o los desarrolladores individuales.

Veracode, uno de los proveedores de seguridad de aplicaciones que patrocinó la investigación del ESG, lanzó recientemente la Veracode Security Labs Community Edition, una plataforma dentro del navegador donde los desarrolladores pueden obtener acceso gratuito a docenas de cursos de seguridad de aplicaciones y aplicaciones en contenedores que pueden explotar y parchear para practicar.

Componentes de código abierto objeto de los ataques a la cadena de suministro
Cualquier programa maduro de seguridad de aplicaciones debería cubrir cualquier componente y marco de código abierto, ya que estos constituyen un gran porcentaje de las bases de código de las aplicaciones modernas, y conllevan riesgos de vulnerabilidades heredadas y ataques a la cadena de suministro. Casi la mitad de los encuestados en la encuesta de ESG dijeron que los componentes de código abierto constituyen más del 50% de su base de código y el 8% dijo que representan dos tercios de su código. A pesar de eso, solo el 48% de las organizaciones han invertido en controles para hacer frente a las vulnerabilidades de código abierto.

En su informe sobre el estado de la cadena de suministro de software en el 2020, Sonatype, empresa de gobernanza de código abierto, señaló un crecimiento del 430% año tras año de los ataques dirigidos a proyectos de software de código abierto. Estos ya no son unos pasivos en los que los atacantes explotan las vulnerabilidades después de haberlas divulgado públicamente, sino unos en los que los atacantes tratan de comprometer e inyectar malware en la fase inicial de los proyectos de código abierto, y cuyo código es luego arrastrado por los desarrolladores a sus propias aplicaciones.

En mayo, el equipo de seguridad de GitHub emitió una advertencia sobre una campaña de malware denominada Octopus Scanner que estaba respaldando proyectos de NetBeans IDE. Los componentes maliciosos o comprometidos también fueron distribuidos regularmente en los repositorios de paquetes como npm o PyPi.

La compleja red de dependencias hace que sea difícil lidiar con este problema. En el 2019, investigadores de la Universidad de Darmstadt analizaron el ecosistema npm, que es la fuente principal de los componentes de JavaScript, y encontraron que cualquier paquete típico cargaba un promedio de 79 paquetes de terceros de 39 mantenedores diferentes. Los cinco primeros paquetes en el npm tenían un alcance de entre 134.774 y 166.086 otros paquetes.

«Cuando el código malicioso es inyectado deliberada y secretamente en proyectos de código abierto, es muy probable que nadie sepa que el malware está ahí, excepto la persona que lo plantó”, señaló Sonatype en su informe. «Este enfoque permite a los adversarios tender trampas de manera clandestina en la fase inicial, y luego realizar ataques en la fase final una vez que la vulnerabilidad ha pasado a través de la cadena de suministro y ha sido liberada».

Según la empresa, entre febrero del 2015 y junio del 2019 se notificaron 216 de esos ataques a la cadena de suministro de «nueva generación», pero entre julio del 2019 y mayo del 2020 se documentaron otros 929 ataques. Este se ha convertido en un vector de ataque muy popular.

En cuanto a los ataques tradicionales en los que los hackers explotan vulnerabilidades conocidas en los componentes, las empresas parecen no estar preparadas para responder con suficiente rapidez. En el caso de la vulnerabilidad de Apache Struts2 que finalmente llevó a la ruptura de Equifax en el 2017, los atacantes comenzaron a explotar la vulnerabilidad dentro de las 72 horas siguientes a que se conociera. Más recientemente, una vulnerabilidad reportada en SaltStack también fue explotada dentro de los tres días posteriores de ser anunciada, sorprendiendo a muchas compañías sin estar preparadas.

Una encuesta de Sonatype a 679 profesionales del desarrollo de software reveló que solo el 17% de las organizaciones se enteran de las vulnerabilidades del código abierto en el día siguiente a la divulgación pública; un tercio del total dentro de la primera semana; y casi la mitad después de una semana. Además, alrededor de la mitad de las organizaciones necesitaron más de una semana para responder a una vulnerabilidad después de conocerla, y la otra mitad tardó más de un mes.

Tanto la disponibilidad como el consumo de componentes de código abierto aumenta cada año que pasa. La comunidad de JavaScript introdujo más de 500 mil nuevas versiones de componentes durante el año pasado empujando el directorio npm a 1.3 millones de paquetes. Hasta mayo los desarrolladores descargaron paquetes 86 miles de millones de veces de npm, y Sonatype proyecta que para fin de año la cifra alcanzará un billón de descargas. Es preocupante que la investigación de la Universidad de Darmstadt publicada el año pasado haya revelado que casi el 40% de todos los paquetes npm contienen o dependen de código con vulnerabilidades conocidas, y que el 66% de las vulnerabilidades en los paquetes npm permanecen sin parchear.

En el ecosistema de Java, los desarrolladores descargaron 226 mil millones de componentes de software de código abierto del Repositorio Central de Maven en el 2019, lo que supuso un aumento del 55% en comparación con el 2018. Dadas las estadísticas vistas en el 2020, Sonatype estima que las descargas de componentes de Java alcanzarán los 376 mil millones este año. La compañía, que mantiene el Repositorio Central y tiene un profundo conocimiento de los datos, informa que una de cada diez descargas fue para un componente con una vulnerabilidad conocida.

Un análisis más detallado de 1.700 aplicaciones empresariales reveló que, en promedio, contenían 135 componentes de software de terceros, de los cuales el 90% eran de código abierto. De esos, el 11% tenía al menos una vulnerabilidad, pero las aplicaciones tenían en promedio 38 vulnerabilidades conocidas heredadas de esos componentes. Tampoco era infrecuente ver aplicaciones ensambladas de dos mil a cuatro mil componentes de código abierto, lo que resaltaba la importancia del papel que desempeña el ecosistema de código abierto en el desarrollo de software moderno.

Se observaron tendencias similares de consumo de componentes en el ecosistema .NET y en el ecosistema de microservicios, con DockerHub recibiendo imágenes de contenedores 2.2 durante el año pasado y estando en camino a ver 96 mil millones de solicitudes de extracción de imágenes por parte de los desarrolladores este año. Los ataques a la cadena de suministro comunicados públicamente han involucrado imágenes de contenedores malignos alojados en DockerHub, y la posibilidad de tener imágenes con configuraciones erróneas o vulnerabilidades es alta.

La infraestructura como código necesita reparación
El movimiento DevOps ha cambiado el desarrollo de software y ha hecho posible la nueva arquitectura de microservicios, en la que las aplicaciones monolíticas tradicionales son descompuestas en servicios mantenidos individualmente que operan en sus propios contenedores. Las aplicaciones ya no solo contienen el código necesario para sus características, sino también los archivos de configuración que dictan y automatizan su despliegue en las plataformas de la nube, junto con los recursos que necesitan. En DevSecOps, los equipos de desarrollo no solo son responsables de escribir código seguro, sino también de desplegar una infraestructura segura.

De acuerdo con un nuevo informe de la empresa de seguridad en la nube Accurics, que opera una plataforma que puede detectar configuraciones vulnerables en plantillas de infraestructura como código y despliegues en la nube, el 41% de las organizaciones tenían claves codificadas con privilegios en sus configuraciones que se utilizaban para suministrar recursos informáticos, el 89% de los despliegues tenían recursos aprovisionados y en marcha con políticas de gestión de identidad y acceso (IAM) excesivamente permisivas, y la gran mayoría contaba con reglas de enrutamiento mal configuradas.

Según la empresa, la violación de seguridad de septiembre del 2019 en CenturyLink, que expuso 2,8 millones de registros de clientes; la de agosto del 2019 en Imperva, que mostró una instantánea de la base de datos que contenía correos electrónicos y contraseñas; y la de julio del 2019 en Capital One, que afectó a 100 millones de residentes de los Estados Unidos, fueron el resultado de ataques que explotaron al menos uno de esos problemas.

«La política como código debe aplicarse para garantizar que se empleen las mejores prácticas, como la codificación de las bases de datos, la rotación de las claves de acceso y la aplicación de la autenticación multifactor», anotó Accurics en su informe. «Sin embargo, el modelado automatizado de amenazas también es necesario para determinar si cambios, tales como el aumento de los privilegios y los cambios de ruta, crean vías de violación en un despliegue en la nube. Como resultado, las organizaciones deben aumentar la política como código con la seguridad como código cuando la infraestructura es definida durante el desarrollo (la infraestructura como código)».

Según Om Moolchandani, CTO de Accurics, está surgiendo una nueva práctica llamada «remediación como código» en la que las herramientas de seguridad no solo comprueban las vulnerabilidades en las plantillas de configuración de la nube o en los propios despliegues en ejecución, sino que también generan el código necesario para solucionar automáticamente el problema y se lo proponen a los desarrolladores. Esto podría mejorar el tiempo que tardan las organizaciones en corregir, lo que representa un problema importante, ya que hasta el momento dicho proceso se ha venido realizando manualmente y se han terminado ignorando muchos problemas.

En los últimos años, muchos proveedores de seguridad para aplicaciones e infraestructuras han estado trabajando en la reingeniería de sus productos para que se integren bien con las herramientas de desarrollo, ya que los desarrolladores tienen expectativas diferentes y trabajan de forma distinta a los equipos de seguridad. También están disponibles una serie de herramientas de código abierto para probar las implementaciones de la nube.

La empresa de pruebas de penetración Bishop Fox lanzó una herramienta llamada Smogcloud durante la conferencia Black Hat USA que puede ayudar a los ingenieros de seguridad y a los administradores de la nube a encontrar sus activos de nube AWS expuestos, incluyendo problemas como los FQDNs e IPs conectados a Internet, configuraciones erróneas o vulnerabilidades, activos que ya no están en uso, servicios que no están siendo monitoreados y otros problemas de TI ocultos. Accurics también tiene una colección de herramientas de código abierto y una versión gratuita de su plataforma de pruebas de despliegue en la nube.

Lucian Constantin, CSOonline.com