Skip to content

5 Lições aprendidas ao implementar 100 milhões de patches

Com mais de 100 milhões de patches implementados, veja o nosso top 5 de lições ao implementar patches ao longo da década.

Uma história sobre patching

Era uma tarde fria de dezembro de 2008. Um cliente, um dos maiores pontos de venda do Reino Unido, sofreu uma brecha de segurança.

O vírus Down-n-up, também conhecido como Conficker, infectou um dos servidores remotos e se espalhou rapidamente através de praticamente todos os servidores e estações de trabalho. As 48 horas seguintes foram gastas na execução de um “Conficker killer” em todos os dispositivos seguidos de uma reinicialização. O vírus foi praticamente erradicado, porém, eles falharam em instalar os KB958644, KB957097 e o KB958687.

Então, logo em seguida, o vírus voltou.

Comparado as infecções recentes, o conficker não rouba ou não sequestra seus dados como o ransomware, mas lentamente drenava recursos que poderiam destruir o sistema operacional e forçar uma tela azul. Essa interrupção ao usuário final deveria ser resolvida o mais rápido possível.

A reação inicial do diretor de TI foi de preparar uma tarefa de patch para atualizar o ambiente. A ferramenta utilizada estava agendada para instalar tudo naquela noite. A estratégia não funcionou, e foi quando nós fomos chamados para resolver a situação, onde entramos com nossos serviços de gerenciamento de patch e sanamos o problema.

Após mais de 10 anos, 100 milhões de patches implementados e centenas de clientes levando a nossa marca dentro de seus ambientes, nenhum deles sofreu nenhum tipo de brecha.

Aqui estão nossas 5 maiores lições que aprendemos na última década em relação aos serviços de gerenciamento de patch.

 

1 – Patching é essencial mesmo que você tenha um antivírus instalado e atualizado.

Os experts da indústria estimam que o número de brechas aumentou em cerca de 60% em 2019, e que as infecções especificas de ransomware aumentaram em 90% resultando em U$11,5 bilhões.

Diversos diretores de T.I sênior, CIOs e CISOs acreditam que a proteção do seu próprio perímetro, incluindo proteção de firewall e antivírus/antispyware, manterá todo o ambiente seguro. Entretanto, é desta forma que o roubo de dados e a intrusão na rede e sistemas ocorrem. Uma vez que uma brecha apareça, a exploração sofisticada destas brechas é fácil de se fazer, mas extremamente difíceis de rastrear ou remediar.

Nós seguimos um experimento simples conduzido por um grupo de estudantes do Reino Unido. Eles montaram diversos laboratórios utilizando Windows, Linux e Mac OS protegidos com firewall e ferramentas de antivírus/antispyware, porém sem nenhuma atualização no sistema operacional. Todas as estações tinham acesso à internet através de um endereço IP roteado. Cada sistema foi deixado “do jeito que vieram” sem atualizações, patches ou hotfixes e ficaram ligados durante 720 horas, qualquer uma delas seria vítima de um ataque externo. Os resultados a seguir foram surpreendentes e assustadores ao mesmo tempo:

Leia também:  Patch Management Guia para compradores

Sistema Operacional

Exposta/Infectada

Notas

Windows 7

Sim

Infectada pelo Windows 2012

Windows 10

Sim

Infectada pelo Windows 2012

Windows Server 2012

Sim

Explorada usando RDP

Windows Server 2016

Não

Mac OS “Mojave”

Não

Linux Ubuntu 14

Não

Linux SUSE

Não

 

Antes da destruição do laboratório, evidência forense foi coleta para demonstrar que o RDP foi usado para exploração ransomware no Windows Server 2012 e em ambos os desktops virtuais Windows. Nenhum dos dispositivos Linux ou Mac OS foram impactados. Talvez se os experimentos tivessem durado mais, esses poderiam possivelmente ser infectados? O que podemos tirar deste experimento é que qualquer um pode ser uma vítima mesmo com proteção de firewall e antivírus/antispyware em funcionamento

2 – Realizando e registrando evidências de teste

Ninguém entende o medo de um gerente de TI quando eles ouvem a seguinte frase; “Tem alguém realizando as tarefas de patch agora?

