Cosas vulnerables que se ejecutan en contenedores siguen siendo cosas vulnerables.
Se ha dicho –y no sólo por mí– que el código malicioso cifrado sigue siendo código malicioso. El cifrado no hace nada para cambiar eso, excepto posiblemente cegar la seguridad y la infraestructura de la aplicación para su transporte a través de la red.
Lo mismo ocurre con las aplicaciones y plataformas que se ejecutan en contenedores. Si la aplicación es vulnerable, lo es independientemente de que se ejecute sobre un sistema operativo, en una máquina virtual o, actualmente, en un contenedor. Si la aplicación es vulnerable en el centro de datos, es vulnerable en la nube. Y viceversa.
Los contenedores no están diseñados para proteger mágicamente las aplicações. Proporcionan cierta seguridad básica en la capa de red, pero la red no es la aplicação. Las aplicações tienen su superficie de ataque, que incluye su código e interfaces (API), así como los protocolos (HTTP, TCP) y la pila de aplicaciones que requiere. Nada de esto cambia al agregar una entrada a una tabla IP o restringir de otro modo las solicitudes entrantes a aquellas que provienen del ingreso al entorno en contenedores.
La razón por la que menciono esto es gracias a la Encuesta DevSecOps 2017 de Sonatype. En él, el 88% de los más de 2200 encuestados estuvo de acuerdo en que la seguridad de los contenedores era importante, pero solo el 53% aprovecha los productos de seguridad para identificar aplicações, sistemas operativos y configuraciones vulnerables en los contenedores.
Los primeros dos elementos de esa estadística ( aplicações y sistema operativo) me llamaron la atención porque son dos de los componentes de una pila de aplicaciones completamente realizada que no cambian necesariamente en función de la ubicación o el modelo operativo (nube, contenedor, virtualización, etc.). Una aplicación o API con una vulnerabilidad SQLi o XSS no está mágicamente imbuida de protección cuando se mueve entre modelos. Esa vulnerabilidad está en el código. Lo mismo ocurre con las plataformas, que son indiscutiblemente parte de la pila de seguridad de la aplicación. Aún existirá una vulnerabilidad en el manejo de encabezados HTTP en Apache cuando se ejecuta en Linux si esa aplicación se traslada de un modelo tradicional basado en sistema operativo a un modelo en contenedores.
Es importante, incluso imperativo, que sigamos identificando vulnerabilidades en toda la pila de aplicaciones , independientemente de dónde o en qué forma se implemente la aplicación.
También es igualmente importante mantener las protecciones de aplicaciones que ya se emplean para las aplicaciones tradicionales cuando se migran a contenedores. Un firewall de aplicação web es tan beneficioso para las aplicaciones implementadas en contenedores como para las aplicaciones implementadas en la nube y en entornos tradicionales.
Al igual que otras herramientas de seguridad, la encuesta encontró que los encuestados las utilizan, como soluciones de escaneo estático y en tiempo real ( SAST, DAST, IAST y RASP ). Si bien el uso de firewall de aplicação web (WAF) supera al de otras herramientas, SAST y SCA (análisis de código fuente ) también son comunes. SCA es un medio estático para eliminar problemas antes de la entrega. Me pondré del año y señalaré que herramientas como lint entran en la categoría de herramientas SCA, y si bien no exponen vulnerabilidades resultantes de la interacción del código (y con los usuarios) en tiempo real, pueden encontrar algunos de los errores más comunes cometidos por los desarrolladores que resultan en fugas de memoria, fallas o el infame desbordamiento del búfer.
Sé lo que estás pensando. Estás pensando: “Lori, acabo de leer los resultados de la encuesta para desarrolladores de Stack Overflow de 2017 y JavaScript es, por lejos, el lenguaje preferido número uno de los desarrolladores. Y JavaScript se interpreta, por lo que todo este asunto del desbordamiento de búfer y las pérdidas de memoria son simplemente malos recuerdos de los viejos tiempos, cuando se codificaba en C/C++”.
Excepto que JavaScript –y otros lenguajes interpretados modernos– se implementan en última instancia en un lenguaje más cercano a la placa de circuito, como C/C++. Y como se ha demostrado en el pasado , si uno es lo suficientemente inteligente, puede usar ese hecho para crear un exploit para el sistema.
E incluso si eso no es una preocupación, hay muchas otras vulnerabilidades en cualquier código basadas en bibliotecas utilizadas o en una llamada de sistema mal utilizada que viola la seguridad del lado del servidor. Las encuestas actuales dicen que el 80% de las aplicaciones están compuestas por componentes de código abierto. La encuesta de Sonatype señaló además que hubo un aumento del 50% en infracciones verificadas o sospechosas relacionadas con componentes de código abierto entre 2014 y 2017. Muchos de ellos están escritos en lenguajes que se prestan a errores más espectaculares, tanto porque están menos controlados como porque hay cada vez menos desarrolladores competentes en esos lenguajes.
El punto es que cualquier código es propenso a contener vulnerabilidades. Y dado que el código es el elemento fundamental de las aplicaciones, que son la cara visible de los negocios hoy en día, es importante escanearlas y protegerlas sin importar dónde o cómo se implementen.
Contenedores o nube. Tradicional o virtual. Todas las aplicações deben analizarse para detectar vulnerabilidades y protegerse contra ataques a plataformas y protocolos. Período.
Las aplicaciones deben escanearse y probarse exhaustivamente durante el desarrollo y luego probarse nuevamente en producción. Ambos son necesarios, porque la falacia de descomposición nos dice que la introducción de nuevos componentes cambia la línea base. Nuevas interacciones pueden hacer que salgan a la luz vulnerabilidades previamente no descubiertas.
Para proteger las aplicaciones, tenga en cuenta lo siguiente:
- Utilizar herramientas de análisis de código y aplicaciones en el desarrollo. Si es posible, incorpórelos al flujo de trabajo de CI/CD.
- Pruebe nuevamente en producción, en caso de que la interacción con otros componentes/aplicaciones presente problemas.
- Manténgase al tanto de las vulnerabilidades del protocolo y la plataforma , así como de aquellas descubiertas en bibliotecas de terceros que pueda utilizar.
- Integre un firewall de aplicaciones web en su arquitectura. Incluso si no lo usa en modo de bloqueo, es un recurso invaluable en caso de que se descubra una vulnerabilidad de día cero o de biblioteca en un protocolo/plataforma.
¡Mantenerse seguro!