Las empresas pueden seguir recomendaciones detalladas y aplicar parches existentes y aplicar las mejores prácticas en respuesta inmediata a log4j. Pero en un segundo paso, deberían echar un vistazo general a los procesos relacionados con las cadenas de suministro de software.
Después de todo, incluso Log4Shell, sin importar qué tan relevante para la seguridad pueda ser la brecha, es "solo" un componente defectuoso en la cadena de suministro de software", dice Udo Schneider, IoT Security Evangelist Europe en Trend Micro.
Log4Shell - ¿Conoce su cadena de suministro de software?
Por supuesto, la amenaza crítica que representa la vulnerabilidad de Log4Shell requiere una respuesta inmediata. Pero en el segundo paso, las empresas generalmente tienen que hacerse preguntas sobre los procesos relacionados con las cadenas de suministro de software y las dependencias documentadas (?).
La vulnerabilidad de Log4Shell que se dio a conocer hace unos días está en boca de todos y mantiene alerta a los expertos en seguridad de todo el mundo. El BSI habla de una "situación de amenaza extremadamente crítica" porque la biblioteca vulnerable Log4J es, por así decirlo, "el" registro estándar en entornos Java. En consecuencia, también se utiliza en miles de aplicaciones y servicios de Internet. Además, es fácil abusar de la vulnerabilidad y, en muchos casos, se puede explotar de forma remota, lo que en última instancia permite la ejecución arbitraria de comandos. ¡Una auténtica pesadilla desde el punto de vista de la ciberseguridad! Las organizaciones pueden seguir nuestras recomendaciones detalladas y aplicar parches existentes y aplicar las mejores prácticas para una respuesta inmediata. Pero en un segundo paso, deberían echar un vistazo general a los procesos relacionados con las cadenas de suministro de software. Después de todo, incluso Log4Shell, sin importar qué tan relevante para la seguridad pueda ser la vulnerabilidad, es "solo" un componente defectuoso en la cadena de suministro de software.
Log4Shell el bloque de construcción defectuoso
Para comprender las cadenas de suministro de software y su contexto, es útil observar el mundo "real", como la fabricación de productos electrónicos. Las llamadas "listas de materiales" (BOM - Bill of Material) para ensamblajes son comunes. Si observa una sola placa de circuito como un conjunto, la lista de piezas correspondiente contiene una lista de todos los componentes utilizados, como resistencias, condensadores, diodos, circuitos integrados y mucho más. Para cada componente también se almacenan parámetros exactos, fabricantes, precios, fuentes de suministro y, en última instancia, también números de serie o al menos información de lote.
Si hay información del fabricante de uno de los componentes de que ciertos componentes de un lote no corresponden a los valores de temperatura especificados, es posible rastrear exactamente qué placas (cada una con su propio número de serie) están a) afectadas y b ) si es necesario actuar. Si es necesario tomar las medidas apropiadas, la información sobre qué ensamblajes se ven afectados (basada en el número de serie) es, por supuesto, de gran ayuda. En última instancia, este procedimiento continúa con "ensamblajes" casi a voluntad... hasta que finalmente terminas con instalaciones masivas como el LHC en el CERN. Incluso con una máquina tan grande, la falla de un pequeño componente SMD puede hacer que toda la máquina falle. Si, por ejemplo, se conocen lotes defectuosos, en última instancia debe poder verificar cada resistencia individual instalada.
Lista de materiales de software (SBOM)
Así es exactamente como funcionan las cadenas de suministro de software, es decir, SBOM”, y específicamente volviendo a Log4Shell: ¿Puede decir rápidamente si está afectado por esta brecha? Con su propio software que usa Log4J, la pregunta quizás pueda responderse rápidamente. A menudo, incluso los servicios SCM como GitHub o GitLab ofrecen dichas funciones directamente. Pero, ¿qué pasa con las dependencias transitorias? ¿Una biblioteca de terceros que utiliza utiliza Log4J internamente? O peor aún: ¿una biblioteca que usa usa una biblioteca que a su vez depende de (etc.) una biblioteca que usa Log4J? ¿El software comprado de un proveedor de servicios se basa en Log4J? ¿Un servicio en la nube que compra usa Log4J?
Contenido SBOM (Imagen: Trend Micro).
Preguntas sobre preguntas que necesitan respuestas que requieren que lidie con SBOM. Log4Shell muestra claramente los problemas que surgen cuando la cadena de suministro de software no está documentada. Pero no se deje engañar. Log4Shell es ciertamente el peor de los casos en este momento. Pero incluso con "fallos" simples que no son directamente relevantes para la seguridad, ¡la pregunta de si usted se ve afectado es importante!
Dependencias de documentos
Básicamente, los SBOM se tratan de documentar las dependencias. Pueden ser dependencias en forma de software (componentes), pero también servicios, licencias, servidores y mucho más. Especialmente cuando se trata de modelar dependencias de software, con el tiempo han surgido dos formatos de intercambio: CycloneDX y SPDX. Ambos permiten la descripción de diferentes componentes de software incluyendo posibles dependencias:
Pero el lenguaje descriptivo no es suficiente. Más bien, el entorno específico también debe describirse y mantenerse actualizado. Por supuesto, estas descripciones se pueden crear manualmente y, a veces, por ejemplo, cuando depende de servicios externos, no hay otra opción. Sin embargo, cuando se trata de crear descripciones para software, el esfuerzo manual no tiene sentido. Aquí, la creación y el mantenimiento de estas descripciones deben realizarse de forma totalmente automática como parte de la canalización de CI/CD. Básicamente, existen dos enfoques: integración en el proceso de construcción y escaneo de artefactos de construcción.
Integración de CI/CD: proceso de creación
Creación de SBOM durante el proceso de compilación (Imagen: Trend Micro).
Tanto CycloneDX como SPDX tienen herramientas que se pueden integrar directamente en el proceso de construcción. Estos extraen directamente las dependencias "en el origen" (transitorias). Estos pueden ser bibliotecas, archivos ejecutables, pero también contenedores o capas de contenedores. La integración directa también permite realizar un seguimiento de las dependencias que existen, por ejemplo, solo durante la compilación en sí, pero no en el producto terminado.
Integración de CI/CD: artefacto de compilación
Incluso si no se le permite intervenir directamente en el proceso de construcción, existen herramientas para CycloneDX y SPDX que escanean el resultado final "después". Esto significa que estas herramientas extraen las dependencias de la aplicación Java, por ejemplo, y las documentan. Dado que estas herramientas solo ven el resultado final, es muy posible que algunas dependencias simplemente se pasen por alto, ya que ya no se pueden deducir del resultado final.
Monitoreo de vulnerabilidades
Creación de SBOM después del proceso de compilación (Imagen: Trend Micro).
Para las empresas que solo están interesadas en el monitoreo de vulnerabilidades, muchas de estas herramientas también ofrecen una correlación directa con las bases de datos de vulnerabilidades. Esto significa que la salida no solo contiene los componentes encontrados, sino también una lista de vulnerabilidades. Esto es comparable, por ejemplo, a la integración de snyk, Trend Micro Application Security o Trend Micro Container Security en la canalización de CI/CD.
Pista de dependencia de OWASP
Si el seguimiento y la documentación de las licencias, el inventario o el grado de distribución también juegan un papel, hay otras soluciones (adicionalmente) disponibles. En este entorno, la herramienta de seguimiento de dependencias de OWASP (Open Web Application Security Project) es sin duda uno de los mejores. Como solución de código abierto, generalmente se integra en las canalizaciones de CI/CD y recibe datos SBOM allí, ya sea a través de datos CycloneDX/SPDX (manual, API) o directamente desde el proceso de compilación. Además, Dependency Track almacena automáticamente datos de vulnerabilidades de varias bases de datos de vulnerabilidades y correlaciona continuamente los datos de compilaciones (históricas) y vulnerabilidades. Las coincidencias se muestran en consecuencia en un tablero o se informan directamente a través del chat y la integración de CI/CD o, opcionalmente, se reenvían a herramientas para su corrección automática.
Integración de Dependency Track (Imagen: https://github.com/DependencyTrack/dependency-track )
Dependency Track es una base de datos con la que se puede responder fácilmente a la pregunta: "¿Dónde me afecta Log4Shell?". Esta respuesta no solo incluye las versiones actuales del software, sino que también se proporcionan descripciones de versiones anteriores. Por lo tanto, un posible hallazgo puede ser que una empresa no se vea afectada en la versión actual (ya que está suficientemente parcheada), pero sí 34 versiones anteriores. Si ahora también realiza un seguimiento de la información sobre la cantidad de versiones instaladas, estos son datos casi perfectos para una evaluación de riesgos bien fundamentada.
Conclusión sobre Log4j, Log4Shell y las cadenas de suministro
Finalmente, es importante poder responder a las preguntas planteadas al principio: ¿Utilizamos (directamente o en nuestra cadena de suministro de software) Log4J? Si es así, ¿hasta qué punto (versión, distribución) nos afecta Log4Shell? El esfuerzo requerido para responder a esta pregunta es un indicador de hasta qué punto tiene conocimiento de su cadena de suministro de software y si vale la pena usar herramientas para ayudar allí.
Con respecto a las herramientas, es importante aclarar si se trata "solo" de la pregunta "estoy afectado". Si este es el caso, te ayudarán herramientas como snyk o las opciones integradas en GitHub y GitLab. Por otro lado, si se desea una vista más completa, existen otras soluciones para capturar y catalogar artefactos de software. Ambos son comerciales y gratuitos. Desde el campo de código abierto, Dependency Track es sin duda el más extendido aquí.
En última instancia, sin embargo, debe tenerse en cuenta que las brechas de seguridad son un argumento importante para la gestión de la cadena de suministro de software, ¡pero ciertamente no el único!
Más en TrendMicro.com
Acerca de Trend Micro Como uno de los principales proveedores de seguridad de TI del mundo, Trend Micro ayuda a crear un mundo seguro para el intercambio de datos digitales. Con más de 30 años de experiencia en seguridad, investigación de amenazas globales e innovación constante, Trend Micro ofrece protección para empresas, agencias gubernamentales y consumidores. Gracias a nuestra estrategia de seguridad XGen™, nuestras soluciones se benefician de una combinación intergeneracional de técnicas de defensa optimizadas para entornos de vanguardia. La información de amenazas en red permite una protección mejor y más rápida. Optimizadas para cargas de trabajo en la nube, terminales, correo electrónico, IIoT y redes, nuestras soluciones conectadas brindan visibilidad centralizada en toda la empresa para una detección y respuesta más rápidas a las amenazas.