Nós aprendemos que as atividades de patching devem ser feitas em uma plataforma transparente. Nós acreditamos que há uma alocação perfeita de recursos que devem ser usados para testar e documentar os testes. Isto leva a menos interrupção ao usuário final e um aumento de confiança.

O modelo a seguir é um exemplo do que esperamos performar rotineiramente em nossos clientes:

  1. Uma cópia de cada sistema operacional (com Service Packs únicos/ Feature Updates) que melhor exemplifica o ambiente real é preparado em um laboratório Virtual. Todas as variações devem ser testadas.
  2. Cada sistema operacional é reiniciado diversas vezes para garantir que toda atividade pós reinício é feita. Um dos patches que testamos em 2015 mudava o layout do teclado para Chinês. Isso só foi descoberto depois de diversas reinicializações, e caso não fosse encontrado, se tornaria um pesadelo para a equipe de suporte global. Este patch em particular foi removido das implementações.
  3. Todos os problemas são completamente investigados, mesmo que eles sejam vistos apenas uma vez.
  4. Todos os patches que contém arquivos de desinstalação são testados para garantir que a desinstalação funcione! Nem sempre confie no fabricante, esta é uma das nossas regras de ouro
  5. Qualquer patch que não tenha uma instalação é testado no mínimo duas vezes, esta é outra das nossas regras de ouro.

Todos os testes são documentados e devem ser concluídos antes de qualquer atividade subsequente. Quaisquer problemas encontrados durante a implementação, teste ou pós-reinício serão detalhados. Grande parte dos clientes irão querer ver essa evidência antes de iniciarem o processo de controle de alterações.

3 – Implementação

A implementação está a apenas alguns cliques de ser completa, certo? Na realidade, aqui é onde o conhecimento do ambiente que você está trabalhando é indispensável.

Você terminou o teste e sabe que os patches não irão interromper os usuários finais. Entretanto, o que você não sabe é como estes patches implementados “em massa” impactarão na sua rede, o tempo necessário para instalar e os requisitos do ambiente nas suas estações e servidores.

Aqui estão alguns dos requisitos de alto nível que você precisará ter ou saber:

  1. Listar quais patches estão faltando por ordem de severidade. Determine quais patches são os mais importantes. Caso você consiga, os liste também de acordo com a pontuação de risco do CVSS já que esta é a forma mais precisa de identificar a severidade disponível hoje. Mantenha seu ambiente seguro.
  2. Identifique quais patches são cumulativos. Você não precisa realizar todos os updates críticos caso eles já tenham sido repostos, torne sua implementação mais eficiente
  3. Calcule o tamanho dos patches. Há espaço livre no disco das suas estações e servidores? E a rede consegue suportar a implementação? Planejamento aumenta a confiança.
  4. Cronometre a instalação como parte do seu teste. Os usuários podem esperar tanto tempo? Usuários finais felizes é referência de um bom serviço.

4 – Mudança de gestão

Nossos clientes não possuíam controle de alterações em seus ambientes, somente clientes dos setores bancários, varejos e governamentais solicitaram um processo de aprovação formal para implementação e instalação dos patches. Mesmo em casos que não seja implementada no ambiente inteiro dos nossos clientes, o sucesso do nosso serviço é possível graças à seleção, classificação dos patches e cronograma para aplicação.

Estudos constataram que o gerenciamento de alterações normalmente é aplicado em mais de 80% do ambiente, e no caso da FTSE 100, é aplicado em 100% do ambiente. Nossa função é apresentar os patches que queremos implementar, os testes que realizamos com esses patches, os resultados desses testes e buscar a aprovação para iniciar um laboratório e em seguida o início do projeto de implementação dos patches. Isso acaba transferindo a responsabilidade, porém garante que o cronograma seja cumprido no tempo determinado. Você consegue imaginar uma implementação simultânea no Reino Unido e no Japão?

5 – Relatórios e percepção

O último passo, talvez o mais crítico deles, na sua estratégia de patching seria relatar o sucesso obtido.  É importante que os gerentes superiores vejam a cobertura dos patches em todo o ambiente e a duração do serviço. Caso você esteja sob contrato para implementar atualizações todo mês, mostre relatórios que possam provar isso. Nada alivia mais a preocupação da governança do que ver você provando mensalmente seus esforços com “serviço ao longo do tempo”

Texto em parceria com Syxsense

Conheça o Syxsense

Comente o que achou do artigo