0
0
Já faz mais de um ano desde que o hack da cadeia de suprimentos SolarWinds enviou ondas de choque através de milhares de organizações em todo o mundo, mas este terremoto de cibersegurança não acabou. Mais recentemente, vimos choques posteriores alimentados pelas vulnerabilidades Log4Shell e Spring4Shell, que impactaram as organizações que usam a biblioteca Log4j e a estrutura spring core.
Já tínhamos visto ataques na cadeia de suprimentos antes, mas 2021 foi o ano em que eles realmente decolaram. Como foi o caso dos ataques Spring4Shell e Log4j, o uso de soluções de código aberto aumentou o risco. Eles são onipresentes em quase todas as formas de desenvolvimento de software e muitas vezes desenvolvidos em velocidade, deixando lacunas na segurança. Isso significa que, se houver alguma vulnerabilidade dentro de componentes de código aberto, o impacto será enorme.
Na esteira do Log4Shell e do Spring4Shell, existem três lições-chave que as organizações devem aprender para que permaneçam seguras enquanto utilizam software de código aberto:
Detectando os riscos
Para desenvolver, gerenciar e manter uma cadeia de fornecimento de software com segurança, você deve entender e ter visibilidade de todos os links.
Para garantir a segurança, as empresas precisam de um inventário claro e uma compreensão verdadeira de todos os componentes de código aberto em uso. Você não pode confiar cegamente na procedência e segurança dos componentes do software. Se incidentes como Log4Shell, Spring4Shell e SolarWinds nos ensinaram alguma coisa, é que precisamos de mais consciência de todas as diferentes peças de software usadas dentro de uma organização.
Isso inclui como e onde eles foram desenvolvidos, bem como onde eles estão sendo usados em toda a empresa, de modo que se as vulnerabilidades forem descobertas o problema pode ser resolvido rapidamente para limitar os danos.
Não coma demais
O número dois da lista é a necessidade de se tornar à prova de choque. Ao desenvolver estruturas ou bibliotecas, é importante fazê-lo bem. Mas também é importante adotar uma abordagem mais simplista para que você não insegue sem saber introduzir vulnerabilidades.
Concentrar-se em fazer algumas coisas bem é melhor do que introduzir um monte de recursos mal. Quanto mais recursos houver, maior a probabilidade de haver uma vulnerabilidade crítica. Então, ao olhar para quais novos recursos você gostaria de adicionar aos produtos e serviços, pense cuidadosamente sobre se você precisa deles e apenas ligue recursos que você sabe que são essenciais.
Apesar da necessidade de se desenvolver rapidamente, as empresas precisam ter certeza de que estão tomando tempo para realmente pensar sobre quais características elas absolutamente precisam e por que – como qualquer coisa que seja excedente à exigência pode apenas deixar a porta aberta para vulnerabilidades.
Remova a labuta
Em terceiro lugar, as organizações precisam estar cientes das preocupações de corte cruzado ao projetar e desenvolver diferentes aplicações. Seja para registro, métricas, comunicações criptografadas ou cache, é importante pensar se essas preocupações em curso precisam ser tratadas dentro do aplicativo ou se podem ser externalizadas em vez disso.
Vamos dar um exemplo. Com o registro, muitas frameworks podem enviar logs para uma variedade de locais, incluindo arquivos de saída chamados stdout e serviços de alerta, pelos quais seu aplicativo é responsável. Mas há uma abordagem melhor e mais segura que você poderia tomar. Em vez disso, pense em fazer com que seu aplicativo envie logs para stdout e, em seguida, aproveite um serviço de coletor de registro, para enviar os logs para todos os locais finais necessários. Ao externalizar essas preocupações, há menos código e configuração para os desenvolvedores se preocuparem e, portanto, menos vulnerabilidades que podem entrar.
As consequências
O Log4Shell e o Spring4Shell só serviram para enfatizar a necessidade de as organizações tomarem medidas proativas para proteger seus ambientes. No entanto, isso só vai se tornar mais difícil à medida que a inovação se acelerar, criando cada vez mais identidades de máquinas para as empresas ficarem de olho.
Tentar monitorar e gerenciar todas essas identidades de máquina, ao mesmo tempo em que mantém o estoque de todos os componentes do software e garante que o desenvolvimento permaneça simples não será tarefa fácil. As organizações hoje em dia apenas não têm as habilidades e recursos para garantir que possam marcar todas essas caixas. Em vez disso, eles devem utilizar ferramentas de automação e segurança para garantir que essas vulnerabilidades sejam mantidas ao mínimo, de modo que as ondas de choque de ataques como aqueles que atingiram o Log4j não sejam sentidas tão amplamente.
FONTE: HELPNET SECURITY