Tipos de correções: um guia detalhado para equipes de segurança e DevOps

Principais conclusões

• Existem cinco tipos distintos de aplicação de patches – tradicional, virtual, de firmware, em tempo real e em nuvem/contêiner –, cada um com seu próprio perfil de tempo de inatividade, risco e conformidade.
• A maioria das equipes ainda recorre, por padrão, à estratégia de “aplicar patches e reiniciar”, o que deixa os sistemas vulneráveis por dias ou semanas enquanto as janelas de atualização se acumulam.
• A aplicação de correções em tempo real aplica correções no kernel e nas bibliotecas a sistemas em execução sem a necessidade de reinicialização, reduzindo o tempo de correção de semanas para horas.
• A estratégia correta de aplicação de patches depende dos seus requisitos de tempo de atividade, dos SLAs regulatórios e de quais camadas da sua pilha de tecnologia você realmente controla.

São 23h de um domingo. Alguém da sua equipe está acompanhando de perto uma janela de manutenção porque três servidores de produção precisam de um patch CVE para o kernel, e a única maneira segura de aplicá-lo – de acordo com o manual de 2014 – é reiniciar o sistema. O patch em si tem dois megabytes. O tempo de inatividade é de 40 minutos por host. Multiplique isso por uma frota de algumas centenas de servidores e toda essa “correção rápida de segurança” se transforma em um quarto de hora que você não recupera.

É por isso que os tipos de correção que você escolhe realmente fazem diferença. A abordagem correta pode reduzir o tempo de manutenção de horas para segundos — ou eliminá-lo completamente. A abordagem errada mantém você exposto a uma vulnerabilidade CVE conhecida por semanas, pois você não consegue autorização para reiniciar o sistema.

Alguns dos chamados métodos de “correção” nem sequer são correções de verdade. Este é o seu guia completo para entender as diferentes opções de correção disponíveis no mercado.

O que é a aplicação de patches em software?

A aplicação de patches de software é tanto um processo de TI quanto uma prática fundamental de segurança. Geralmente, é descrita como o processo de corrigir problemas ou adicionar recursos a um determinado sistema, por meio da adição ou substituição de componentes existentes por outros atualizados. Isso pode ser feito em diversos níveis, como a atualização de código no nível do subsistema, das dependências ou da funcionalidade central. Da mesma forma, é possível aplicar patches em aplicativos específicos, sistemas operacionais, drivers ou qualquer outro componente.

Embora o objetivo seja sempre ter uma versão mais atualizada do que quer que esteja sendo corrigido, a maneira como isso é feito é o que diferencia as diversas abordagens de aplicação de patches — e tratá-las como se fossem uma única categoria é o que faz com que as equipes acabem com vulnerabilidades não corrigidas há meses em ambiente de produção.

Assim como outros termos da área de TI, como “depuração”, o termo “patching” tem origem em um processo físico. Ele se referia à ação de tapar os orifícios nos cartões perfurados; ou seja, você “remendava” uma seção do código. Esse uso parece ter caído em desuso, então abordaremos as abordagens mais modernas.

A diferença entre um patch, uma atualização e uma versão completa

Antes de abordarmos os tipos de correção, vale a pena esclarecer uma questão terminológica que causa muita confusão na prática. Os termos “correção”, “atualização” e “versão completa” são usados de forma intercambiável — às vezes pela mesma pessoa na mesma conversa —, mas descrevem conceitos significativamente diferentes, especialmente quando se trata de definir o escopo do trabalho ou de conversar com um auditor de conformidade.

Uma regra prática razoável: se você conseguir descrever a alteração em uma frase, trata-se de um patch. Se vier acompanhado de notas de lançamento com mais de um parágrafo, trata-se de uma atualização. Se vier com um guia de migração, trata-se de um lançamento completo.

Uma coisa que a tabela não consegue mostrar: às vezes, os fornecedores rotulam as atualizações de forma equivocada para que pareçam menos impactantes. Uma “atualização menor” que, discretamente, troca o driver do banco de dados subjacente é, em termos de funcionalidade, mais próxima de uma versão completa. Leia o registro de alterações antes de confiar no rótulo.

Principais tipos de remendos: uma análise completa

Os tipos abaixo abrangem a grande maioria das situações com as quais a maioria das equipes de segurança e DevOps se deparará. Há alguma sobreposição — um patch de firmware também é um patch de segurança, e a aplicação de patches em tempo real se aplica tanto a servidores Linux tradicionais quanto a cargas de trabalho em contêineres. As categorias não são mutuamente exclusivas, mas cada uma delas descreve um mecanismo de entrega distinto, com seu próprio perfil operacional.

Correções tradicionais

É isso que a maioria das pessoas conhece como “patch”. Consiste em baixar versões atualizadas de um determinado software e, em seguida, substituir os arquivos correspondentes no disco pelas novas versões.

