0
0
As empresas estão enfrentando duas grandes verdades este ano: mais regulamentação de segurança cibernética e menos recursos.
Para o primeiro, está na hora. A segurança cibernética precisa de requisitos básicos e as regulamentações governamentais podem ser uma função de imposição útil. É encorajador ver um foco renovado em áreas que precisam de atenção real, especialmente a segurança da cadeia de suprimentos de software. Considerando o último, isso significa que as empresas enfrentarão uma escalada íngreme pela frente para implementar essas novas regulamentações em um ano de incerteza econômica. No entanto, os regulamentos estão aqui, mais regulamentos estão chegando e as empresas precisam se adaptar.
Em um artigo recente , discuti alguns problemas com o formato de lista de materiais de software (SBOM) como padrão, que inclui:
- Requisitos x campos opcionais
- Completa falta de consideração de proveniência
Mas este ano, o maior obstáculo será a adoção.
O problema de adoção do fornecedor de software
A ACMECorp é um exemplo de empresa que produz produtos de software. Vamos nos referir a um de seus produtos como “Anvil” e seus clientes como “Clientes”.
Os clientes querem que a ACMECorp libere seus SBOMs para Anvil para que possam entender se são afetados por problemas de cadeia de suprimentos de software, vulnerabilidades ou riscos de licença. Os clientes também querem ser capazes de entender rapidamente se forem afetados à medida que surgem novos problemas.
Os órgãos reguladores querem exigir que a ACMECorp libere SBOMs para que os clientes possam ser melhor informados. A ACMECorp pode muito bem quererfornecer essas informações aos clientes também, mas esse é um empreendimento enorme.
Para todos os produtos de software, a ACMECorp agora precisará:
- Identifique todos os componentes de software usados como dependências. Isso é no mínimo dezenas e no máximo dezenas de milhares de componentes de software individuais.
- Identifique todos os possíveis problemas de segurança. Isso inclui uma auditoria de segurança de um produto e todas as suas dependências.
- Investigue cada possível problema de segurança e determine a resposta da ACMECorp, que varia entre “temos que corrigir isso agora” e “não aplicável”. A análise resultante da equipe de segurança de software encarregada de realizar esse trabalho inevitavelmente passará por equipes de advogados para determinar a exposição e o risco. Isso é crucial, porque a ACMECorp precisará dessas informações para:
- Levantar um novo departamento para lidar com a enxurrada de perguntas e desafios inevitáveis dos Clientes às respostas desenvolvidas.
- Libere SBOMs para clientes com o mínimo de detalhes possível para proteger a propriedade intelectual e limitar a exposição.
- Faça todo o processo novamente para cada versão lançada, perpetuamente, e mantenha registros históricos.
É um trabalho pesado, mas a ACMECorp precisará ter uma versão acima (ou pelo menos um começo) que espera que os clientes aceitem.
O problema da adoção do cliente
Os clientes que desejam consumir o SBOM da Anvil (e centenas ou milhares de outros SBOMs) agora têm uma enorme carga de trabalho adicional para adotar qualquer tecnologia.
As empresas já têm um problema de gerenciamento de vulnerabilidades e isso multiplicará o fardo. Como o SBOM é um mecanismo de auto-relato, os clientes não estarão inclinados a simplesmente confiar em um SBOM como uma fonte oficial de verdade. Em vez disso, eles exigirão que suas equipes já sobrecarregadas de aplicativos, segurança de produtos e jurídicos encontrem maneiras de validar os SBOMs da ACMECorp após cada lançamento.
Vamos apontar para o melhor
Sou otimista quanto aos objetivos dos SBOMs. Devemos ter um inventário completo e atualizado dos componentes usados em um produto de software. Devemos entender as implicações dos eventos e problemas de segurança e como eles afetam empresas, governos e usuários. Minha esperança é que possamos trabalhar juntos para construir um processo muito melhor do que temos com a iteração atual do SBOM.
Primeiro, devemos nos livrar da ideia de que simplesmente compartilhar dados de fornecedor para cliente resolverá os desafios que a SBOM espera enfrentar. Como descrevi acima, é garantido apenas para fazer trabalho adicional. Em vez disso, devemos pensar em como podemos compartilhar atestados em dados da cadeia de suprimentos de software.
Os fornecedores querem mostrar aos clientes que a postura de segurança de seus produtos é bem defendida. Os clientes querem ter a garantia de que a postura de segurança de produtos e serviços de terceiros esteja alinhada com seu modelo de ameaça e tolerância a riscos. Esses objetivos são alcançados interpretando os dados da cadeia de suprimentos de software e respondendo a perguntas relevantes para os objetivos. O contexto em torno dos dados é fundamental para esses resultados.
Uma grande quantidade de metas de segurança que os fornecedores e clientes esperam atender pode ser codificada e, em seguida, construída em políticas que podem ser acordadas pelas relações fornecedor-consumidor. Os testes ou atestados para essas políticas podem ser de código aberto, com a colaboração dos setores de segurança e desenvolvimento. Isso permitirá uma compreensão aberta do valor dos atestados e de seus pontos fracos que podem ser melhorados. Ele pode nos fornecer uma estrutura compartilhada para interpretar o risco da cadeia de suprimentos de software.
Grupos de atestados na forma de uma política podem ser testados rapidamente à medida que os fornecedores desenvolvem software para planejar os requisitos de estado final. Os clientes podem usar isso para entender rapidamente o risco da cadeia de suprimentos de software do produto de um fornecedor. Isso pode significar optar por uma versão local hospedada em um ambiente controlado ou requisitos de contrato para melhor atender às necessidades do cliente, mas oferece aos fornecedores e clientes uma taxonomia comum para um melhor alinhamento entre si.
Atestados e políticas nos permitem criar efetivamente diretivas de conformidade de forma que os fornecedores possam gerenciar durante o ciclo de vida de desenvolvimento de produtos e softwares. As alterações nos atestados podem ser agendadas e mapeadas sem pilhas de reuniões para coordenar questões individuais. Essas diretrizes de conformidade podem ser avaliadas rapidamente para entender o impacto regulatório, que sabemos estar no horizonte de qualquer maneira . Esses atestados podem se estender para mostrar transparência e proveniência dos dados do fornecedor fornecidos como entrada. No geral, isso nos dá o terreno comum necessário para construir confiança.
Finalmente, uma grande parte deste processo pode ser automatizada . Podemos concentrar com muito mais eficiência o tempo de nossas equipes de segurança e desenvolvimento onde for necessário, em vez de preparar e consumir um fluxo interminável de despejos de dados SBOM.
Um brinde ao ano da SBOM. Estamos juntos nessa.
FONTE: DARK READING