Por Sergio Fernández, Technical Account Manager da Qualys para Portugal e Espanha
A correção de problemas de segurança e potenciais vulnerabilidades de software é uma das formas mais rápidas de melhorar a segurança e prevenir ataques. É um processo padrão para as equipas de segurança e deveria facilitar o trabalho de todos os envolvidos. No entanto, muitos dos problemas de segurança que vemos serem explorados continuam a ser vulnerabilidades de software conhecidas. No nosso Top 20 Security Vulnerability Research deste ano, as cinco explorações mais comuns incluem um problema de abuso de privilégios no protocolo Zerologon, problemas de execução remota de código (RCE) no Microsoft Office e no Wordpad de 2017 e até um RCE com os controlos comuns do Microsoft Windows de 2012. Estes problemas ainda existem e foram alvo de ameaças este ano.
Então, porque é que estes problemas antigos ainda estão presentes nos sistemas de produção anos depois de terem sido lançados os patches, e porque é que não foram corrigidos? O que está a atrasar as equipas de TI em relação a esta acumulação de vulnerabilidades e como podem as equipas melhorar os seus processos para se anteciparem a estes problemas no futuro?
A resposta a esta questão é que o mundo real é mais complicado. Embora se queiram aplicar medidas corretivas, há outras coisas que se podem interpor no caminho. Alguns destes problemas comuns continuam a existir porque a atualização vai impedir uma funcionalidade que é necessária para o negócio. Outras correções requerem um período de inatividade para serem implementadas e o sistema em causa é difícil de colocar offline. Outras ainda estão enraizadas nos sistemas e a equipa pode ter de implementar vários patches, passos de remediação e uma reinicialização dos sistemas para considerar a atualização completa.
Melhorar os seus processos de correção
Para ultrapassar estes obstáculos, há várias medidas que pode tomar para melhorar as suas taxas de sucesso em matéria de correção e impedir que os problemas voltem a surgir. Eis cinco passos que pode dar:
1. Rever as imagens e os modelos do sistema
Para facilitar a gestão dos seus sistemas de TI, normalmente há um conjunto de imagens de base que utiliza como padrão. Essas imagens podem facilitar a implementação de novos endpoints ou servidores na cloud, já que para as aplicações executadas em containers em ambientes de cloud, essas imagens são essenciais como parte do seu pipeline de implementação. No entanto, estas imagens também têm de ser mantidas atualizadas, ou podem introduzir vulnerabilidades de software antigo nos seus ambientes existentes. Verificar regularmente as imagens gold e a biblioteca de contentores de software quanto a potenciais problemas é uma prática recomendada a adotar, uma vez que pode evitar que os problemas entrem em produção.
2. Automatize os seus processos de implementação de patches para softwares menos críticos ou de baixo risco
O seu parque de aplicações incluirá uma mistura de diferentes softwares e serviços – alguns deles serão críticos para o funcionamento da sua organização, enquanto outros serão menos importantes ou onde não se espera que os patches sejam problemáticos. Para estas aplicações de baixo risco, a implementação de atualizações deve ser automatizada tanto quanto possível para reduzir a carga da sua equipa. A implementação automatizada de patches para estas aplicações irá normalmente remover muitas atualizações de terceiros da lista, e permite que a sua equipa se concentre em testar patches para as aplicações mais críticas. Isto deverá poupar tempo e eliminar muitas das atualizações que, de outra forma, seriam adiadas ou atrasadas por períodos mais longos.
3. Verifique a exatidão das contagens de vulnerabilidades
Numa empresa, havia uma lista de vulnerabilidades que parecia nunca diminuir, por muito que a equipa trabalhasse ou por muitas atualizações que fossem implementadas. Esta situação chegou a um ponto crítico para a sua equipa, pois estava a afetar o seu moral e desempenho. A equipa de segurança decidiu rever a situação e chegar ao fundo do problema. O que descobriram foi surpreendente: a equipa estava, na verdade, a fazer um trabalho fantástico. O problema era que a lista de vulnerabilidades não era exata.
Pode haver várias razões para este problema, por exemplo, pode haver ambientes de trabalho virtualizados que são reiniciados sempre que um utilizador abre uma sessão, o que pode fazer com que não sejam implementadas as atualizações mais recentes. Também poderá haver ativos que foram desativados e já não estão a funcionar em produção, mas que continuam a ser contabilizados para a contagem de vulnerabilidades. Qualquer que seja a razão, isto pode ajudá-lo a manter a contagem de vulnerabilidades realista e a melhorar o desempenho.
4. Rever o que está a causar o problema
A contagem de vulnerabilidades de software depende do total de softwares que foram implementados. Assim, para além de verificar as vulnerabilidades existentes, pode também verificar se esse software ainda é necessário nos dispositivos ou se pode ser removido.
Por exemplo, uma empresa teve um problema com versões de navegador web que foram implementadas e que estavam desatualizadas. No entanto, estes browsers estavam instalados em servidores que não precisavam de ter o software. A desinstalação deste software reduziu o número de implementações e eliminou a necessidade de gerir esse software específico nesse lote de ativos no futuro, reduzindo o problema em geral. Da mesma forma, outra organização descobriu que tinha várias versões de Java instaladas nos seus endpoints; ao remover as versões mais antigas e desnecessárias das suas máquinas, reduziu para metade a pontuação geral de risco da organização.
5. Garantir que as atualizações são concluídas
Concluir a implementação de um patch é, por vezes, mais complexo do que simplesmente lançar uma atualização. Para concluir o processo, pode ser necessário reiniciar o sistema e isto pode ser um problema quando a aplicação é crítica para o negócio ou tem de funcionar sem interrupção. Quando o sistema é responsável pela rentabilidade do negócio, pode ser difícil conseguir que o tempo de inatividade seja autorizado.
Para ajudar nesta situação, é importante fornecer informações sobre o contexto de ameaças para esta aplicação e a respetiva atualização. Quando se tem de justificar uma mudança na parte mais lucrativa da empresa, isto pode ser difícil; em vez disso, analisar o risco e o potencial impacto pode ajudar a mudar a predisposição da empresa para corrigir o risco em vez de continuar com sistemas inseguros.
Ao combinar estes passos, pode melhorar, em geral, a eficácia e a eficiência dos seus esforços de correção e aplicação de patches. Ao mesmo tempo, pode educar a empresa sobre a forma como pode reduzir o risco. Com tantos problemas potenciais a ter em conta, a utilização da automatização também o pode ajudar a antecipar-se aos problemas.