É relativamente simples de implementar e fácil de entender: você tem uma versão antiga de um determinado software que é substituída por uma nova versão, seja total ou parcialmente. É preciso reiniciar o aplicativo ou o sistema para que a nova versão entre em vigor, mas não há outros passos envolvidos. É claro que aí também reside a maior desvantagem — reiniciar aplicativos ou reiniciar sistemas inteiros é uma operação lenta que causa interrupções significativas em qualquer carga de trabalho em execução. Por causa disso, não é algo que possa ser feito de forma pontual, então geralmente ocorre no que se chama de “janela de manutenção” — um período de tempo pré-aprovado em que se espera que os sistemas apresentem problemas de disponibilidade ou desempenho.

Esse processo é demorado e tende a ultrapassar os prazos previstos em caso de problemas. De acordo com um relatório do Ponemon Institute patrocinado pela TuxCare, 56% das organizações levam de cinco semanas a um ano para corrigir vulnerabilidades críticas ou de alta prioridade – e mais de 55% relataram ter sofrido um incidente de segurança cibernética causado por um patch que já estava disponível, mas não havia sido aplicado. Esse atraso é, em grande parte, causado pelo agendamento da janela de alterações, e não pela instalação em si.

Use-o quando você tiver uma janela de manutenção aceitável, um ambiente de teste estável e nenhuma restrição de conformidade que exija uma correção mais rápida. Não confie nisso como sua única estratégia se estiver executando qualquer coisa que não possa suportar uma reinicialização regular.

Correção virtual

Trata-se de algo que tem a palavra “patching” no nome e, à primeira vista, parece fornecer resultados de correção, mas, na verdade, opera em um nível completamente diferente. Não há nenhuma substituição ou correção real de código no “patching virtual”. Ele consiste na implementação de detecção de ameaças no nível do firewall, bloqueando padrões de ataque conhecidos. Do ponto de vista do invasor, o ataque falha, de modo que ele pode supor que o sistema está corrigido quando, na verdade, não está.

Esse método de “correção” apresenta várias desvantagens: na verdade, o código corrigido não chega aos sistemas em nenhum momento; a proteção abrange apenas padrões de ataque conhecidos — o que desconsidera imediatamente problemas exclusivamente locais —; e pode ser burlado por modificações no tráfego de rede correspondentes a uma determinada ameaça.

Se as desvantagens não descartarem imediatamente essa abordagem, as vantagens incluem a ausência de interrupções (já que nada é realmente feito dentro de um sistema), a capacidade de uma única implantação abranger vários sistemas e a proteção imediata contra novas ameaças exclusivamente remotas à medida que elas surgem.

Encare o patch virtual como uma medida provisória, não como um objetivo final. Quando uma vulnerabilidade significativa é divulgada e sua equipe precisa de dias, em vez de semanas, para implementar a correção definitiva, um patch virtual proporciona um tempo valioso para respirar. Se ele ainda estiver em vigor seis meses após a divulgação, no entanto, você deixou de aplicar correções e passou a arriscar.

Use-o quando precisar mitigar uma vulnerabilidade CVE mais rapidamente do que levaria para aplicar a correção definitiva, ou se estiver utilizando um software em fim de vida útil que não recebe mais patches do fornecedor.

Atualização de firmware

A atualização de firmware é um caso específico da aplicação tradicional de patches, com a particularidade de que se está aplicando correções em código contido em mídias de armazenamento geralmente difíceis de atualizar – diretamente nos chips EPROM (memória de leitura exclusiva programável e apagável). Isso costumava ser a norma para os primeiros dispositivos inteligentes e dispositivos de IoT de primeira geração. O software era carregado na fábrica e raramente — ou quase nunca — recebia atualizações. Isso se devia, em parte, ao fato de que atualizações e segurança não eram preocupações prioritárias como são hoje, mas também porque a forma como o software era armazenado dificultava a atualização. Os dispositivos mais recentes têm o código, total ou parcialmente, gravado em mídias mais comuns, como SSDs, cartões SD ou similares, que são muito mais fáceis de modificar.

Quando o código era executado em chips que precisavam ser conectados a equipamentos de gravação especializados, com requisitos de software proprietário e cabos específicos, isso acrescentava uma camada de complexidade que tornava todo o processo muito pouco atraente para a maioria das equipes de TI. Como resultado, esses dispositivos simplesmente nunca recebiam nenhuma atualização ao longo de toda a sua vida útil. Infelizmente, muitos deles ainda estão em uso — servidores de impressão, câmeras IP e sensores de data center são bons exemplos de dispositivos que funcionam dessa maneira.

