Gestão de Patches em OT: Priorizar Antes de Atualizar

Em ambientes industriais, corrigir uma vulnerabilidade nem sempre significa instalar imediatamente a atualização mais recente.

Sistemas OT e ICS possuem requisitos específicos de disponibilidade, desempenho, confiabilidade e segurança física. Muitos equipamentos permanecem em operação por longos ciclos de vida, dependem de softwares legados ou possuem janelas restritas de manutenção.

Nesse contexto, uma atualização aplicada sem avaliação prévia também pode introduzir risco.

O NIST reconhece essa particularidade em seu guia de segurança para OT. A aplicação de patches pode depender da validação do fabricante, exigir testes prévios ou demandar uma interrupção operacional que a organização não pode realizar naquele momento. Quando a correção não é viável, controles compensatórios podem ser necessários.

Por isso, em 2026, uma estratégia madura não começa pela pergunta:

“Quais patches ainda precisamos instalar?”

Ela começa por outra:

“Quais vulnerabilidades representam maior risco para a nossa operação e como devemos tratá-las?”

Nem Toda Vulnerabilidade Exige a Mesma Urgência

Uma vulnerabilidade com classificação crítica não representa automaticamente o maior risco para uma operação industrial.

É preciso entender onde ela está.

Um ativo isolado, protegido por diferentes controles e sem exposição externa pode representar uma situação completamente diferente de um sistema conectado à internet, utilizado para acesso remoto ou diretamente relacionado a uma função crítica.

O cenário atual evidencia a importância dessa priorização.

No relatório de cibersegurança OT publicado em 2026, a Dragos concluiu que apenas 2% das vulnerabilidades relevantes para ICS analisadas em 2025 exigiam ação imediata segundo seu modelo de priorização baseado em risco.

Isso não significa ignorar as demais vulnerabilidades.

Significa compreender que tentar tratar todas com a mesma urgência pode consumir recursos justamente onde eles são menos necessários.

CVSS é Importante, mas Não Deve Decidir Sozinho

A severidade técnica continua sendo uma informação relevante para gestão de vulnerabilidades, mas não deveria determinar isoladamente a ordem das correções.

O próprio cenário de 2026 mostra uma limitação adicional: segundo a Dragos, 25% das vulnerabilidades avaliadas a partir de ICS-CERT e NVD apresentavam pontuações CVSS incorretas em sua análise.

Uma estratégia de priorização precisa combinar diferentes informações.

Além da severidade, é importante considerar a criticidade do ativo, exposição, existência de exploração conhecida, facilidade de acesso ao sistema, função operacional, dependências, disponibilidade de correção e consequências de um eventual comprometimento.

O catálogo Known Exploited Vulnerabilities (KEV) da CISA, por exemplo, reúne vulnerabilidades que possuem evidências de exploração no mundo real e é recomendado pela própria agência como uma das entradas para frameworks de priorização de vulnerabilidades.

Isso permite sair de uma lógica baseada apenas em:

“Qual vulnerabilidade tem o maior score?”

para:

“Qual vulnerabilidade representa maior risco no contexto da nossa operação?”

Antes do Patch, é Preciso Conhecer o Ativo

Não existe gestão eficiente de patches sem gestão de ativos.

A organização precisa saber quais equipamentos e sistemas existem, quais versões estão em uso, quais funções desempenham e como estão conectados.

Também precisa compreender sua criticidade.

Uma vulnerabilidade em uma estação de engenharia responsável pela configuração de controladores pode exigir uma avaliação diferente daquela presente em um sistema de baixa criticidade.

Da mesma forma, dois equipamentos com exatamente a mesma vulnerabilidade podem receber prioridades diferentes dependendo de sua exposição e função operacional.

Por isso, inventário e contexto operacional precisam estar conectados à gestão de vulnerabilidades.

A pergunta não é apenas “onde está o CVE?”, mas:

“O que acontece com a operação se esse ativo for comprometido?”

Testar Continua Sendo Fundamental

Uma prática importante do artigo original continua válida em 2026: patches destinados a sistemas OT precisam ser avaliados antes de sua implantação.

Uma atualização pode alterar bibliotecas, drivers, serviços ou componentes dos quais aplicações industriais dependem.

Em determinados ambientes, a organização também depende do fabricante para validar se a atualização é compatível com o sistema.

O NIST destaca justamente essa particularidade: organizações podem depender dos fornecedores para validar a operação de um patch antes de implantá-lo em OT.

Quando houver ambiente de homologação disponível, ele pode ser utilizado para avaliar compatibilidade e comportamento antes da implantação.

Quando isso não for possível, o planejamento precisa considerar outras formas de reduzir o risco da mudança.

Aplicar um patch resolve uma vulnerabilidade. Uma atualização inadequada também pode criar indisponibilidade.

Em OT, as duas possibilidades precisam entrar na decisão.

A Janela de Manutenção Faz Parte da Estratégia

Ao contrário de grande parte dos ambientes corporativos, sistemas industriais podem operar continuamente durante longos períodos.

Parar um processo para realizar uma atualização pode exigir planejamento de produção, equipes especializadas e coordenação com diferentes áreas.

Por isso, a janela de manutenção não deve ser tratada simplesmente como um obstáculo à segurança.

Ela faz parte da própria gestão do risco.

Quando a vulnerabilidade pode aguardar com segurança, o patch pode ser planejado para uma janela adequada.

Quando o risco de exploração é elevado e a próxima janela está distante, a organização precisa avaliar outras possibilidades de mitigação.

E é justamente aí que entra um ponto essencial para a segurança OT.

Quando Não é Possível Aplicar o Patch

Essa é uma das principais diferenças entre uma abordagem de patches tradicional e uma estratégia realmente adaptada a OT.

Nem sempre haverá um patch disponível.

No levantamento divulgado pela Dragos em 2026, 26% dos advisories analisados não apresentavam patch ou mitigação fornecidos pelo fabricante.

Mesmo quando existe uma atualização, pode haver situações em que ela ainda não possa ser aplicada porque precisa de validação, é incompatível com o ambiente ou exige uma parada operacional inviável naquele momento.

O NIST prevê explicitamente esse cenário.

Quando o patch não estiver disponível ou sua implantação não for viável, podem ser adotados controles compensatórios, como redução da exposição do sistema, restrição de serviços vulneráveis e virtual patching. Também pode ser necessário aumentar a capacidade de detectar uma possível exploração.

A CISA segue lógica semelhante e recomenda que, quando um ativo OT não puder ser atualizado sem comprometer disponibilidade ou segurança, sejam implementados e documentados controles compensatórios, incluindo segmentação e monitoramento.

Portanto:

não aplicar imediatamente um patch não significa necessariamente aceitar o risco sem fazer nada.

Segmentação Pode Reduzir a Exposição Durante a Espera

Quando uma vulnerabilidade não pode ser corrigida imediatamente, reduzir os caminhos disponíveis para explorá-la se torna ainda mais importante.

Isso pode envolver segmentação, restrição das comunicações permitidas, controle de acesso remoto, limitação de serviços e redução da exposição à internet.

A própria CISA orienta que controles compensatórios para ativos OT não corrigíveis sejam capazes de retirar o ativo da exposição pública ou reduzir a capacidade de um adversário explorar suas vulnerabilidades.

Essa lógica é importante porque muda a pergunta.

Em vez de:

“Esse equipamento está atualizado?”

a organização também precisa saber:

“Enquanto ele não pode ser atualizado, quais controles reduzem seu risco?”