0
0
Anúncios antigos podem ser surpreendentes – anúncios de cigarro costumavam exibir suas propriedades benéficas à saúde, doces carregados de açúcar já foram anunciados como uma ajuda dietética e refrigerantes foram anunciados como uma alternativa ao leite para bebês. Nada disso voaria hoje, é claro, graças aos regulamentos. Os alimentos devem ser anunciados com mais responsabilidade e devem listar seus ingredientes claramente na embalagem, especialmente os alérgenos.
Listas de materiais de software (SBOMs) são como listas de ingredientes para software. Nenhum software é criado inteiramente, e um SBOM listará os blocos de construção usados para criá-lo. E assim como qualquer pessoa com alergia alimentar precisa ser capaz de examinar a lista de alimentos que foram colocados em sua refeição pronta para micro-ondas antes de comer, as empresas precisam saber não apenas qual software está em uso, mas qual software seu software está usando. .
A necessidade de SBOMs
Listas de materiais (também conhecidas como listas de componentes, também conhecidas como receitas de produtos) são comuns na fabricação. Um BOM é uma lista estruturada e padronizada de tudo o que é necessário para fabricar um produto, as quantidades e como obtê-las. Eles são vitais no planejamento de compras e na minimização de atrasos — nenhum fabricante eficiente quer ficar parado com armazéns cheios de componentes enquanto espera a chegada de peças vitais. É também o primeiro ponto de chamada se houver uma falha ou outro problema.
Os SBOMs funcionam de maneira semelhante. Um SBOM é uma lista de todos os componentes de código aberto e de terceiros presentes em um software, mas também mais do que isso: contém os números de versão, as licenças e o status do patch de cada componente. Assim como na fabricação, isso se torna um material de referência fundamental quando algo dá errado. Um fabricante que descobre um componente defeituoso pode dizer qual de seus produtos pode precisar ser recolhido. Uma empresa que faz uso de software de código aberto pode dizer imediatamente onde podem estar as vulnerabilidades se algo der errado.
A vulnerabilidade Log4Shell é um exemplo perfeito. Log4j foi usado, como o nome sugere, para registrar erros e eventos e comunicá-los aos administradores. Se alguém visitar um site e receber um erro 404, isso provavelmente será registrado pelo Log4j – se muitos deles estiverem acontecendo, isso indica um problema. Sua utilidade o tornou onipresente, e isso o tornou, perversamente, bastante obscuro – um software padrão usado em todos os lugares que ninguém realmente pensou. Quando foi revelado que o Log4j poderia ser usado para injetar código, isso significava que milhões de servidores poderiam ser atacados e controlados. O banco de dados de vulnerabilidade do NIST dá a ele uma classificação CVSS (Common Vulnerability Scoring System) de 10, a mais alta possível.
O conselho para manter tudo atualizado é bom, mas só vai até certo ponto. Diferentes tipos de software são atualizados em diferentes cadências, portanto, não havia garantia de que esperar por um patch fosse bom o suficiente. Também era possível atacar servidores que eram considerados internos e geralmente não vulneráveis a tais ataques, e provavelmente considerados menos vitais para correção.
Um SBOM é incrivelmente valioso nessa situação, dando às equipes de segurança um calculador prático e pronto, mostrando onde estão as vulnerabilidades quando elas surgem.
Aguardando regulamentação
Precisamos de SBOMs. A boa notícia é que os regulamentos que exigem SBOMs estão em andamento nos EUA e em outros lugares. O governo dos Estados Unidos tem exigido que as agências federais adotem SBOMs em um formato padrão, mas se isso é necessário é baseado na “criticidade do software”.
A UE tem a proposta de Lei de Resiliência Cibernética, e o Reino Unido está procurando trazer os provedores de serviços gerenciados para o escopo das leis atuais que já se aplicam à infraestrutura crítica.
Mas, como acontece com qualquer regulamentação, há muitos talvez e advertências à medida que passam pelos órgãos legislativos. Existe a preocupação de que os requisitos possam sufocar a inovação e que empresas menores possam ser prejudicadas por burocracia extra. Essas novas regras de segurança cibernética são uma resposta a ataques à cadeia de suprimentos, como o hack da SolarWinds, e têm maior probabilidade de atingir os grandes fornecedores que sustentam grande parte da TI hoje.
Nosso conselho é não esperar pela regulamentação e promulgar políticas que atuem como se já existissem exigências rígidas aos SBOMs. Aja como se um G-man empunhando um regulamento estrito chegasse sem avisar amanhã e exigisse que lhe mostrassem esta documentação.
Existem padrões em vigor que podem tornar isso mais simples – o formato SPDXdeve ser usado, a menos que haja um bom motivo para não fazê-lo, pois é bem conhecido e é um padrão ISO.
O mais importante é que seja utilizado um sistema onde seja possível encontrar rapidamente componentes que possam ter vulnerabilidades. A geração de SBOMs deve ser feita por meio de métodos de tempo de compilação, geralmente usando um pipeline de CI/CD, o que significa que o SBOM estará sempre atualizado. Deve ser gerado um para cada versão produzida, para que versões mais antigas que ainda possam ser utilizadas possam ser verificadas, se necessário.
Existe o risco de que exigir que os fornecedores entreguem seus SBOMs signifique expor seu molho secreto – os programas que eles usam para construir suas soluções, um problema potencial para a concorrência. Os regulamentos podem ir longe demais, e é possível que haja regulamentação ruim se a auto-regulação não for levada suficientemente a sério.
Nem os desenvolvedores nem as equipes de segurança podem esperar – eles precisam implementar e exigir SBOMs agora, normalizando-os antes do próximo grande hack. Não se trata apenas de segurança, trata-se de parceiros e clientes que confiam em sua capacidade de responder a eventos inesperados ou vulnerabilidades. Quando o próximo evento CVSS nível 10 chegar, a capacidade de dizer “não se preocupe, nós cuidamos disso” será inestimável.
FONTE: HELPNET SECURITY