A aplicação de patches no firmware também é o tipo que apresenta maior risco operacional. Uma atualização malfeita do BIOS deixa o equipamento inutilizável, e a resposta quando se trata de reverter a alteração costuma ser “não dá”. Os fornecedores não são consistentes quanto à frequência com que lançam atualizações de firmware e à confiabilidade com que as testam — os fornecedores de servidores geralmente são confiáveis, mas no caso de hardware para IoT e de consumo, a história é outra.

Para dispositivos IoT e embarcados que rodam Linux, existe uma solução intermediária que vale a pena conhecer. O KernelCare IoT da TuxCare oferece a aplicação de patches no kernel sem necessidade de reinicialização para dispositivos ARM64 — com suporte a Raspberry Pi, Ubuntu e distribuições baseadas em Yocto em diversos chipsets, incluindo Arm Neoverse, NXP e AWS Graviton, além de integração com o Microsoft Azure IoT Hub para gerenciamento de frotas —, o que contorna totalmente o problema tradicional de atualização de firmware na camada do kernel.

Utilize-o em uma frequência definida – trimestralmente é razoável para a maioria das frotas –, sempre após testes em equipamentos representativos, e nunca pule a etapa de verificação pós-atualização.

Correção em tempo real

A correção dinâmica é o processo de modificar um código em execução e substituir seções ou funções com erros conhecidos por versões corrigidas dessas mesmas seções. Isso é feito inteiramente na memória e não exige que o aplicativo seja reiniciado para que as novas alterações sejam aplicadas. Num instante, o software contém um erro em uma função; no momento seguinte, uma versão corrigida dessa função já é utilizada em seu lugar.

Não há reinicializações, nem reinicializações do sistema, nem interrupções. Por isso, os patches podem ser implantados imediatamente — a operação não requer um intervalo de manutenção, o que permite uma resposta mais rápida a ameaças emergentes. Em vez de esperar semanas ou meses pela implantação de um patch, como na aplicação tradicional de patches, isso agora pode ocorrer em questão de horas ou até mesmo minutos após o patch estar disponível.

A complexidade adicional do patching dinâmico ocorre no momento da criação do patch. O patch precisa ser criado de forma que possa ser carregado no espaço de memória correto, utilizando os mesmos tamanhos de variáveis e alinhamentos do código original. Essa complexidade fica oculta para os usuários de uma solução de patching dinâmico — ela só é visível para o provedor do patch dinâmico.

Um subsistema de aplicação de patches em tempo real já é capaz de implementar patches no kernel do Linux há mais de 10 anos, e várias soluções diferentes foram criadas. O KernelCare, da TuxCare, é uma dessas soluções, responsável pela aplicação de patches em tempo real no kernel do Linux em todas as principais distribuições. O LibCare estende isso às bibliotecas críticas do espaço do usuário — incluindo OpenSSL e glibc, que sustentam a criptografia e as chamadas de sistema essenciais em praticamente todas as cargas de trabalho do Linux — sem exigir a reinicialização do serviço. Juntos, eles cobrem a superfície de ataque de maior risco em um servidor Linux sem precisar recorrer a uma janela de manutenção.

Existem também muitas variações de correção dinâmica, incluindo abordagens temporárias e permanentes, dependendo se o processo de correção dinâmica é implementado como uma solução provisória ou como uma alternativa mais permanente à correção tradicional.

Utilize-o quando você opera o Linux em qualquer escala significativa, executa cargas de trabalho regulamentadas com SLAs de correção rigorosos ou tem partes interessadas que tratam qualquer reinicialização não planejada como um incidente crítico.

Aplicação de patches em nuvem e contêineres

As cargas de trabalho em nuvem e em contêineres alteram o modelo de maneiras que vale a pena compreender claramente, pois os pressupostos que se aplicam aos servidores tradicionais não se aplicam da mesma forma.

Os contêineres são normalmente corrigidos por meio da recompilação da imagem e da implantação de uma nova versão — o contêiner antigo é substituído por um novo, que contém a correção. Na maioria dos fluxos de trabalho, não há, intencionalmente, nenhuma modificação no local de um contêiner em execução; a imutabilidade é o princípio de design, e é um princípio sólido. Isso significa, no entanto, que uma imagem base vulnerável pode persistir discretamente em muitos contêineres em execução se o processo de recompilação não for bem gerenciado.

Os ambientes em nuvem dividem as responsabilidades de acordo com o modelo de responsabilidade compartilhada. Com o IaaS, o provedor aplica patches no hipervisor e nos hosts físicos; você é responsável pelo sistema operacional convidado, pelo ambiente de execução e pela camada de aplicativos. Com o PaaS, o provedor cuida de uma parte maior da pilha. Com o SaaS, você se preocupa principalmente com agentes e integrações. Saber exatamente de qual camada você é responsável já é metade do caminho andado — equipes já passaram por situações desagradáveis ao presumir que “a nuvem cuida disso” para algo que o provedor explicitamente não cobre.

