Uma retrospectiva do Log4j, parte 4: 5 Lições aprendidas com o Log4j
Na parte 4 da série retrospectiva do Log4j,destacarei as principais conclusões. À medida que a busca para erradicar essa vulnerabilidade avançar, muitas outras lições serão descobertas. No entanto, já existem cinco conclusões fundamentais.
1. A nova norma
Tanto a complexidade do software quanto a taxa na qual os usuários finais exigem novos recursos continuam crescendo rápido e sem limites. Para satisfazer as necessidades dos usuários finais nos prazos necessários, os desenvolvedores devem contar com um conjunto de bibliotecas, ecossistemas de linguagem e infraestrutura e serviços de terceiros com crescimento rápido. Como resultado, porções cada vez maiores da funcionalidade de qualquer parte do software são compostas por componentes que os próprios desenvolvedores podem nunca ter tocado ou compreendido totalmente.
Em qualquer gráfico de dependência de software, as vulnerabilidades são herdadas dos nós folha ou do código e de serviços compartilhados, ascendentes ao nó raiz, ou do produto que está sendo programado. À medida que mais nós folhas são adicionados a um projeto, de acordo com o citado acima, o risco de uma vulnerabilidade também aumenta.
Tudo isso leva a uma conclusão inevitável: esses tipos de vulnerabilidades não só estão aqui para ficar, mas continuarão a se expandir em frequência e impacto.
Essa é a nova norma.
2. O risco é recursivo
Muitas vezes, pensamos de maneira incorreta sobre o risco relacionado aos sistemas, software e funções que podemos controlar diretamente. Organizações mais avançadas estão começando a avaliar o risco um nível acima; por exemplo, pedindo aos desenvolvedores para examinarem a confiabilidade de uma determinada biblioteca.
Mas, como os sistemas e softwares continuam a ser compostos por camadas e camadas de código de terceiros, as organizações terão que, cada vez mais, avaliar não apenas o risco de uma determinada biblioteca ou parceiro, mas também as práticas dessa comunidade de desenvolvimento ou fornecedor, para garantir que eles também estejam examinando suas dependências.
Cada nó na árvore de dependência e na cadeia de fornecimento deve ser avaliado por você, seus parceiros e/ou pela respectiva comunidade de desenvolvimento para determinar se os níveis de risco toleráveis foram atendidos.
3. A visibilidade desbloqueia a velocidade
Mesmo com as avaliações de riscos acima em vigor, as vulnerabilidades ocorrerão. Devemos aceitar esse fato. A questão é como podemos abordar a situação de maneira mais eficaz quando ela acontecer e não como podemos evitá-la completamente.
Para isso, a visibilidade é fundamental. Muitas organizações têm dificuldades com a correção porque não sabem quais máquinas foram afetadas primeiro. As empresas devem ter sistemas instalados para dar visibilidade ao que está sendo executado no data center e na nuvem.
Quanto mais abrangente e precisa for a visibilidade, mais rápida será a reação de uma organização e a correção dos ativos necessários.
4. Filtre o óbvio
Muitas vulnerabilidades só podem ser atacadas por meio de uma cadeia de exploração. Cortar qualquer parte da cadeia é, muitas vezes, suficiente para evitar a exploração completa. Como resultado, os sistemas que filtram ataques anteriores e óbvios são essenciais.
As organizações devem priorizar os seguintes sistemas:
- EPP (Plataformas de proteção de ponto de extremidade)
Protege os pontos de extremidade contra softwares mal-intencionados conhecidos.
WAF (Web Application Firewalls)
Protege as aplicações Web de cargas mal-intencionadas conhecidas e de agentes de ameaça. Considere a melhor proteção Kona da Akamai.
Firewall DNS
Evita que os pontos de extremidade visitem domínios mal-intencionados e filtra cargas de DNS mal-intencionadas. Considere a solução Akamai Enterprise Threat Protection.
SWG (Gateway seguro da Web)
Protege os pontos de extremidade contra o download de malware e a visita a websites mal-intencionados na Internet. Considere a solução Akamai Enterprise Threat Protection.
MFA (Autenticação multifator)
Reduz o risco de roubo de credenciais, permitindo o acesso à empresa onde a cadeia de exploração pode ser entregue. Considere a Akamai MFA.
Segmentação baseada em identidade
Restringe a comunicação do software e dos sistemas com apenas máquinas necessárias para concluir as tarefas. Considere a segmentação da Akamai Guardicore.
ZTNA (Acesso de rede Zero Trust)
Limita o impacto de usuários finais infectados entrando na rede. Considere o Akamai Enterprise Application Access.
5. O menor privilégio ainda é o mais importante
Finalmente, as organizações devem adotar totalmente o princípio do menor privilégio. Bloqueie servidores, máquinas e software para que eles possam alcançar apenas os sistemas necessários para executar suas tarefas.
Por exemplo, muitos dos sistemas que fazem chamadas LDAP de saída como parte da exploração do Log4j nunca tiveram a necessidade de utilizar o LDAP. Esses sistemas devem ter acesso firewall ao LDAP. Outro exemplo: Se um serviço atender apenas a solicitações de entrada, bloqueie as conexões de saída.
Ao aplicar os princípios de menor privilégio a todos os sistemas e softwares sob seu controle, você pode reduzir bastante a superfície de ameaça quando surgir uma vulnerabilidade e, em muitos casos, interromper a cadeia de ataque antes que você seja afetado.
Saiba mais
Agradecemos por chegar até o final desta série. Embora esta série de blogs termine aqui, nossa pesquisa e proteção dos clientes contra vulnerabilidades continua. Não hesite em entrar em contato com a Akamai se quiser saber mais sobre nossas recomendações para a mitigação do Log4j e outras ameaças.
