As empresas podem seguir recomendações detalhadas e aplicar patches existentes e aplicar as melhores práticas em resposta imediata ao log4j. Mas, em uma segunda etapa, eles devem dar uma olhada geral nos processos relacionados às cadeias de suprimentos de software.
Afinal, mesmo o Log4Shell, não importa o quão relevante para a segurança seja a lacuna, é "apenas" um componente defeituoso na cadeia de suprimentos de software", diz Udo Schneider, IoT Security Evangelist Europe na Trend Micro.
Log4Shell - Você conhece sua cadeia de suprimentos de software?
Obviamente, a ameaça crítica representada pela vulnerabilidade Log4Shell requer uma resposta imediata. Mas na segunda etapa, as empresas geralmente precisam se questionar sobre processos relacionados a cadeias de suprimentos de software e dependências documentadas (?)
A vulnerabilidade Log4Shell que se tornou conhecida há alguns dias está na boca de todos e mantém os especialistas em segurança em todo o mundo em alerta. O BSI fala de uma "situação de ameaça extremamente crítica" porque a vulnerável biblioteca Log4J é, por assim dizer, "o" padrão de log em ambientes Java. Assim, também é usado em milhares de aplicativos e serviços de Internet. Além disso, é fácil abusar da vulnerabilidade e, em muitos casos, pode ser explorada remotamente, permitindo a execução arbitrária de comandos. Um verdadeiro pesadelo do ponto de vista da cibersegurança! As organizações podem seguir nossas recomendações detalhadas e aplicar patches existentes e aplicar as melhores práticas para resposta imediata. Mas, em uma segunda etapa, eles devem dar uma olhada geral nos processos relacionados às cadeias de suprimentos de software. Afinal, mesmo o Log4Shell, não importa quão relevante para a segurança a vulnerabilidade possa ser, é “apenas” um componente defeituoso na cadeia de suprimentos de software.
Log4Shell o bloco de construção defeituoso
Para entender as cadeias de suprimentos de software e seu contexto, é útil olhar para o mundo "real", como a fabricação de produtos eletrônicos. As chamadas “listas de materiais” (BOM – Bill of Material) para montagens são comuns. Se você observar uma única placa de circuito como um conjunto, a lista de peças apropriada contém uma lista de todos os componentes usados, como resistores, capacitores, diodos, ICs e muito mais. Parâmetros exatos, fabricantes, preços, fontes de suprimento e, finalmente, também números de série ou pelo menos informações de lote também são armazenados para cada componente.
Se houver informação do fabricante de um dos componentes de que determinados componentes de um lote não correspondem aos valores de temperatura especificados, é possível rastrear exatamente quais placas (cada uma com seu próprio número de série) são a) afetadas e b ) se há necessidade de ação. Se medidas apropriadas tiverem que ser iniciadas, as informações sobre quais conjuntos são afetados (com base no número de série) são de grande ajuda. Em última análise, esse procedimento continua com "montagens" quase à vontade ... até que você finalmente termine com instalações massivas como o LHC no CERN. Mesmo com uma máquina tão grande, a falha de um pequeno componente SMD pode causar a falha de toda a máquina. Se, por exemplo, lotes defeituosos se tornarem conhecidos, você terá que ser capaz de verificar cada resistor individual instalado.
Lista de materiais de software (SBOM)
É exatamente assim que as cadeias de suprimentos de software funcionam, ou seja, SBOMs ”- e especificamente de volta ao Log4Shell: você pode dizer rapidamente se é afetado por essa lacuna? Com seu próprio software que usa o Log4J, talvez a pergunta possa ser respondida rapidamente. Frequentemente, até serviços SCM como GitHub ou GitLab oferecem essas funções diretamente. Mas e as dependências transitórias? Uma biblioteca de terceiros que você usa usa o Log4J internamente? Ou pior ainda - uma biblioteca que você usa usa uma biblioteca que, por sua vez, depende (etc.) de uma biblioteca que usa Log4J? O software adquirido de um provedor de serviços depende do Log4J? Um serviço de nuvem que você compra usa o Log4J?
Conteúdo SBOM (Imagem: Trend Micro).
Perguntas e mais perguntas que precisam de respostas que exigem que você lute com SBOMs. Log4Shell mostra claramente os problemas que surgem quando a cadeia de suprimentos de software não é documentada. Mas não se deixe enganar. Log4Shell é certamente o pior cenário no momento. Mas mesmo com "falhas" simples que não são diretamente relevantes para a segurança, a questão de saber se você foi afetado é importante!
dependências do documento
Basicamente, SBOMs tratam de documentar dependências. Podem ser dependências na forma de software (componentes), mas também serviços, licenças, servidores e muito mais. Especialmente quando se trata de modelar dependências de software, dois formatos de troca surgiram ao longo do tempo: CycloneDX e SPDX. Ambos permitem a descrição de diferentes componentes de software, incluindo possíveis dependências:
Mas a linguagem descritiva não é suficiente. Em vez disso, o ambiente específico também deve ser descrito e atualizado. Claro, essas descrições podem ser criadas manualmente - e às vezes, por exemplo, quando depende de serviços externos, não há outra escolha. No entanto, quando se trata de criar descrições de software, o esforço manual não faz sentido. Aqui, a criação e manutenção dessas descrições devem ocorrer de forma totalmente automática como parte do pipeline CI/CD. Existem basicamente duas abordagens: integração no processo de construção e varredura de artefatos de construção.
Integração CI/CD - processo de construção
Criação do SBOM durante o processo de construção (Imagem: Trend Micro).
Ambos CycloneDX e SPDX possuem ferramentas que podem ser integradas diretamente no processo de construção. Estes extraem dependências diretamente "na fonte" (transitórias). Podem ser bibliotecas, arquivos executáveis, mas também contêineres ou camadas de contêineres. A integração direta também permite rastrear as dependências que existem, por exemplo, apenas durante a própria compilação, mas não no produto final.
Integração CI/CD – construir artefato
Mesmo que você não tenha permissão para intervir diretamente no processo de construção, existem ferramentas para CycloneDX e SPDX que verificam o resultado final "depois". Isso significa que essas ferramentas extraem as dependências do aplicativo Java, por exemplo, e as documentam. Como essas ferramentas sempre veem apenas o resultado final, é bem possível que algumas dependências sejam simplesmente ignoradas, pois não podem mais ser deduzidas do resultado final.
Monitoramento de Vulnerabilidade
Criação do SBOM após o processo de build (Imagem: Trend Micro).
Para empresas interessadas apenas no monitoramento de vulnerabilidades, muitas dessas ferramentas também oferecem correlação direta com bancos de dados de vulnerabilidades. Isso significa que a saída não contém apenas os componentes encontrados, mas também uma lista de vulnerabilidades. Isso é comparável, por exemplo, à integração do snyk, Trend Micro Application Security ou Trend Micro Container Security no pipeline de CI/CD.
Rastreamento de Dependência OWASP
Se o rastreamento e a documentação de licenças, inventário ou grau de distribuição também desempenham um papel, outras soluções (adicionalmente) estão disponíveis. Nesse ambiente, a ferramenta de rastreamento de dependência do OWASP (Open Web Application Security Project) é certamente uma das melhores. Como uma solução de código aberto, geralmente é integrado a pipelines de CI/CD e recebe dados SBOM lá - por meio de dados CycloneDX/SPDX (manual, API) ou diretamente do processo de construção. Além disso, o Dependency Track armazena automaticamente dados de vulnerabilidade de vários bancos de dados de vulnerabilidade e correlaciona continuamente os dados de compilações (históricas) e vulnerabilidades. As correspondências são exibidas adequadamente em um painel ou relatadas diretamente via chat e integração CI/CD ou, opcionalmente, encaminhadas para ferramentas para correção automática.
Integração do rastreamento de dependência (Imagem: https://github.com/DependencyTrack/dependency-track )
Dependency Track é um banco de dados com o qual a pergunta: "Onde estou afetado pelo Log4Shell" pode ser facilmente respondida. Esta resposta não inclui apenas as versões atuais do software, mas também são fornecidas descrições de versões antigas. Uma descoberta possível pode, portanto, ser que uma empresa não é afetada na versão atual (desde que esteja suficientemente corrigida), mas 34 versões anteriores são afetadas. Se agora você também rastrear informações sobre o número de versões instaladas, esses são dados quase perfeitos para uma avaliação de risco bem fundamentada.
Conclusão sobre Log4j, Log4Shell e cadeias de suprimentos
Finalmente, é importante ser capaz de responder às perguntas feitas no início: Nós (diretamente ou em nossa cadeia de suprimentos de software) usamos o Log4J? Em caso afirmativo, em que medida (versão, distribuição) somos afetados pelo Log4Shell? O esforço necessário para responder a essa pergunta é um indicador de até que ponto você tem conhecimento sobre sua cadeia de suprimentos de software e se vale a pena usar ferramentas para ajudá-la.
Com relação às ferramentas, é importante esclarecer se se trata “apenas” da questão “estou afetado”. Se for esse o caso, ferramentas como snyk ou as opções integradas no GitHub e no GitLab ajudarão. Por outro lado, caso se deseje uma visão mais abrangente, existem outras soluções para captura e catalogação de artefatos de software. Ambos são comerciais e gratuitos. Do campo de código aberto, o Dependency Track é certamente o mais difundido aqui.
Em última análise, no entanto, deve-se observar que as lacunas de segurança são um argumento importante para o gerenciamento da cadeia de suprimentos de software - mas certamente não o único!
Mais em TrendMicro.com
Sobre a Trend Micro Como um dos principais fornecedores mundiais de segurança de TI, a Trend Micro ajuda a criar um mundo seguro para a troca de dados digitais. Com mais de 30 anos de experiência em segurança, pesquisa de ameaças globais e inovação constante, a Trend Micro oferece proteção para empresas, agências governamentais e consumidores. Graças à nossa estratégia de segurança XGen™, nossas soluções se beneficiam de uma combinação entre gerações de técnicas de defesa otimizadas para ambientes de ponta. As informações sobre ameaças em rede permitem uma proteção melhor e mais rápida. Otimizadas para cargas de trabalho em nuvem, endpoints, e-mail, IIoT e redes, nossas soluções conectadas fornecem visibilidade centralizada em toda a empresa para detecção e resposta mais rápidas a ameaças.