O que o modelo de contêiner não altera: o kernel do Linux subjacente ao ambiente de execução do contêiner ainda precisa receber patches. Trata-se de sistemas reais, executando kernels reais com vulnerabilidades CVE reais, e a aplicação de patches em tempo real se aplica a eles da mesma forma que a qualquer outro host Linux.

Use isso quando você executar o Kubernetes, o ECS ou qualquer plataforma de orquestração de contêineres. Combine a recompilação de imagens com a aplicação de patches em tempo real ou a aplicação tradicional de patches no sistema operacional do host subjacente — a abstração do contêiner não torna o kernel subjacente magicamente seguro.

Como escolher a estratégia correta de aplicação de patches

Existem muitas maneiras de lidar com a aplicação de patches, e nenhum método isolado abrange todas as situações. A escolha certa depende de uma combinação de fatores — alguns técnicos, outros organizacionais — que, juntos, levam você a adotar uma abordagem ou outra.

Algumas das variáveis mais importantes:

Requisitos de tempo de atividade: Se uma reinicialização de 5 minutos não for motivo de preocupação, a aplicação tradicional de patches atende à maioria dos casos. Se o tempo de inatividade não planejado for considerado um incidente crítico, a aplicação de patches em tempo real muda significativamente o cenário.

SLAs de correção: Estruturas como o PCI DSS e a HIPAA especificam com que rapidez os patches críticos devem ser aplicados. Se o seu SLA for de 30 dias e suas janelas de alteração forem mensais, você não tem margem para que nada dê errado.

Composição da pilha: As frotas com predominância de Linux são as que mais se beneficiam da aplicação de patches em tempo real. As frotas com Windows dependem da aplicação tradicional de patches, utilizando a aplicação virtual de patches como solução provisória. Dispositivos embarcados e de IoT precisam de atualizações de firmware, nas quais a maioria das equipes investe de forma crônica insuficiente.

Maturidade operacional: Ambientes de teste automatizados e procedimentos sólidos de reversão determinam quais estratégias são viáveis. Sem eles, cada tipo de patch apresenta mais riscos do que deveria.

Um quadro prático para situações comuns:

• Tempo de atividade inegociável, frota Linux → aplicação de patches em tempo real para o kernel e bibliotecas compartilhadas críticas; aplicação de patches tradicional para todo o restante, em um ritmo mais flexível
• Janelas de manutenção aceitáveis, ambiente homogêneo → a aplicação tradicional de patches com alto grau de automação atende à maioria das necessidades
• Preso a um software em fim de vida útil (EOL) que você ainda não pode substituir → a aplicação de patches virtuais, aliada a um monitoramento rigoroso, é a única solução provisória sensata
• A frota inclui servidores físicos, equipamentos de rede ou dispositivos IoT → destinar verba para a aplicação de patches de firmware como um programa independente, separado da aplicação de patches do sistema operacional

Para qualquer organização que tenha, mesmo que minimamente, a preocupação de manter seus sistemas, dados e usuários seguros, a aplicação de patches é uma das questões fundamentais que deve ser tratada tanto no nível estratégico quanto no operacional. Cada ambiente terá suas particularidades — certifique-se de escolher o processo adequado para a sua situação específica.

Ainda precisa reiniciar o computador para instalar o patch? Existe uma maneira melhory

Se o seu fluxo de trabalho atual é “agendar uma reinicialização, torcer para que nada dê errado e repetir no mês seguinte”, você está arcando com mais sobrecarga do que o necessário e aceitando um período de exposição mais longo do que deveria. A aplicação de patches em tempo real existe porque o modelo de “reinicialização como necessidade” não é uma lei física — é um hábito herdado de uma época em que não havia alternativa.

O KernelCare e o LibCare da TuxCare oferecem aplicação de patches em tempo real para kernels do Linux e bibliotecas compartilhadas críticas — incluindo OpenSSL e glibc — em todas as principais distribuições. Os mesmos servidores, sem reinicializações e sem necessidade de janelas de manutenção para a aplicação de patches de segurança. E se sua frota incluir dispositivos IoT ou embarcados, o KernelCare IoT estende essa mesma aplicação de patches sem reinicialização a dispositivos ARM64 que executam distribuições baseadas em Raspberry Pi, Ubuntu e Yocto.

Perguntas frequentes

Resumo

Nome do artigo

Tipos de correções: um guia detalhado para equipes de segurança e DevOps

Descrição

Conheça os diferentes tipos de aplicação de patches, incluindo patches de segurança, de sistema operacional e em tempo real. Entenda quando usar cada um deles e como manter os sistemas seguros.

Autor

Rohan Timalsina

Nome da editora

TuxCare

Logotipo da editora