Recuperando-se de um terremoto de segurança cibernética: as lições que as organizações devem aprender
Já tínhamos visto ataques à cadeia de suprimentos antes, mas 2021 foi o ano em que eles realmente decolaram.
Já faz mais de um ano desde que o hack da cadeia de suprimentos da SolarWinds enviou ondas de choque a milhares de organizações em todo o mundo, mas esse terremoto de segurança cibernética ainda não acabou. Mais recentemente, vimos réplicas alimentadas pelas vulnerabilidades Log4Shell e Spring4Shell , que afetaram as organizações que usam a biblioteca Log4j e a estrutura Spring Core.
Como foi no 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 geralmente desenvolvidos em velocidade, deixando lacunas na segurança. Isso significa que, se houver alguma vulnerabilidade nos componentes de código aberto, o impacto será enorme.
Na esteira do Log4Shell e do Spring4Shell, há três lições importantes que as organizações devem aprender para se manterem seguras ao utilizar software de código aberto:
Identificando os riscos
Para desenvolver, gerenciar e manter com segurança uma cadeia de suprimentos de software, você deve entender e ter visibilidade de todos os links.
Para garantir a segurança, as empresas precisam de um inventário claro e um verdadeiro entendimento de todos os componentes de código aberto em uso. Você não pode confiar cegamente na procedência e segurança dos componentes de software. Se incidentes como Log4Shell, Spring4Shell e SolarWinds nos ensinaram alguma coisa, é que precisamos de mais conhecimento sobre todos os diferentes softwares usados em uma organização.
Isso inclui como e onde eles foram desenvolvidos, bem como onde estão sendo usados em toda a empresa, para que, se forem descobertas vulnerabilidades, o problema possa ser resolvido rapidamente para limitar os danos.
Não complique demais
O número dois da lista é a necessidade de se tornar à prova de choque. Ao desenvolver frameworks ou bibliotecas, é importante fazê-lo bem. Mas também é importante adotar uma abordagem mais simplista para não introduzir vulnerabilidades inadvertidamente.
Concentrar-se em fazer algumas coisas bem é melhor do que introduzir muitos recursos mal. Quanto mais recursos houver, maior a probabilidade de haver uma vulnerabilidade crítica. Portanto, ao analisar quais novos recursos você gostaria de adicionar aos produtos e serviços, pense cuidadosamente se você precisa deles e ative apenas os recursos que você sabe que são essenciais.
Apesar da necessidade de desenvolvimento rápido, as empresas precisam ter certeza de que estão dedicando tempo para realmente pensar sobre quais recursos eles realmente precisam e por quê – já que qualquer coisa que seja excedente aos requisitos pode deixar a porta aberta para vulnerabilidades.
Remova a labuta
Em terceiro lugar, as organizações precisam estar cientes das preocupações transversais ao projetar e desenvolver diferentes aplicativos. Seja para registro, métricas, comunicações criptografadas ou armazenamento em cache, é importante pensar se essas preocupações contínuas precisam ser tratadas no aplicativo ou se podem ser externalizadas.
Vamos dar um exemplo. Com o log, muitas estruturas podem enviar logs para vários 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ê pode adotar. Em vez disso, pense em fazer com que seu aplicativo envie logs para stdout e, em seguida, aproveite um serviço de coletor de logs 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 surgir.
As consequências
Log4Shell e Spring4Shell serviram apenas 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 acelera, criando cada vez mais identidades de máquina para as empresas ficarem de olho.
Tentar monitorar e gerenciar todas essas identidades de máquina, mantendo o estoque de todos os componentes de software e garantindo que o desenvolvimento permaneça simples, não será tarefa fácil. Hoje em dia, as organizações simplesmente carecem de 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 reduzidas ao mínimo, de modo que as ondas de choque de ataques como os que atingiram o Log4j não sejam tão amplamente sentidas.
