Uso de código aberto em infraestrutura crítica sob escrutínio

Vulnerabilidades graves de software de código aberto, como a falha encontrada em dezembro na biblioteca de registro Log4j, provavelmente aparecerão em testes de penetração por um longo tempo. Esses bugs não desaparecem porque, apesar da disponibilidade de patches e de recomendações sólidas de atualização, os administradores nem sempre estão cientes de onde esses componentes de código aberto se encontram dentro de aplicativos de software comerciais ou desenvolvidos internamente.

Isso é particularmente verdadeiro em ambientes industriais, onde o software legado continua a dominar, e a importância desses bugs é ainda mais ampliada porque, muitas vezes, o tempo de inatividade é inaceitável e os serviços essenciais não podem ser facilmente desligados para atualizações de software ou firmware. Em vez disso, as organizações ficam com poucas opções além de aplicar mitigações - se houver alguma disponível - na esperança de atenuar o impacto de uma exploração disponível publicamente.

Amanhã, representantes de vários provedores de serviços em nuvem, empresas de desenvolvimento de software e outros líderes tecnológicos devem se reunir na Casa Branca para discutir a prevalência e os riscos apresentados pelos componentes de software de código aberto. O Log4j provocou essa reação no governo Biden, mas isso já vem ocorrendo há algum tempo.

Código aberto é uma "preocupação fundamental para a segurança nacional

O governo tem priorizado a segurança cibernética da infraestrutura essencial desde os ataques públicos do ano passado contra a Colonial Pipeline e outras empresas industriais, e surgiram várias ordens executivas e mandatos específicos do setor exigindo mais visibilidade dos ativos que executam os serviços mais essenciais do país.

O assessor de segurança nacional da Casa Branca, Jake Sullivan, chegou ao ponto de chamar o uso de software de código aberto de"principal preocupação de segurança nacional". Além de ser uma preocupação a falta de visibilidade de onde o software de código aberto está inserido nos produtos comerciais, Williams acrescentou que muitos desses projetos são executados por "voluntários". A Apache Software Foundation mantém o Log4j e, em seu site, afirma que mais de 850 membros individuais e 8.200 committers colaboram com o software de nível empresarial criado e mantido pela fundação. Há mais de 300 projetos listados no site da Apache; não se sabe quantos membros e committers trabalham no Log4j, por exemplo.

Muitos projetos de código aberto têm poucos recursos e são mal financiados; esses desafios geralmente não vêm à tona a menos que uma vulnerabilidade crítica apareça. O Heartbleed, a vulnerabilidade de criptografia encontrada em 2014 no OpenSSL, evidenciou a falta de recursos para manter o OpenSSL funcionando, apesar do fato de o software estar presente em todos os lugares, desde softwares comerciais até smartphones e dispositivos industriais. Na época, havia uma equipe mínima mantendo o OpenSSL, lamentavelmente atrasada em relação às atualizações, mas fiel a manter o projeto no caminho certo. O Heartbleed colocou muitas empresas em risco e, de forma reativa, o setor foi forçado a criar grupos para auditar a base de código e canalizar dinheiro e recursos de desenvolvimento para o projeto.

A reunião de amanhã na Casa Branca é um passo concreto que o governo Biden está dando para avaliar proativamente os riscos apresentados pelo software de código aberto.

SBOM: uma importante ferramenta de gerenciamento de riscos

Em maio passado, foram tomadas as primeiras medidas para bloquear o desenvolvimento de software para códigos usados pelo governo federal.

Impulsionada pelo ataque à cadeia de suprimentos da Solarwinds, a administração emitiu uma ordem executiva que incluía uma seção proeminente sobre o aprimoramento da segurança da cadeia de suprimentos de software, incluindo a criação de diretrizes para avaliar as práticas de desenvolvimento seguro. Além disso, a EO determinou que uma lista de materiais de software (SBOM) fosse publicada em um site público para cada produto dentro da cadeia de suprimentos federal.

Os SBOMs são semelhantes aos rótulos de ingredientes em produtos alimentícios, por exemplo. Elas descrevem os componentes - e as relações entre esses componentes - usados na criação de software; os desenvolvedores geralmente compilam projetos usando códigos de várias fontes, incluindo projetos de código aberto, por exemplo.

Um SBOM permitiria ao comprador saber antecipadamente quais componentes compõem o software que está comprando, garantir que estejam atualizados e priorizar a resposta no caso de uma vulnerabilidade crítica. O governo expressou, por meio da ordem executiva, que os SBOMs são uma ferramenta crucial de gerenciamento de riscos e que, atualmente, não fazem parte do arsenal de um tomador de decisões.

OT não está imune a problemas de código aberto

Clarotyda Team82, descobriu vulnerabilidades que provam que a OT também pode ser muito afetada por vulnerabilidades de software de código aberto.

Vamos dar uma olhada em dois casos importantes:

OpenVPN:

As soluções de acesso remoto industrial nunca foram tão importantes para os negócios em ambientes industriais como desde o início da pandemia, há quase dois anos. Muitas são criadas com o OpenVPN em execução. O OpenVPN é a implementação de VPN mais comum usada para criar conexões seguras site a site em configurações roteadas ou em ponte, bem como em instalações de acesso remoto. Se você deseja criar um túnel seguro, não vai reinventar a roda, vai usar o OpenVPN.

A Equipe 82 examinou os clientes de acesso remoto industrial de quatro fornecedores que executam o OpenVPN: HMS Industrial Networks, Siemens, PerFact e MB connect line. As vulnerabilidades descobertas pela Equipe 82 permitiam a execução remota de código ou o estabelecimento de uma nova instância do OpenVPN com uma configuração arbitrária, permitindo que um invasor elevasse os privilégios.

Em ambos os cenários, um invasor poderia explorar um bug em um componente de código aberto amplamente utilizado para comprometer seriamente a integridade de uma conexão remota.

OpENer ENIP Stack:

O código aberto também pode estar no centro dos protocolos populares de comunicação industrial. Esses protocolos supervisionam como os sistemas de controle interagem com os dispositivos de campo, carregam novas configurações e comandos e fazem download de dados. A pilha OpENer ENIP implementa os protocolos ENIP e CIP que são executados em muitos produtos comerciais usados em empresas industriais.

No ano passado, a Team82 publicou um relatório revelando várias vulnerabilidades que poderiam ser usadas para travar dispositivos, executar códigos remotamente ou ler dados de um dispositivo.

O ENIP é o principal protocolo industrial; ele adapta o Protocolo Industrial Comum à Ethernet, permitindo a transmissão de dados de dispositivos entre diferentes aplicativos industriais. A visibilidade desses protocolos é essencial para manter a integridade dos dados enviados de e para os dispositivos industriais.

Recomendações

O desenvolvimento seguro de software entre projetos de código aberto continua sendo um grande desafio, que o governo federal parece reconhecer. Embora reacionária à vulnerabilidade do Log4j, a reunião de amanhã da Casa Branca deve servir como um impulso a mais para exigir visibilidade do software executado nos principais sistemas de infraestrutura crítica e a adesão a padrões mínimos de desenvolvimento seguro.

Os grandes recursos do governo federal podem levar as empresas a melhorar a análise de código, desenvolver SBOMs para ajudar a priorizar o gerenciamento de vulnerabilidades e melhorar a visibilidade de onde o código aberto está sendo executado dentro de sistemas críticos.

Caso contrário, vulnerabilidades como Log4j, Heartbleed e outras continuarão a aparecer, interromperão a continuidade dos negócios e permanecerão nos sistemas legados por muitos anos.