0
0
Sempre houve uma compensação em TI entre o envio de novos recursos e funcionalidades versus o pagamento de dívidas técnicas, o que inclui coisas como confiabilidade, desempenho, testes… e sim, segurança.
Nesta era do “ship fast and break things”, acumular dívidas de segurança é uma decisão que as organizações tomam voluntariamente. Toda organização tem tarefas de segurança recheadas em suas listas de pendências do Jira para “algum dia” — coisas como implantar patches de segurança e executar as versões mais recentes e estáveis de linguagens e estruturas de programação. Fazer a coisa certa leva tempo, e as equipes adiam intencionalmente essas tarefas porque estão priorizando novos recursos. Grande parte do trabalho do CISO é reconhecer os momentos em que as dívidas de segurança devem ser pagas.
Uma coisa que tornou a exploração do Log4j tão alarmante para os CISOs foi a percepção de que havia essa enorme dívida acumulada que nem estava em seu radar. Ele expôs uma classe oculta de lacunas de segurança entre projetos de código aberto e os ecossistemas de criadores, mantenedores, gerenciadores de pacotes e organizações que os usam.
A segurança da cadeia de suprimentos de software é um item de linha único no balanço da dívida de títulos, mas os CISOs podem montar um plano coerente para pagá-la.
Uma nova classe de vulnerabilidade
A maioria das empresas ficou muito boa em bloquear sua segurança de rede. Mas há toda uma classe de explorações que são possíveis porque os sistemas de compilação do desenvolvedor e os artefatos de software que eles aproveitam para escrever aplicativos não têm um mecanismo de confiança ou cadeia de custódia segura.
Hoje, qualquer pessoa com bom senso sabe não pegar um pen drive aleatório e conectá-lo ao seu computador devido aos riscos de segurança. Mas há décadas, os desenvolvedores baixam pacotes de código aberto sem nenhuma maneira de verificar se eles são seguros.
Os maus atores estão capitalizando esse vetor de ataque porque é o novo fruto de baixa suspensão. Eles percebem que podem obter acesso através desses buracos e, uma vez dentro, girar para todos os outros sistemas que têm dependências de qualquer artefato inseguro que eles usaram para obter entrada.
Pare de cavar bloqueando sistemas de compilação
O ponto de partida fundamental para os CISOs, endossado em materiais como o guia do desenvolvedor “Securing the Software Supply Chain”, é começar a usar estruturas de código aberto como o Secure Software Development Framework (SSDF) do NIST e o Supply Chain Levels for Software Artifacts (SLSA) do OpenSSF. Essas são basicamente etapas prescritivas para bloquear sua cadeia de suprimentos. SLSA Nível 1 é usar um sistema de compilação. O nível 2 é exportar alguns logs e metadados (para que você possa procurar coisas mais tarde e responder a incidentes). O nível 3 deve seguir uma série de práticas recomendadas. Nível 4 é usar um sistema de compilação realmente seguro. Seguindo esses primeiros passos, os CISOs podem criar uma base sólida para a construção de uma cadeia de suprimentos de software segura por padrão.
As coisas ficam mais sutis à medida que os CISOs pensam sobre políticas sobre como as equipes de desenvolvedores adquirem software de código aberto em primeiro lugar. Como os desenvolvedores sabem quais são as políticas de sua empresa para o que é considerado “seguro”? E como eles sabem que o código aberto que estão adquirindo (que constitui a grande maioria de todos os softwares usados pelos desenvolvedores nos dias de hoje) é realmente inviolável?
Ao bloquear sistemas de compilação e criar um método repetível para verificar a procedência de artefatos de software antes de trazê-los para o ambiente, os CISOs podem efetivamente parar de cavar um buraco mais profundo para sua organização em dívidas de segurança.
Que tal pagar dívidas antigas de segurança da cadeia de suprimentos de software?
Depois de parar de escavar bloqueando suas imagens base e criar ambientes, agora você precisa atualizar seu software e corrigir suas vulnerabilidades, incluindo versões de imagem base.
Atualizar software e aplicar patches em CVEs é super tedioso. É chato, é demorado, é uma tarefa, é trabalho. É o “coma seus vegetais” da cibersegurança. Pagar essa dívida requer uma colaboração profunda entre CISOs e equipes de desenvolvimento. Também é uma oportunidade para ambas as equipes concordarem com ferramentas e processos mais seguros e produtivos que podem ajudar a tornar a cadeia de suprimentos de software de uma organização segura por padrão.
Assim como algumas pessoas não gostam de mudanças, algumas equipes de software não gostam de atualizar suas imagens de base de contêiner. A imagem base é a primeira camada de aplicativos de software baseados em contêiner. Atualizar uma imagem base para uma nova versão às vezes pode quebrar o aplicativo de software, especialmente se houver cobertura de teste inadequada. Assim, algumas equipes de software preferem o status quo, essencialmente vagando indefinidamente em uma versão de imagem base de trabalho que provavelmente está acumulando CVEs diariamente.
Para evitar esse acúmulo de vulnerabilidades, as equipes de software devem atualizar as imagens com frequência com pequenas alterações e usar práticas de “teste em produção”, como lançamentos canários. O uso de imagens de contêiner reforçadas, de tamanho mínimo e construídas com metadados críticos de segurança da cadeia de suprimentos de software, como listas de materiais de software (SBOMs), procedência e assinaturas, pode ajudar a aliviar a dor demorada do gerenciamento diário de vulnerabilidades em imagens base. Essas técnicas encontram o equilíbrio certo entre se manter seguro e garantir que a produção não caia.
Comece a pagar à medida que avança
O que é excepcionalmente desagradável sobre a dívida de segurança é que, quando você apenas a arquiva por “algum dia”, ela normalmente se levanta quando você está mais vulnerável e menos pode pagá-la. A vulnerabilidade Log4j surgiu pouco antes do movimentado ciclo de e-commerce de fim de ano e paralisou muitas equipes de engenharia e segurança no ano seguinte. Nenhum CISO quer ter surpresas de segurança escondidas à espreita.
Todo CISO deve fazer um investimento mínimo em sistemas de compilação mais seguros, métodos de assinatura de software para estabelecer a procedência do software antes que os desenvolvedores o tragam para o ambiente e imagens de base de contêiner mínimas e reforçadas que reduzam a superfície de ataque na base do software e dos aplicativos.
Aprofundando-se nessa enorme dívida de segurança da cadeia de suprimentos de software, os CISOs enfrentam um enigma de quanto estão dispostos a fazer com que seus desenvolvedores paguem à medida que avançam (atualizando continuamente imagens base e software com vulnerabilidades) versus adiando essa dívida e alcançando um nível aceitável de vulnerabilidade.
FONTE: DARK READING